次の方法で共有

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

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

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

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

接続の管理

資格情報マネージャーの接続の 管理 部分では、OAuth 2.0 トークンの 資格情報プロバイダー の設定と構成が行われ、プロバイダーの同意フローが有効になり、資格情報プロバイダーへの 1 つ以上の 接続 が資格情報プロバイダーに設定されて資格情報にアクセスできるようになります。

次の図は、承認コード許可の種類を使用する API Management で接続を作成するためのプロセス フローをまとめたものです。

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

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

資格情報プロバイダー

資格情報プロバイダーを構成するときに、さまざまな OAuth プロバイダー と許可の種類 (承認コードまたはクライアント資格情報) を選択できます。 各プロバイダーには、特定の構成が必要です。 注意すべき重要な点:

  • 資格情報プロバイダーの構成には、許可の種類を 1 つだけ指定できます。
  • 1 つの資格情報プロバイダー構成に 複数の接続を設定できます。

注

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

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

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

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

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

許可の種類 Description
Authorization code (承認コード) ユーザー コンテキストにバインドされます。つまり、ユーザーは接続に同意する必要があります。 更新トークンが有効である限り、API Management は新しいアクセス トークンと更新トークンを取得できます。 更新トークンが無効になった場合、ユーザーは再認証する必要があります。 すべての資格情報プロバイダーは、承認コードをサポートします。 詳細情報
クライアント資格情報 ユーザーにバインドされておらず、アプリケーション間のシナリオでよく使用されます。 クライアント資格情報の許可の種類に同意する必要はなく、接続が無効になりません。  詳細情報

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

アクセス ポリシー

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

アイデンティティ Description メリット 考慮事項
サービス プリンシパル 組織が 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 アカウントを持っている必要があります。

接続のランタイム

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

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

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

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

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

関連コンテンツ