このガイドでは、エンタープライズのアイデンティティ プロバイダー (IdP) として Okta を使用し、テストに利用できる Okta テナントへの管理者アクセス権を持っていることを前提とします。まだお持ちでない場合は、Create and configure your Okta tenant を参照してください。
主要な利点
- エンタープライズ IT 管理者向け: アプリケーションによるエンタープライズデータおよびユーザーデータへのアクセスについて、一元的な制御、可視性、ポリシーの適用を実現します。
- SaaS プロバイダーおよび開発者向け: エコシステムの成長を促進する、エンタープライズ AI 向けの標準化されたセキュアな統合を提供します。
- エンドユーザー向け: アプリケーション間の接続を効率化し、摩擦のない体験を実現することで、複雑な OAuth 同意フローを不要にします。
ユースケース
- AI エージェントをエンタープライズアプリケーションに接続する: 従業員が AI エージェントを使って自分のカレンダーアプリから予定を読み取り、エンタープライズ向けメッセージングアプリに自分の空き状況に関する更新を投稿します。従業員にリダイレクトフローや同意プロンプトへの対応を求める代わりに、AI エージェントは XAA を使用してエンタープライズ IdP（アイデンティティプロバイダー）からアクセストークンを取得し、エンタープライズのアクセスポリシーで許可されている場合に、カレンダーアプリとメッセージングアプリの両方の API を安全に呼び出します。
- SaaS アプリケーションを接続する: 前述の例では、エンタープライズのカレンダーアプリとメッセージングアプリの両方が XAA をサポートしています。従業員は、エンタープライズのアクセスポリシーに従いつつ、ユーザーのリダイレクトや同意を伴うことなく、メッセージングアプリをシームレスに接続してカレンダーアプリの API にアクセスできます。
仕組み
- Requesting App: リソースへアクセスする必要があるアプリケーションまたは AI エージェント。
- Resource App: 保護されたリソースを所有し、API を介してそれを公開するアプリケーション。
- Enterprise IdP: Okta などの、従業員を認証する IdP（アイデンティティプロバイダー）。
- Resource App（Todo0）の Authorization Server は、OIDC を通じて Enterprise IdP とフェデレーションされており、その IdP によって認証されたエンドユーザー向けのアクセストークンを生成できます。
- Requesting App（Agent0）は、Resource App Authorization Server に対して OAuth 2.0 クライアントとして登録されており、有効な client_id と資格情報を使用して Resource App Authorization Server からアクセストークンを要求できます。
- Acme の IT 管理者は、Agent0 と Todo0 間の XAA アクセス制御を定義しています。
エンドツーエンドの XAA フロー
- Acme の従業員が、エンタープライズ IdP を用いた SSO で Requesting App（Agent0）にログインします。Requesting App は、Acme 従業員のアイデンティティを検証するために IDトークンを取得します。
- Requesting App は、IDトークンをクロスドメインの Identity Assertion JWT Authorization Grant（ID-JAG とも呼ばれる）に交換するために、IdP にトークン交換リクエストを送信します。IdP はリクエストを検証し、Acme の IT 管理者によって定義された XAA ポリシーを確認します。
- XAA ポリシーで許可されている場合、IdP は ID-JAG を Requesting App に返します。
- Requesting App は、ID-JAG を用いて Resource App（Todo0）の認可サーバーにトークンリクエストを行います。
- Resource App の認可サーバーは、IdP との OpenID Connect フローでも使用している公開鍵を使って ID-JAG を検証します。有効な場合、認可サーバーはアクセストークンを返します。
- Requesting App は、アクセストークンを使用して Resource App の API にリクエストを送信します。
ベータ版の制限事項
- Requesting App は、機密クライアントかつ Auth0 テナント内のファーストパーティアプリである必要があります。SPA やネイティブアプリなどのパブリッククライアントはサポートされません。
- 委任管理はサポートされません。エンタープライズ顧客が Auth0 テナント上で SSO 接続を直接設定することはできません。Self-Service SSO のサポートは、今後のリリースで提供予定です。
- 上流 IdP issuer ごとに、XAA を有効にした接続は 1 つだけに制限されます。同じ Okta テナントを、複数の XAA 有効なエンタープライズ接続に使用することはできません。
- 組織機能のサポートには制限があります:
- 接続は 1 つの組織（Organization）に対して 1:1 で割り当てられます。複数の組織を、XAA アクセス用に同じ接続へマッピングすることはできません。
- Requesting App が組織（Organizations）の使用を必須とするよう構成されている場合、ユーザーは事前に対象の組織のメンバーである必要があります。
resourceパラメーターが ID-JAG リクエストで指定されていない場合、対象 API はtenant.default_audienceによって決定されます。- 動的なユーザー作成は行われません。ユーザーは、あらかじめ設定済みの Okta 接続を使用して Resource App にログインしている必要があります。そうでない場合、ID-JAG アサーションをアクセストークンに交換するリクエストは失敗し、
User not found errorが返されます。
レート制限
/token エンドポイントでの ID-JAG エクスチェンジにはレート制限が適用され、1 秒あたり 5 リクエストまでとなります。