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 フローをテストするには、Requesting App から送信される JWT-Bearer リクエストを Auth0 テナントが受け付けられることを確認する必要があります。この処理は Auth0 によって自動的に行われます。
エンドツーエンドの XAA フローをテストする前に、次を確認してください。
- Okta テナント内で Requesting App として動作するテスト用アプリケーションのコールバック URL を Redirect URI フィールドに設定して更新します。手順については、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 |
まず、Okta テストテナントを使用して Requesting App にログインする必要があります。ログインに成功して同意を付与すると、Okta は認可コードを付与してブラウザーを Requesting App にリダイレクトします。Requesting App はその認可コードを安全に Okta のアクセストークンと IDトークンに交換します。
Okta の IDトークンを ID-JAG に交換するには、Requesting App が次のパラメーターを指定して、Okta テストテナントの /token エンドポイントに対して 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 エンドポイントに アクセストークンのリクエスト を送信します。
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 を取得し、適用されるアクセス制御を再度受ける必要があります。