On-Behalf-Of (OBO) フローでは、独自の ID 以外の ID を使用して別の Web API を呼び出す Web API のシナリオについて説明します。 OAuth では委任と呼ばれ、この目的は、要求チェーンを介してユーザーの ID とアクセス許可を渡すことです。
中間層サービスでは、ダウンストリーム サービスに認証済み要求を発行するために、Microsoft ID プラットフォームからのアクセス トークンをセキュリティ保護する必要があります。 アプリケーション ロールでなく、委任されたスコープのみを使用します。 ロール はプリンシパル (ユーザー) にアタッチされたままであり、ユーザーの代わりに動作するアプリケーションにはアタッチされません。 これは、アクセス許可を持つべきではないリソースに対し、ユーザーがアクセス許可を取得できないようにするために発生します。
この記事では、アプリケーション内のプロトコルに対して直接プログラムする方法について説明します。 可能であれば、サポートされている Microsoft 認証ライブラリ (MSAL) を使用して トークンを取得し、セキュリティで保護された Web API を呼び出すようにすることをお勧めします。 例については、 MSAL を使用するサンプル アプリ も参照してください。
クライアントの制限事項
サービス プリンシパルがアプリ専用トークンを要求して API に送信した場合、その API は、元のサービス プリンシパルを表さないトークンを交換します。 これは、OBO フローはユーザー プリンシパルに対してのみ機能するためです。 代わりに、 クライアント資格情報フロー を使用してアプリ専用トークンを取得する必要があります。 シングルページ アプリ (SPA) の場合、中間層の機密クライアントにアクセス トークンを渡して、OBO フローを代わりに実行する必要があります。
クライアントで暗黙的フローを使って id_token を取得する場合、また、応答 URL にワイルドカードが含まれている場合には、id_token を OBO フローで使用することはできません。 ワイルドカードは、* 文字で終わる URL です。 たとえば、https://myapp.com/* が応答 URL の場合、id_token は、クライアントを識別するのに十分に明確でないため、使用できません。 これにより、トークンが発行されるのが回避されます。 ただし、暗黙的な許可フローを通じて取得されたアクセス トークンは、開始側クライアントにワイルドカード応答 URL が登録されている場合でも、機密クライアントによって引き換えられます。 これは、機密クライアントがアクセス トークンを取得したクライアントを識別できるためです。 その後、機密クライアントはアクセス トークンを使用して、ダウンストリーム API の新しいアクセス トークンを取得できます。
また、カスタム署名キーを持つアプリケーションは、OBO フローで中間層 API として使用することはできません。 これには、シングル サインオン用に構成されたエンタープライズ アプリケーションが含まれます。 中間層 API がカスタム署名キーを使用する場合、ダウンストリーム API は、それに渡されるアクセス トークンの署名を検証しません。 これにより、クライアントによって制御されるキーで署名されたトークンを安全に受け入れることができないため、エラーが発生します。
プロトコル図
ユーザーが OAuth 2.0 承認コード付与フロー または別のサインイン フローを使用してアプリケーションを認証したとします。 この時点で、アプリケーションは API A (トークン A) のアクセス トークンを持ち、ユーザーの要求と中間層 Web API (API A) へのアクセスに同意します。 ここで、API A はダウンストリーム Web API (API B) に認証済み要求を発行する必要があります。
OBO フローを構成するための以下の手順について、次の図を使用して説明します。
- クライアント アプリケーションは、トークン A (API A の
aud要求) を使用して API A に要求を発行します。 - API A が Microsoft ID プラットフォーム トークン発行エンドポイントに対して認証を行い、API B にアクセスするためのトークンを要求します。
- Microsoft ID プラットフォーム トークン発行エンドポイントはトークン A を使用して API A の資格情報を検証し、API B (トークン B) から API B へのアクセス トークンを発行します。
- API A によって、API B への要求の承認ヘッダー内にトークン B が設定されます。
- セキュリティで保護されたリソースからのデータが API B によって API A に返され、次に、クライアントに返されます。
このシナリオでは、中間層サービスに、ダウンストリーム API にアクセスするユーザーの同意を得るためのユーザー操作はありません。 そのため、ダウンストリーム API へのアクセス権を付与するオプションは、認証中の同意手順の一部として事前に提供されます。 アプリでこれを実装する方法については、「 中間層アプリケーションの同意を得る」を参照してください。
中間層アクセス トークン要求
アクセス トークンを要求するには、次のパラメーターを使用して、テナントに固有の Microsoft ID プラットフォーム トークン エンドポイントへの HTTP POST を作成します。
https://login.microsoftonline.com/<tenant>/oauth2/v2.0/token
警告
中間層に発行されたアクセス トークンは、トークンの対象ユーザーを除く任意の場所に送信しないでください。 中間層に発行されるアクセス トークンは、その中間層 のみが 目的の対象ユーザー エンドポイントと通信するために使用することを目的としています。
中間層リソースから、(アクセス トークン自体を取得するクライアントではなく)クライアントにアクセス トークンを中継する場合のセキュリティ上のリスクは次のとおりです。
- 侵害された SSL/TLS チャネル経由でのトークン傍受リスクの増加。
- 要求のステップアップ (MFA、サインイン頻度など) が必要なトークン バインディングや条件付きアクセスのシナリオを満たすことができない。
- 管理者が構成したデバイス ベースのポリシー (MDM、場所ベースのポリシーなど) との非互換性。
クライアント アプリケーションのセキュリティ保護に共有シークレットまたは証明書のどちらを使うかに応じて、2 つのケースがあります。
最初のケース:共有シークレットを使ったアクセス トークン要求
共有シークレットを使用する場合、サービス間のアクセス トークン要求には、次のパラメーターが含まれてます。
| パラメーター | タイプ | 説明 |
|---|---|---|
grant_type |
必須 | トークン要求の種類。 JWT を使用した要求では、この値は urn:ietf:params:oauth:grant-type:jwt-bearer にする必要があります。 |
client_id |
必須 | Microsoft Entra 管理センターの [アプリの登録] ページがアプリに割り当てられているアプリケーション (クライアント) ID。 |
client_secret |
必須 | Microsoft Entra管理センター - アプリの登録 ページ でアプリ用に生成したクライアント シークレット。 代わりに、 RFC 6749 に従って Authorization ヘッダーに資格情報を提供する基本的な認証パターンもサポートされています。 |
assertion |
必須 | 中間層 API に送信されたアクセス トークン。 このトークンには、この OBO 要求を行うアプリ (aud フィールドに示されるアプリ) の対象ユーザー (client-id) 要求が必要です。 アプリケーションは別のアプリ用のトークンを利用することはできません (たとえば、クライアントが API に Microsoft Graph 用のトークンを送信した場合、API は OBO を使用してそれを利用することはできません。代わりに、トークンを拒否する必要があります)。 |
scope |
必須 | トークン要求のスコープのスペース区切りリスト。 詳細については、 スコープを参照してください。 |
requested_token_use |
必須 | 要求の処理方法を指定します。 OBO フローでは、この値は on_behalf_of に設定する必要があります。 |
例
次の HTTP POST は、 user.read Web API に対する https://graph.microsoft.com スコープを含むアクセス トークンと更新トークンを要求します。 要求はクライアント シークレットで署名され、機密クライアントによって作成されます。
//line breaks for legibility only
POST /oauth2/v2.0/token HTTP/1.1
Host: login.microsoftonline.com/<tenant>
Content-Type: application/x-www-form-urlencoded
grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
&client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&client_secret=sampleCredentia1s
&assertion=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6InowMzl6ZHNGdWl6cEJmQlZLMVRuMjVRSFlPMCJ9.eyJhdWQiOiIyO{a lot of characters here}
&scope=https://graph.microsoft.com/user.read+offline_access
&requested_token_use=on_behalf_of
2 番目のケース:証明書を使ったアクセス トークン要求
証明書を含むサービス間アクセス トークン要求には、前の例のパラメーターに加えて、次のパラメーターが含まれています。
| パラメーター | タイプ | 説明 |
|---|---|---|
grant_type |
必須 | トークン要求の種類。 JWT を使用した要求では、この値は urn:ietf:params:oauth:grant-type:jwt-bearer にする必要があります。 |
client_id |
必須 | Microsoft Entra 管理センターの [アプリの登録] ページがアプリに割り当てられているアプリケーション (クライアント) ID。 |
client_assertion_type |
必須 | 値は urn:ietf:params:oauth:client-assertion-type:jwt-bearer である必要があります。 |
client_assertion |
必須 | 作成する必要があるアサーション (JSON Web トークン) です。このアサーションは、アプリケーションの資格情報として登録した証明書で署名する必要があります。 証明書を登録する方法とアサーションの形式については、 証明書の資格情報を参照してください。 |
assertion |
必須 | 中間層 API に送信されたアクセス トークン。 このトークンには、この OBO 要求を行うアプリ (aud フィールドに示されるアプリ) の対象ユーザー (client-id) 要求が必要です。 アプリケーションは別のアプリ用のトークンを利用することはできません (たとえば、クライアントが API に MS Graph 用のトークンを送信した場合、API は OBO を使用してそれを利用することはできません。代わりに、トークンを拒否する必要があります)。 |
requested_token_use |
必須 | 要求の処理方法を指定します。 OBO フローでは、この値は on_behalf_of に設定する必要があります。 |
scope |
必須 | トークン要求のスコープのスペース区切りリスト。 詳細については、 スコープを参照してください。 |
パラメーターは、共有シークレットによる要求の場合とほぼ同じであることに注意してください。ただし、 client_secret パラメーターは、 client_assertion_type と client_assertionの 2 つのパラメーターに置き換えられます。
client_assertion_type パラメーターが urn:ietf:params:oauth:client-assertion-type:jwt-bearer に設定され、client_assertion パラメーターが証明書の秘密キーで署名された JWT トークンに設定されます。
例
次の HTTP POST は、証明書を使用して user.read Web API に対する https://graph.microsoft.com スコープを含むアクセス トークンを要求します。 要求はクライアント シークレットで署名され、機密クライアントによって作成されます。
// line breaks for legibility only
POST /oauth2/v2.0/token HTTP/1.1
Host: login.microsoftonline.com/<tenant>
Content-Type: application/x-www-form-urlencoded
grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer
&client_id=11112222-bbbb-3333-cccc-4444dddd5555
&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
&client_assertion=eyJhbGciOiJSUzI1NiIsIng1dCI6Imd4OHRHeXN5amNScUtqRlBuZDdSRnd2d1pJMCJ9.eyJ{a lot of characters here}
&assertion=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6InowMzl6ZHNGdWl6cEJmQlZLMVRuMjVRSFlPMCIsImtpZCI6InowMzl6ZHNGdWl6cEJmQlZLMVRuMjVRSFlPMCJ9.eyJhdWQiO{a lot of characters here}
&requested_token_use=on_behalf_of
&scope=https://graph.microsoft.com/user.read+offline_access
中間層アクセス トークン応答
成功応答は、次のパラメーターを含む JSON OAuth 2.0 応答です。
| パラメーター | 説明 |
|---|---|
token_type |
トークンの種類の値を示します。 Microsoft ID プラットフォームでサポートされる種類は Bearer のみです。 ベアラー トークンの詳細については、「 OAuth 2.0 Authorization Framework: Bearer Token Usage (RFC 6750)」を参照してください。 |
scope |
トークンで付与されるアクセスのスコープ。 |
expires_in |
アクセス トークンが有効な時間の長さ (秒単位)。 |
access_token |
要求されたアクセス トークン。 呼び出し元のサービスは、このトークンを使用して受信側のサービスへの認証を行うことができます。 |
refresh_token |
要求されたアクセス トークンの更新トークン。 呼び出し元のサービスは、現在のアクセス トークンの期限が切れた後に、このトークンを使用して別のアクセス トークンを要求できます。 更新トークンは、offline_access スコープが要求された場合にのみ提供されます。 |
成功応答の例
次の例に、 https://graph.microsoft.com Web API へのアクセス トークン要求に対する成功応答を示します。 応答にはアクセス トークンと更新トークンが含まれており、証明書の秘密キーで署名されます。
{
"token_type": "Bearer",
"scope": "https://graph.microsoft.com/user.read",
"expires_in": 3269,
"ext_expires_in": 0,
"access_token": "eyJ0eXAiOiJKV1QiLCJub25jZSI6IkFRQUJBQUFBQUFCbmZpRy1tQTZOVGFlN0NkV1c3UWZkQ0NDYy0tY0hGa18wZE50MVEtc2loVzRMd2RwQVZISGpnTVdQZ0tQeVJIaGlDbUN2NkdyMEpmYmRfY1RmMUFxU21TcFJkVXVydVJqX3Nqd0JoN211eHlBQSIsImFsZyI6IlJTMjU2IiwieDV0IjoiejAzOXpkc0Z1aXpwQmZCVksxVG4yNVFIWU8wIiwia2lkIjoiejAzOXpkc0Z1aXpwQmZCVksxVG4yNVFIWU8wIn0.eyJhdWQiOiJodHRwczovL2dyYXBoLm1pY3Jvc29mdC5jb20iLCJpc3MiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC83MmY5ODhiZi04NmYxLTQxYWYtOTFhYi0yZDdjZDAxMWRiNDcvIiwiaWF0IjoxNDkzOTMwMzA1LCJuYmYiOjE0OTM5MzAzMDUsImV4cCI6MTQ5MzkzMzg3NSwiYWNyIjoiMCIsImFpbyI6IkFTUUEyLzhEQUFBQU9KYnFFWlRNTnEyZFcxYXpKN1RZMDlYeDdOT29EMkJEUlRWMXJ3b2ZRc1k9IiwiYW1yIjpbInB3ZCJdLCJhcHBfZGlzcGxheW5hbWUiOiJUb2RvRG90bmV0T2JvIiwiYXBwaWQiOiIyODQ2ZjcxYi1hN2E0LTQ5ODctYmFiMy03NjAwMzViMmYzODkiLCJhcHBpZGFjciI6IjEiLCJmYW1pbHlfbmFtZSI6IkNhbnVtYWxsYSIsImdpdmVuX25hbWUiOiJOYXZ5YSIsImlwYWRkciI6IjE2Ny4yMjAuMC4xOTkiLCJuYW1lIjoiTmF2eWEgQ2FudW1hbGxhIiwib2lkIjoiZDVlOTc5YzctM2QyZC00MmFmLThmMzAtNzI3ZGQ0YzJkMzgzIiwib25wcmVtX3NpZCI6IlMtMS01LTIxLTIxMjc1MjExODQtMTYwNDAxMjkyMC0xODg3OTI3NTI3LTI2MTE4NDg0IiwicGxhdGYiOiIxNCIsInB1aWQiOiIxMDAzM0ZGRkEwNkQxN0M5Iiwic2NwIjoiVXNlci5SZWFkIiwic3ViIjoibWtMMHBiLXlpMXQ1ckRGd2JTZ1JvTWxrZE52b3UzSjNWNm84UFE3alVCRSIsInRpZCI6IjcyZjk4OGJmLTg2ZjEtNDFhZi05MWFiLTJkN2NkMDExZGI0NyIsInVuaXF1ZV9uYW1lIjoibmFjYW51bWFAbWljcm9zb2Z0LmNvbSIsInVwbiI6Im5hY2FudW1hQG1pY3Jvc29mdC5jb20iLCJ1dGkiOiJWR1ItdmtEZlBFQ2M1dWFDaENRSkFBIiwidmVyIjoiMS4wIn0.cubh1L2VtruiiwF8ut1m9uNBmnUJeYx4x0G30F7CqSpzHj1Sv5DCgNZXyUz3pEiz77G8IfOF0_U5A_02k-xzwdYvtJUYGH3bFISzdqymiEGmdfCIRKl9KMeoo2llGv0ScCniIhr2U1yxTIkIpp092xcdaDt-2_2q_ql1Ha_HtjvTV1f9XR3t7_Id9bR5BqwVX5zPO7JMYDVhUZRx08eqZcC-F3wi0xd_5ND_mavMuxe2wrpF-EZviO3yg0QVRr59tE3AoWl8lSGpVc97vvRCnp4WVRk26jJhYXFPsdk4yWqOKZqzr3IFGyD08WizD_vPSrXcCPbZP3XWaoTUKZSNJg",
"refresh_token": "OAQABAAAAAABnfiG-mA6NTae7CdWW7QfdAALzDWjw6qSn4GUDfxWzJDZ6lk9qRw4An{a lot of characters here}"
}
このアクセス トークンは、Microsoft Graph 用に v1.0 でフォーマットされたトークンです。 これは、トークン形式はアクセスされる リソース に基づいており、要求に使用されるエンドポイントとは無関係であるためです。 Microsoft Graph は v1.0 トークンを受け入れるように設定されているため、クライアントが Microsoft Graph のトークンを要求すると、Microsoft ID プラットフォームによって v1.0 アクセス トークンが生成されます。 他のアプリは、v2.0 形式のトークン、v1.0 形式のトークン、または独自のまたは暗号化されたトークン形式が必要であることを示している可能性があります。 v1.0 と v2.0 のエンドポイントは両方とも、どちらの形式のトークンも出力できます。 これにより、クライアントがトークンを要求する方法や場所に関係なく、リソースは常に適切な形式のトークンを取得できます。
警告
この例のトークンをコードに含め、所有していない API のトークンの検証や読み取りを試みないでください。 Microsoft サービスのトークンでは、JWT として検証されない特殊な形式を使用できます。また、コンシューマー (Microsoft アカウント) ユーザー向けに暗号化することもできます。 トークンの読み取りは便利なデバッグおよび学習ツールですが、コード内でこれに依存したり、制御する API 用ではないトークンに関する詳細を想定したりしないでください。
エラー応答の例
ダウンストリーム API に条件付きアクセス ポリシー ( 多要素認証など) が設定されている場合、ダウンストリーム API のアクセス トークンを取得しようとすると、トークン エンドポイントからエラー応答が返されます。 クライアント アプリケーションが条件付きアクセス ポリシーを満たすためのユーザー操作を提供できるように、中間層サービスでこのエラーをクライアント アプリケーションに示す必要があります。
このエラーをクライアントに返すために、中間層サービスは HTTP 401 Unauthorized で応答し、エラーと要求チャレンジを含む WWW-Authenticate HTTP ヘッダーを使用して応答します。 クライアントは、このヘッダーを解析し、要求チャレンジが存在する場合はそれを提示し、トークン発行者から新しいトークンを取得する必要があります。 クライアントは、キャッシュされたアクセス トークンを使用して中間層サービスへのアクセスを再試行しないでください。
{
"error":"interaction_required",
"error_description":"AADSTS50079: Due to a configuration change made by your administrator, or because you moved to a new location, you must enroll in multifactor authentication to access 'aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb'.\r\nTrace ID: 0000aaaa-11bb-cccc-dd22-eeeeee333333\r\nCorrelation ID: aaaa0000-bb11-2222-33cc-444444dddddd\r\nTimestamp: 2017-05-01 22:43:20Z",
"error_codes":[50079],
"timestamp":"2017-05-01 22:43:20Z",
"trace_id":"0000aaaa-11bb-cccc-dd22-eeeeee333333",
"correlation_id":"aaaa0000-bb11-2222-33cc-444444dddddd",
"claims":"{\"access_token\":{\"polids\":{\"essential\":true,\"values\":[\"00aa00aa-bb11-cc22-dd33-44ee44ee44ee\"]}}}"
}
アクセス トークンを使用して、セキュリティ保護されたリソースにアクセスする
中間層サービスは、以前に取得したトークンを使用して、 Authorization ヘッダーにトークンを設定することで、ダウンストリーム Web API に対して認証された要求を行うことができます。
例
GET /v1.0/me HTTP/1.1
Host: graph.microsoft.com
Authorization: Bearer eyJ0eXAiO ... 0X2tnSQLEANnSPHY0gKcgw
OAuth2.0 OBO フローにより取得した SAML アサーション
一部の OAuth ベースの Web サービスは、非対話型フローで SAML アサーションを受け入れるその他の Web サービス API にアクセスする必要があります。 Microsoft Entra ID は、SAML ベースの Web サービスをターゲット リソースとして使用する On-Behalf-Of フローに応答して SAML アサーションを提供できます。
これは、OAuth 2.0 On-Behalf-Of フローに対する非標準の拡張機能であり、OAuth2 ベースのアプリケーションが SAML トークンを使用する Web サービス API エンドポイントにアクセスできるようにします。
ヒント
フロントエンド Web アプリケーションから SAML で保護された Web サービスを呼び出す場合、API を呼び出すだけで、ユーザーの既存のセッションで通常の対話型認証フローを開始できます。 サービス間の呼び出しでユーザー コンテキストを提供するために SAML トークンが必要なときのみ OBO フローを使用する必要があります。
共有シークレットを持つ OBO 要求を使用して SAML トークンを取得する
サービス間の SAML アサーション要求には、次のパラメーターが含まれています。
| パラメーター | タイプ | 説明 |
|---|---|---|
| grant_type（グラントタイプ） | 必須 | トークン要求の種類。 JWT を使用する要求の場合、値は urn:ietf:params:oauth:grant-type:jwt-bearer である必要があります。 |
| 主張 | 必須 | 要求で使用されるアクセス トークンの値。 |
| クライアントID | 必須 | Microsoft Entra ID での登録時に呼び出し元のサービスに割り当てられるアプリ ID。 Microsoft Entra 管理センターでアプリ ID を見つけるには、 Entra ID>App 登録 に移動し、アプリケーション名を選択します。 |
| クライアントシークレット | 必須 | 呼び出し元のサービスに対して Microsoft Entra ID に登録されているキー。 この値は、登録時に注意する必要があります。 代わりに、 RFC 6749 に従って Authorization ヘッダーに資格情報を提供する基本的な認証パターンもサポートされています。 |
| 範囲 | 必須 | トークン要求のスコープのスペース区切りリスト。 詳細については、 スコープを参照してください。 SAML 自体にはスコープの概念がありませんが、トークンを受信するターゲットの SAML アプリケーションを識別するために使用されます。 この OBO フローでは、スコープ値は常に、/.default が追加された SAML エンティティ ID である必要があります。 たとえば、SAML アプリケーションのエンティティ ID が https://testapp.contoso.com の場合、要求されたスコープは https://testapp.contoso.com/.default となります。 エンティティ ID の先頭が https: などの URI スキームではない場合、そのエンティティ ID には、Microsoft Entra によって spn: がプレフィックスとして付けられます。 その場合は、スコープ spn:<EntityID>/.default を要求する必要があります (たとえば、エンティティ ID が spn:testapp/.default の場合は testapp)。 ここで要求するスコープ値によって、SAML トークン内の結果の Audience 要素が決まります。これは、トークンを受信する SAML アプリケーションにとって重要である可能性があります。 |
| 要求されたトークン使用 | 必須 | 要求の処理方法を指定します。 On-Behalf-Of フローでは、値は on_behalf_of である必要があります。 |
| 要求されたトークンタイプ | 必須 | 要求するトークンの種類を指定します。 アクセス先のリソースの要件に応じて、値は urn:ietf:params:oauth:token-type:saml2 または urn:ietf:params:oauth:token-type:saml1 のいずれかです。 |
応答には、UTF8 と Base 64url でエンコードされた SAML トークンが含まれています。
-
OBO 呼び出しからソース化された SAML アサーションの SubjectConfirmationData: ターゲット アプリケーションで
RecipientにSubjectConfirmationData値が必要な場合は、リソース アプリケーション構成で最初の非ワイルドカード応答 URL として値を構成する必要があります。 既定の応答 URL はRecipient値を決定するために使用されないため、最初の非ワイルドカード応答 URL が使用されるように、アプリケーション構成の応答 URL の順序を変更する必要がある場合があります。 詳細については、「 応答 URL」を参照してください。 -
SubjectConfirmationData ノード: ノードは SAML 応答の一部ではないため、
InResponseTo属性を含めることはできません。 SAML トークンを受け取るアプリケーションは、InResponseTo属性なしで SAML アサーションを受け入れることができる必要があります。 -
API のアクセス許可: SAML アプリケーションの スコープのトークンを要求できるように、中間層アプリケーションに
/.defaultを追加して SAML アプリケーションへのアクセスを許可する必要があります。 - 同意: OAuth フローでユーザー データを含む SAML トークンを受け取るために同意する必要があります。 詳細については、「 中間層アプリケーションの同意を得る」を参照してください。
SAML アサーションの応答
| パラメーター | 説明 |
|---|---|
| トークンタイプ | トークンの種類の値を示します。 Microsoft Entra ID がサポートする唯一の型は Bearer です。 ベアラー トークンの詳細については、「 OAuth 2.0 Authorization Framework: Bearer Token Usage (RFC 6750)」を参照してください。 |
| 範囲 | トークンで付与されるアクセスのスコープ。 |
| 有効期限 | アクセス トークンが有効な時間の長さ (秒単位)。 |
| 有効期限 | アクセス トークンの有効期限が切れる時刻。 日付は、1970-01-01T0:0:0Z UTC から有効期限までの秒数として表されます。 この値は、キャッシュされたトークンの有効期間を調べるために使用されます。 |
| リソース | 受信側のサービスのアプリ ID URI (セキュリティ保護されたリソース)。 |
| アクセス トークン | SAML アサーションを返すパラメーター。 |
| リフレッシュ トークン (refresh_token) | 更新トークン。 呼び出し元のサービスは、現在の SAML アサーションの期限が切れた後に、このトークンを使用して別のアクセス トークンを要求できます。 |
- token_type:Bearer
- expires_in:3296
- ext_expires_in:0
- expires_on:1529627844
- 資源：
https://api.contoso.com - access_token: <SAML アサーション>
- issued_token_type: urn:ietf:params:oauth:token-type:saml2
- refresh_token: <更新トークン>
中間層アプリケーションの同意の取得
OBO フローの目標は、クライアント アプリから中間層アプリを呼び出すことができ、バックエンド リソースを呼び出すアクセス許可を中間層アプリに持たせるように、適切な同意を与えることです。 アプリケーションのアーキテクチャまたは使用に応じて、OBO フローが正常に実行されるように、次の点を考慮する必要があります。
.default と組み合わせ同意
中間層アプリケーションは、マニフェスト内の既知の クライアント アプリケーション リスト (knownClientApplications) にクライアントを追加します。 同意プロンプトがクライアントによってトリガーされた場合、同意フローはそれ自体と中間層アプリケーションの両方に対して行われます。 Microsoft ID プラットフォームでは、これは.default スコープを使用して行われます。
.default スコープは、アプリケーションがアクセス許可を持つすべてのスコープにアクセスするための同意を要求するために使用される特殊なスコープです。 これは、アプリケーションが複数のリソースにアクセスする必要があるときに、ユーザーに 1 回だけ同意を求めるようにする場合に便利です。
既知のクライアント アプリケーションと .defaultを使用して同意画面をトリガーすると、同意画面に、中間層 API に対するクライアント の両方 のアクセス許可が表示され、中間層 API で必要なすべてのアクセス許可も要求されます。 ユーザーが両方のアプリケーションに対して同意を行うと、OBO フローが動作します。
要求で識別されるリソース サービス (API) は、クライアント アプリケーションがユーザーのサインインの結果としてアクセス トークンを要求するための API である必要があります。 たとえば、scope=openid https://middle-tier-api.example.com/.default (中間層 API のアクセス トークンを要求するため)、または scope=openid offline_access .default (リソースが識別されない場合は既定で Microsoft Graph) です。
承認要求で識別される API に関係なく、同意プロンプトは、クライアント アプリ用に構成されたすべての必要なアクセス許可と組み合わされます。 クライアントを既知のクライアント アプリケーションとして識別した、クライアントの必要なアクセス許可の一覧に記載されている各中間層 API に対して構成されたすべての必要なアクセス許可も含まれます。
事前認証されたアプリケーション
特定のアプリケーションが特定のスコープを受け取る許可を常に持つことをリソースで示すことができます。 これは、フロントエンド クライアントとバックエンド リソース間の接続をよりシームレスに行う場合に役立ちます。 リソースは、マニフェストで 複数の事前認証されたアプリケーション (preAuthorizedApplications) を宣言できます。 このようなアプリケーションは、OBO フローでこれらのアクセス許可を要求し、ユーザーによる同意なしで、それらのアクセス許可を受け取ることができます。
管理者の同意
テナント管理者は、中間層アプリケーションに対して管理者同意を提供することで、アプリケーションが必要な API を呼び出すためのアクセス許可を確実に持つようにすることができます。 これを行うために、管理者は、テナントで中間層アプリケーションを見つけ、必要なアクセス許可ページを開き、アプリに対してアクセス許可を付与することを選択できます。 管理者の同意の詳細については、 同意とアクセス許可のドキュメントを参照してください。
単一アプリケーションの使用
一部のシナリオでは、中間層とフロントエンド クライアントのペアリングが 1 つだけでした。 このシナリオでは、これを単一のアプリケーションにする方が簡単で、中間層アプリケーションの必要性を完全に否定できます。 フロントエンドと Web API 間で認証を行うために、アプリケーション自体に要求された cookie、id_token、またはアクセス トークンを使用できます。 その後、この単一アプリケーションからバックエンド リソースへの同意を要求します。
こちらもご覧ください
OAuth 2.0 プロトコルと、クライアント資格情報を使用したサービス間認証を実行する別の方法について詳しく学びます。