> ## 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.

> Cross App Access (XAA) を活用して、ユーザーに代わって API を呼び出す方法を学びます。

# Cross App Access (XAA)

<Warning>
  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/) または担当の Technical Account Manager までご連絡ください。
</Warning>

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  このガイドでは、エンタープライズのアイデンティティ プロバイダー (IdP) として Okta を使用し、テストに利用できる Okta テナントへの管理者アクセス権を持っていることを前提とします。まだお持ちでない場合は、[Create and configure your Okta tenant](/docs/ja-JP/secure/call-apis-on-users-behalf/xaa/set-up-xaa-test-environment#create-and-configure-your-okta-tenant) を参照してください。
</Callout>

エンタープライズ環境でサードパーティ アプリケーションや AI エージェントを接続すると、IT 部門から見たデータ共有の可視性の低さと、ユーザーに対する同意フローの繰り返しという 2 つの主要な問題が発生します。

Cross App Access (XAA) は、SaaS アプリケーション（AI エージェントなど）がユーザーに代わって接続する方法について、IT 管理者がアクセス制御を一元的に定義できるようにすることで、これらの課題に対処します。管理者は Okta Admin Console のような中央ダッシュボードでこれらの接続を管理でき、エンドユーザーに対する煩わしい OAuth 同意プロンプトを排除できます。その結果、組織のセキュリティとガバナンス、およびユーザーエクスペリエンスが向上します。

XAA は、AI エージェントまたはアプリケーション (Requesting App) がエンタープライズ IdP（アイデンティティ プロバイダー）を通じて安全なトークンを取得できるようにする、策定中の OAuth 拡張仕様である [Identity Assertion Authorization Grant](https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/) を実装しています。このトークンにより、Requesting App はエンドユーザーに代わって別のアプリケーション (Resource App) の API を呼び出すことができます。詳細については、[How it works](#how-it-works) を参照してください。

<div id="key-benefits">
  ## 主要な利点
</div>

XAA は、エンタープライズエコシステム内のあらゆる役割に対して、次のような主要な利点を提供します。

* エンタープライズ IT 管理者向け: アプリケーションによるエンタープライズデータおよびユーザーデータへのアクセスについて、一元的な制御、可視性、ポリシーの適用を実現します。
* SaaS プロバイダーおよび開発者向け: エコシステムの成長を促進する、エンタープライズ AI 向けの標準化されたセキュアな統合を提供します。
* エンドユーザー向け: アプリケーション間の接続を効率化し、摩擦のない体験を実現することで、複雑な OAuth 同意フローを不要にします。

<div id="use-cases">
  ## ユースケース
</div>

XAA の一般的なユースケースには次のようなものがあります。

* AI エージェントをエンタープライズアプリケーションに接続する: 従業員が AI エージェントを使って自分のカレンダーアプリから予定を読み取り、エンタープライズ向けメッセージングアプリに自分の空き状況に関する更新を投稿します。従業員にリダイレクトフローや同意プロンプトへの対応を求める代わりに、AI エージェントは XAA を使用してエンタープライズ IdP（アイデンティティプロバイダー）からアクセストークンを取得し、エンタープライズのアクセスポリシーで許可されている場合に、カレンダーアプリとメッセージングアプリの両方の API を安全に呼び出します。
* SaaS アプリケーションを接続する: 前述の例では、エンタープライズのカレンダーアプリとメッセージングアプリの両方が XAA をサポートしています。従業員は、エンタープライズのアクセスポリシーに従いつつ、ユーザーのリダイレクトや同意を伴うことなく、メッセージングアプリをシームレスに接続してカレンダーアプリの API にアクセスできます。

<div id="how-it-works">
  ## 仕組み
</div>

XAA フローには次のアクターが関係します。

* Requesting App: リソースへアクセスする必要があるアプリケーションまたは AI エージェント。
* Resource App: 保護されたリソースを所有し、API を介してそれを公開するアプリケーション。
* Enterprise IdP: Okta などの、従業員を認証する IdP（アイデンティティプロバイダー）。

エンドユーザーが Enterprise IdP で認証された後、Requesting App はユーザーに代わって Resource App へのアクセスを要求するために Enterprise IdP に問い合わせます。Enterprise IdP は、アプリ間接続が許可されているかどうかを確認するアクセスポリシーを適用した後、ID-JAG と呼ばれるアサーションを生成します。Requesting App はこの ID-JAG を Resource App に提示し、API 利用のためのアクセストークンを取得します。 

次の図では、Acme はエンタープライズ顧客であり、その従業員は Enterprise IdP（Okta など）で認証され、Requesting App（Agent0）および Resource App（Todo0）へアクセスします。

<Frame>
  <img src="https://mintcdn.com/generaltranslationinc/78hG6sVmUVcUqk59/docs/images/xaa/xaa_high_level_diagram.png?fit=max&auto=format&n=78hG6sVmUVcUqk59&q=85&s=80ac2da8bfbdc3bdceda448b9c50ca02" alt="" width="1454" height="1034" data-path="docs/images/xaa/xaa_high_level_diagram.png" />
</Frame>

* 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 アクセス制御を定義しています。

<div id="end-to-end-xaa-flow">
  ## エンドツーエンドの XAA フロー
</div>

Acme の例を念頭に置くと、エンドツーエンドの XAA フローは次の手順で構成されます。

1. Acme の従業員が、エンタープライズ IdP を用いた SSO で Requesting App（Agent0）にログインします。Requesting App は、Acme 従業員のアイデンティティを検証するために IDトークンを取得します。
2. Requesting App は、IDトークンをクロスドメインの Identity Assertion JWT Authorization Grant（ID-JAG とも呼ばれる）に交換するために、IdP にトークン交換リクエストを送信します。IdP はリクエストを検証し、Acme の IT 管理者によって定義された XAA ポリシーを確認します。
3. XAA ポリシーで許可されている場合、IdP は ID-JAG を Requesting App に返します。
4. Requesting App は、ID-JAG を用いて Resource App（Todo0）の認可サーバーにトークンリクエストを行います。
5. Resource App の認可サーバーは、IdP との OpenID Connect フローでも使用している公開鍵を使って ID-JAG を検証します。有効な場合、認可サーバーはアクセストークンを返します。
6. Requesting App は、アクセストークンを使用して Resource App の API にリクエストを送信します。

XAA フローを活用することで、Acme の IT 管理者が定義するポリシーによって Agent0 から Todo0 へのアクセスが制御され、エンドユーザー側でのリダイレクトや操作は一切不要になります。

<div id="beta-limitations">
  ## ベータ版の制限事項
</div>

XAA ベータ版には、次の制限があります。

* Requesting App は、機密クライアントかつ Auth0 テナント内のファーストパーティアプリである必要があります。SPA やネイティブアプリなどのパブリッククライアントはサポートされません。
* 委任管理はサポートされません。エンタープライズ顧客が Auth0 テナント上で SSO 接続を直接設定することはできません。[Self-Service SSO](/docs/ja-JP/authenticate/enterprise-connections/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` が返されます。

<div id="rate-limits">
  ## レート制限
</div>

XAA Beta では、Auth0 テナントの `/token` エンドポイントでの ID-JAG エクスチェンジにはレート制限が適用され、1 秒あたり 5 リクエストまでとなります。