資格情報マネージャーでの 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 | 応答がクライアントに返されます |
関連するコンテンツ
- 資格情報マネージャーの概要
- 資格情報マネージャーの資格情報プロバイダーを構成する
- Microsoft Graph API または GitHub API 用の接続を構成して使用する
- プロバイダーに対して複数の認可接続を構成する
- ユーザー委任アクセスの接続を構成する