> ## Documentation Index
> Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

> エンドツーエンドのXAAフローをテストする方法について説明します。

# Cross App Access（XAA）フローをテストする

export const ReleaseStageNotice = ({feature, stage, plans, contact, terms}) => {
  const stageTextMap = {
    "beta": "ベータ",
    "ea": "早期アクセス"
  };
  const stageText = stageTextMap[stage] || "製品リリース段階";
  const prsLink = "/docs/troubleshoot/product-lifecycle/product-release-stages";
  const linkify = (text, url) => {
    return <a href={url} target="_blank" rel="noreferrer" class="link">{text}</a>;
  };
  const includeDetails = (plans, contact, terms) => {
    const hasDetails = terms || plans || contact;
    if (!hasDetails) return null;
    return <span data-as="p">
            {plans && <>この機能は、{linkify(`${plans}プラン`, "https://auth0.com/pricing")}で利用できます。 </>}
            {contact && "参加するには、" + contact + " までお問い合わせください。 "}
            {terms && <>この機能を使用すると、Okta の{linkify("Master Subscription Agreement", "https://www.okta.com/legal")}に定める該当する無料トライアル条件に同意したものとみなされます。</>}
        </span>;
  };
  return <Warning>
            <span data-as="p">
                <strong>{feature} 機能は現在、{linkify(stageText, prsLink)}です。</strong>
            </span>

            {includeDetails(plans, contact, terms)}
        </Warning>;
};

<ReleaseStageNotice feature="Cross App Access (XAA)" stage="beta" contact="Auth0 Support" terms="true" />

エンドツーエンドの XAA フローをテストするには、Requesting App から送信される JWT-Bearer リクエストを Auth0 テナントが受け入れられることを確認する必要があります。これには、追加設定なしで Auth0 が対応します。

エンドツーエンドの XAA フローをテストする前に、次の点を確認してください。

* **Redirect URI** フィールドを、Okta テナントで Requesting App として動作するテスト用アプリケーションのコールバック URL に更新します。詳細は、[Register the Requesting App in Okta](/ja/docs/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`                                                         |

<div id="exchange-the-id-token-for-an-id-jag">
  ### IDトークンを ID-JAG に交換する
</div>

まず、Okta のテストテナントを使用して Requesting App にログインする必要があります。ログインに成功し、同意を与えると、Okta は認可コードを付与してブラウザーを Requesting App にリダイレクトします。続いて、Requesting App はその認可コードを安全に Okta のアクセストークンと IDトークン に交換します。

Okta の IDトークン を ID-JAG に交換するには、Requesting App は次のパラメーターを指定して、Okta テストテナントの `/token` エンドポイントに [token exchange request](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}}
```

| **パラメーター**             | **説明**                                                                                                                                                                                                                                                                                                                                                               |
| ---------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `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 はユーザーの ID の「証明」または「アサーション」です。IdP がユーザーの ID を検証するために使用する Okta の IDトークンに設定します。                                                                                                                                                                                                                                                  |
| `subject_token_type`   | `subject_token` パラメーターで指定するトークンの種類です。XAA では、認可サーバーに IDトークンを提示することを示します。                                                                                                                                                                                                                                                                                              |
| `client_id`            | トークン交換リクエストを行う enterprise IdP 内の Requesting App のクライアントIDです。                                                                                                                                                                                                                                                                                                         |
| `client_secret`        | Requesting App が enterprise IdP に対して自身を認証するために使用するクライアントシークレットです。                                                                                                                                                                                                                                                                                                    |

XAA Beta では、Okta の `/token` エンドポイントにスコープを渡すことはサポートされていません。Requesting App が ID-JAG を受け取った後、Auth0 の /token エンドポイントに対する次のリクエストでスコープを設定できます。

本番環境では、Requesting App はお客様の Okta テナントの `/token` エンドポイントにトークン交換リクエストを送信します。

<div id="send-id-jag-to-auth0s-token-endpoint">
  ### ID-JAG を Auth0 の /token エンドポイントに送信する
</div>

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}}
```

| **パラメーター**      | **説明**                                                                         |
| --------------- | ------------------------------------------------------------------------------ |
| `grant_type`    | グラントタイプです。これにより、認可サーバーは、リクエスト内の主たる認証情報として JSON Web Token (JWT) が送信されることを想定します。 |
| `client_id`     | API 呼び出しを行う Resource App 認可サーバー内の Requesting App のクライアントIDです。                  |
| `client_secret` | API 呼び出しを行う Resource App 認可サーバー内の Requesting App のクライアントシークレットです。              |
| `scope`         | Requesting App がアクセストークンに対して要求する権限のセットです。                                      |
| `assertion`     | ID アサーションのベアラーとして機能する ID-JAG または JSON Web Token (JWT) です。                      |

Auth0 認可サーバーは、ユーザーの本人確認のために ID-JAG を検証した後、Auth0 テナント内の対象 API オーディエンスを利用するためのアクセストークンを発行します。このアクセストークンには、RBAC と Auth0 テナントで設定されたその他のポリシーで許可された、要求したスコープも含まれます。

Auth0 認可サーバーは、ID-JAG トークン交換への応答としてリフレッシュトークンを発行しません。そのため、Requesting App は XAA 経由で新しいアクセストークンを取得するために、エンタープライズ IdP から新しい ID-JAG を取得し、該当するアクセス制御を受ける必要があります。