資格情報マネージャーでの OAuth 2.0 接続 - プロセスの詳細とフロー

適用対象: すべての API Management レベル

この記事では、Azure API Management の資格情報マネージャーを使用して OAuth 2.0 接続を管理するためのプロセス フローについて詳しく説明します。 プロセス フローは、管理ランタイムの 2 つの部分に分かれています。

API Management の資格情報マネージャーの背景については、API Management の資格情報マネージャーと API 資格情報に関するページを参照してください。

接続の管理

資格情報マネージャーでの接続の管理の部分では、OAuth 2.0 トークンの資格情報プロバイダーの設定と構成、プロバイダーの同意フローの有効化、資格情報にアクセスするための資格情報プロバイダーへの 1 つ以上の接続の設定を行います。

次の図は、認可コードの付与タイプを使用して、API Management で接続を作成するためのプロセス フローを示しています。

資格情報を作成するためのプロセス フローを示す図。

Step 説明
1 資格情報プロバイダーを作成する要求をクライアントが送信します
2 資格情報プロバイダーが作成され、応答が返されます
3 クライアントから、接続の作成を求める要求が送信されます
4 接続が作成され、接続が "接続" されていないという情報を含む応答が返されます
5 クライアントから、資格情報プロバイダーで OAuth 2.0 の同意を開始するためのログイン URL の取得を求める要求が送信されます。 この要求には、最後の手順で使用されるリダイレクト後の URL が含まれます
6 同意フローを開始するために使用するログイン URL を含む応答が返されます。
7 クライアントが、前の手順で提供されたログイン URL を使用してブラウザーを開きます。 ブラウザーが、資格情報プロバイダーの OAuth 2.0 同意フローにリダイレクトされます
8 同意が承認されると、承認コードを使用して、資格情報プロバイダーで構成されたリダイレクト URL にブラウザーがリダイレクトされます
9 API Management で、承認コードを使用してアクセス トークンと更新トークンがフェッチされます
10 API Management は、トークンを受け取って暗号化します
11 API Management が、手順 5 で提供された URL にリダイレクトされます

資格情報プロバイダー

資格情報プロバイダーを構成するときに、さまざまな OAuth プロバイダーと付与タイプ (認可コードまたはクライアント資格情報) を選択できます。 プロバイダーごとに特定の構成が必要です。 以下の点に注意してください。

  • 1 つの資格情報プロバイダーの構成で使用できる付与タイプは 1 つだけです。
  • 1 つの資格情報プロバイダー構成に複数の接続を設定できます。

Note

Generic OAuth 2.0 プロバイダーを使用すると、OAuth 2.0 フローの標準をサポートする他の ID プロバイダーを使用できます。

資格情報プロバイダーを構成すると、バックグラウンドで資格情報マネージャーによって、資格情報ストアが作成され、プロバイダーの OAuth 2.0 アクセス トークンと更新トークンをキャッシュするために使用されます。

資格情報プロバイダーへの接続

プロバイダーのトークンにアクセスして使用するには、クライアント アプリから資格情報プロバイダーへの接続が必要です。 特定の接続は、Microsoft Entra ID の ID に基づいて、アクセス ポリシーによって許可されます。 プロバイダーに対して複数の接続を構成できます。

接続を構成するプロセスは、構成された付与タイプによって異なり、資格情報プロバイダーの構成に固有です。 たとえば、両方の付与タイプを使用するように Microsoft Entra ID を構成する場合は、2 つの資格情報プロバイダーの構成が必要です。 次の表に、2 つの付与タイプの概要を示します。

[付与タイプ] 説明
Authorization code (承認コード) ユーザー コンテキストにバインドされます。つまり、ユーザーは接続に同意する必要があります。 更新トークンが有効であれば、API Management で新しいアクセス トークンと更新トークンを取得できます。 更新トークンが無効になると、ユーザーは再承認する必要があります。 承認コードはすべての資格情報プロバイダーでサポートされます。 詳細情報
クライアントの資格情報 ユーザーにバインドされず、アプリケーション間のシナリオで多く使用されます。 クライアント資格情報付与タイプでは同意は不要であり、接続は無効になりません。 詳細情報

承認コードの付与タイプに基づく接続の場合、プロバイダーに対して認証を行い、承認に "同意" する必要があります。 資格情報プロバイダーによるログインと承認が成功すると、プロバイダーから有効なアクセス トークンと更新トークンが返されます。これらは、API Management によって暗号化され、保存されます。

アクセス ポリシー

接続ごとに 1 つ以上の "アクセス ポリシー" を構成します。 アクセス ポリシーによって、実行時に認可にアクセスできる Microsoft Entra ID の ID が決まります。 現在、接続では、サービス プリンシパル、API Management インスタンスの ID、ユーザー、グループを使用したアクセスがサポートされています。

ID 説明 メリット 考慮事項
サービス プリンシパル 組織で Microsoft Entra ID を使用している場合に、そのトークンを使用して、特定の Azure リソースを認証し、アクセス権を付与することができる ID。 サービス プリンシパルを使用することで、組織は、ユーザーがリソースにアクセスする必要があるときに認証を管理するための架空ユーザーを作成することを避けることができます。 サービス プリンシパルは、登録済みの Microsoft Entra アプリケーションを表す Microsoft Entra ID です。 接続とユーザー委任のシナリオに対して、より厳密にスコープ指定されたアクセスを許可します。 特定の API Management インスタンスに関連付けられません。 アクセス許可の適用には Microsoft Entra ID を使用します。 承認コンテキストを取得するには、Microsoft Entra ID トークンが必要です。
マネージド ID <Your API Management instance name> このオプションは、API Management インスタンスに関連付けられているマネージド ID に対応します。 既定では、対応する API 管理インスタンスのシステム割り当てマネージド ID へのアクセスが提供されます。 ID は、API Management インスタンスに関連付けられています。 API Management インスタンスへの共同作成者アクセス権があれば、だれでも任意の接続にアクセスして、マネージド ID のアクセス許可を付与できます。
ユーザーまたはグループ Microsoft Entra ID テナント内のユーザーまたはグループ。 特定のユーザーまたはユーザーのグループへのアクセスを制限できます。 ユーザーが Microsoft Entra ID アカウントを持っている必要があります。

接続のランタイム

ランタイム部分では、バックエンド OAuth 2.0 API を get-authorization-context ポリシーで構成する必要があります。 実行時に、ポリシーによって、API Management でプロバイダー用に設定されたアクセス トークンと更新トークンが資格情報ストアからフェッチされて保存されます。 API Management が呼び出され、get-authorization-context ポリシーが実行されると、まず既存の承認トークンが有効かどうかが検証されます。 承認トークンの有効期限が切れている場合、API Management は OAuth 2.0 フローを使用して、格納されているトークンを資格情報プロバイダーから更新します。 その後、アクセス トークンを使用してバックエンド サービスへのアクセスが承認されます。

ポリシーの実行中は、アクセス ポリシーを使用してトークンへのアクセスも検証されます。

次の図は、承認コードの付与タイプを使用する接続に基づいて、承認トークンと更新トークンをフェッチして格納するプロセス フローの例を示しています。 トークンが取得されると、バックエンド API への呼び出しが行われます。

実行時にトークンを取得するためのプロセス フローを示す図。

Step 説明
1 クライアントが、API Management インスタンスに要求を送信します
2 get-authorization-context ポリシーによって、アクセス トークンが現在の接続に対して有効かどうかが確認されます
3 アクセス トークンの有効期限が切れているが、更新トークンが有効な場合、API Management によって、構成された資格情報プロバイダーから新しいアクセス トークンと更新トークンのフェッチが試みられます
4 資格情報プロバイダーから、アクセス トークンと更新トークンの両方が返されます。これらは暗号化されて API Management に保存されます
5 トークンが取得されると、set-header ポリシーを使用して、アクセス トークンがバックエンド API への送信要求に Authorization ヘッダーとしてアタッチされます
6 応答が API Management に返されます
7 応答がクライアントに返されます