> ## Documentation Index
> Fetch the complete documentation index at: https://auth0.generaltranslation.app/llms.txt
> Use this file to discover all available pages before exploring further.
> エンドツーエンドの XAA フローのテスト方法を学びます。
# Cross App Access (XAA) フローをテストする
Cross App Access (XAA) は現在ベータ版です。この機能を使用することで、Okta の [Master Subscription Agreement](https://www.okta.com/legal) における該当する無料トライアル条件に同意したものとみなされます。Auth0 のプロダクトリリースサイクルの詳細については、[Product Release Stages](/docs/ja-JP/troubleshoot/product-lifecycle/product-release-stages) を参照してください。本プログラムに参加するには、[Auth0 Support](https://support.auth0.com/) またはお客様のテクニカルアカウントマネージャーにお問い合わせください。
エンドツーエンドの XAA フローをテストするには、Requesting App から送信される JWT-Bearer リクエストを Auth0 テナントが受け付けられることを確認する必要があります。この処理は Auth0 によって自動的に行われます。
エンドツーエンドの XAA フローをテストする前に、次を確認してください。
* Okta テナント内で Requesting App として動作するテスト用アプリケーションのコールバック URL を **Redirect URI** フィールドに設定して更新します。手順については、[Register the Requesting App in Okta](/docs/ja-JP/secure/call-apis-on-users-behalf/xaa/set-up-xaa-test-environment#register-the-requesting-app-in-okta) を参照してください。
* 次の情報を Okta の担当者に提供します。
* Auth0 テナントの issuer URL。Resource App は Okta Integration Network (OIN) 内で issuer URL に関連付けられ、Requesting App が ID-JAG をリクエストする際にそれを参照できるようになります。
* OIN 内の各 Requesting App に対応する Auth0 の `client_id`。
Auth0 テナント内で issuer URL とクライアント ID を取得するには、**Applications** に移動し、対象のアプリケーションを選択してから **Settings** を選択します。
| **Field** | **Instructions** | **Example** |
| ----------- | --------------------------------------------------- | ------------------------------------------------------------------------------------------ |
| Issuer URL | Auth0 ドメインをコピーし、その前に `https://` を付け、末尾にスラッシュを追加します。 | `https://tenant.region.auth0.com/` または、顧客がカスタムドメインを使用している場合は `https://custom-domain.com/`。 |
| `client_id` | アプリケーションのクライアント ID をコピーします。 | `ovBLQycaVq6I0Xyuhq84pwDVyJeXWLyx` |
### IDトークンをID-JAGに交換する
まず、Okta テストテナントを使用して Requesting App にログインする必要があります。ログインに成功して同意を付与すると、Okta は認可コードを付与してブラウザーを Requesting App にリダイレクトします。Requesting App はその認可コードを安全に Okta のアクセストークンと IDトークンに交換します。
Okta の IDトークンを ID-JAG に交換するには、Requesting App が次のパラメーターを指定して、Okta テストテナントの `/token` エンドポイントに対して [token exchange リクエスト](https://www.ietf.org/archive/id/draft-parecki-oauth-identity-assertion-authz-grant-05.html#name-token-exchange) を実行します。
```
POST /oauth2/v1/token HTTP/1.1
Host: {{YOUR_TENANT}}.okta.com
Content-Type: application/x-www-form-urlencoded
grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&requested_token_type=urn:ietf:params:oauth:token-type:id-jag
&audience={{YOUR_AUTH0_TENANT_ISSUER_URL}}
&resource={{YOUR_AUTH0_TENANT_API_AUDIENCE}}
&subject_token={{OKTA_ID_TOKEN}}
&subject_token_type=urn:ietf:params:oauth:token-type:id_token
&client_id={{REQUESTING_APP_CLIENT_ID_IN_OKTA}}
&client_secret={{REQUESTING_APP_CLIENT_SECRET_IN_OKTA}}
```
| **Parameter** | **Description** |
| ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `grant_type` | グラントタイプ。トークン交換グラントタイプである `urn:ietf:params:oauth:grant-type:token-exchange` を設定します。 |
| `requested_token_type` | クライアントが認可サーバーから受け取りたいトークン種別。Identity Assertion Authorization Grant（ID-JAG）である `urn:ietf:params:oauth:token-type:id-jag` を設定します。 |
| `audience` | 最終トークンの想定される受信者。Auth0 テナントの issuer URL、またはその URL を認可サーバーとして持つ Resource App を設定します。 |
| `resource` | 任意。クライアントがアクセスしたい Resource App の API。認可サーバーが最終的なアクセストークンを発行する際、このリソースをトークンの `aud` クレームに含めます。Resource App の API は、この値を検証に使用します。`resource` パラメータを指定しない場合、次のアクセストークン取得リクエストでは、テナントで設定したデフォルトのオーディエンスが使用されます。Auth0 テナント内の有効な API オーディエンスと一致しない `resource` を指定した場合でも、トークン交換リクエスト自体は失敗せず、ID-JAG は返されます。ただし、その ID-JAG を用いた後続のアクセストークン取得リクエストは Auth0 テナントによって拒否されます。 |
| `subject_token` | クライアントが交換するトークン。XAA では、subject token はユーザーのアイデンティティの「証拠」または「アサーション」となります。IdP がユーザーのアイデンティティを検証するために使用する Okta の IDトークン を設定します。 |
| `subject_token_type` | `subject_token` パラメータで渡されるトークン種別。XAA では、認可サーバーに対して IDトークン が提示されていることを示します。 |
| `client_id` | トークン交換リクエストを送信するエンタープライズ IdP 内の Requesting App のクライアントID。 |
| `client_secret` | Requesting App がエンタープライズ IdP に対して自身を認証するために使用するクライアントシークレット。 |
XAA Beta では、Okta の `/token` エンドポイントに対してスコープを渡すことはサポートされていません。Requesting App が ID-JAG を受け取った後、次の Auth0 の /token エンドポイントへのリクエストでスコープを設定できます。
本番環境では、Requesting App はお客様の Okta テナントの `/token` エンドポイントに対してトークン交換リクエストを送信します。
### ID-JAG を Auth0 の /token エンドポイントに送信する
Requesting App が ID-JAG を取得したら、Auth0 テナントの `/token` エンドポイントに [アクセストークンのリクエスト](https://www.ietf.org/archive/id/draft-parecki-oauth-identity-assertion-authz-grant-05.html#name-access-token-request) を送信します。
```
POST https://{{YOUR_AUTH0_TENANT_DOMAIN}}/oauth/token
Content-Type: application/x-www-form-urlencoded
grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
&client_id={{REQUESTING_APP_CLIENT_ID_IN_AUTH0}}
&client_secret={{REQUESTING_APP_CLIENT_SECRET_IN_AUTH0}}
&scope=scope1%20scope2%20
&assertion={{ID_JAG}}
```
| **Parameter** | **Description** |
| --------------- | ----------------------------------------------------------------------------- |
| `grant_type` | グラントタイプ。リクエスト内で JSON Web Token (JWT) を主要な認証情報として使用することを認可サーバーに伝えます。 |
| `client_id` | API 呼び出しを行う Resource App の認可サーバー内における Requesting App の client\_id（クライアント ID）。 |
| `client_secret` | API 呼び出しを行う Resource App の認可サーバー内における Requesting App のクライアントシークレット。 |
| `scope` | Requesting App がアクセストークンに対して要求する権限のセット（スコープ）。 |
| `assertion` | アイデンティティアサーションの保有者として機能する ID-JAG または JSON Web Token (JWT)。 |
Auth0 認可サーバーが ID-JAG を検証してユーザーのアイデンティティを確認すると、Auth0 テナント内の対象 API オーディエンスを呼び出すためのアクセストークンを発行します。アクセストークンには、Auth0 テナントで設定された RBAC やその他のポリシーによって許可された、要求済みのスコープも含まれます。
Auth0 認可サーバーは、ID-JAG トークン交換に対してはリフレッシュトークンを発行しません。そのため、Requesting App は XAA 経由で新しいアクセストークンを取得するために、エンタープライズ IdP（アイデンティティプロバイダー）から新しい ID-JAG を取得し、適用されるアクセス制御を再度受ける必要があります。