> ## 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. > MCP の Enterprise-Managed Authorization を標準でサポートし、一元化されたエンタープライズ管理機能を使用して、AI agent とアプリケーション間、およびアプリケーション間の接続を作成・管理します。 # Cross App Access (XAA) Resource App 向けの Cross App Access (XAA) は**早期アクセス**です。Enterprise、B2B Pro、B2B Essential のお客様は、エンタープライズ接続 の機能として利用できます。Free tenant では、トライアル期間中にお試しいただくこともできます。この機能を使用すると、Okta の[マスターサブスクリプション契約](https://www.okta.com/legal/?_gl=1*51wq70*_gcl_au*NzczNzM1NjYyLjE3ODE3NzY0MDI.*_ga*MTE3ODU0MTY1Ny4xNzgxNzc2NDAy*_ga_QKMSDV5369*czE3ODQ1NTM3ODckbzgyJGcxJHQxNzg0NTU0NzIxJGo1OCRsMCRoMA..)に定められた該当する Free Trial 条項に同意したものとみなされます。 エンタープライズ環境で AI agent やアプリケーションを他のリソースに接続すると、主に 2 つの課題が生じます。IT 部門によるデータ共有の可視性が不十分になることと、ユーザーに繰り返し同意を求めるフローが発生することです。 Cross App Access (XAA) は、AI agent などの SaaS アプリケーションがユーザーに代わって接続する際のアクセス制御を、IT 管理者が一元的に定義できるようにすることで、これらの課題に対処します。管理者は Okta Admin Console などの一元化されたダッシュボードでこれらの接続を管理できるため、エンドユーザーにとって煩わしい OAuth 同意プロンプトが不要になります。その結果、組織のセキュリティ、ガバナンス、ユーザーエクスペリエンスが向上します。 XAA は、現在策定中の OAuth 拡張である [Identity Assertion Authorization Grant](https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/) を実装しています。これにより、アプリケーションや AI agent などの Requesting App は、エンドユーザーに代わって別のアプリケーションの API (Resource App) を呼び出すために、エンタープライズ IdP から安全な token を取得できます。これは、アプリケーション間接続と agent からアプリケーションへの接続の両方に対応します。XAA は、[MCP client](https://modelcontextprotocol.io/) として動作する AI agent が Resource App によって公開された MCP server にシームレスに接続できるようにする、MCP の [Enterprise-Managed Authorization](https://blog.modelcontextprotocol.io/posts/enterprise-managed-auth/) 拡張を実現するプロトコルソリューションです。詳細は、[仕組み](#how-it-works)を参照してください。
## 主なメリット
XAA は、エンタープライズエコシステムに関わるすべての役割に重要なメリットをもたらします。 * Enterprise IT 管理者向け: エンタープライズデータやユーザーデータへのアプリケーションアクセスを一元的に制御・可視化し、ポリシーを適用。 * SaaS プロバイダーおよび開発者向け: エコシステムの成長を促進する、エンタープライズ AI のための標準化された安全な連携。 * エンドユーザー向け: アプリケーション間をスムーズかつシームレスに接続し、複雑な OAuth 同意フローを不要にします。
## ユースケース
XAAの一般的なユースケースは次のとおりです。 * Enterprise-Managed Authorization (agent-to-app) ：従業員は、MCP Clientとして動作するAI agentを使用して、カレンダーアプリから情報を読み取り、エンタープライズメッセージングアプリに更新を投稿します。従業員がリダイレクトフローや同意プロンプトを経ることなく、エンタープライズのアクセスポリシーで承認されていれば、agentはMCP Serverとして公開されたカレンダーアプリとメッセージングアプリのAPIをXAAで安全に呼び出します。 * SaaSアプリケーションの接続 (app-to-app) ：前の例では、エンタープライズのカレンダーアプリとメッセージングアプリはいずれもXAAをサポートしています。従業員は、ユーザーのリダイレクトや同意を必要とせず、エンタープライズのアクセスポリシーに従って、メッセージングアプリからカレンダーアプリのAPIにシームレスに接続できます。
## 仕組み
XAA フローには、次のアクターが関与します。 * Requesting App: リソースへのアクセスを必要とするアプリケーションまたは AI agent。 * Resource App: 保護されたリソースを所有し、API を介して公開するアプリケーション。 * Enterprise IdP: Okta など、従業員を認証する IdP。 エンドユーザーがエンタープライズ IdP で認証されると、Requesting App はユーザーに代わって Resource App へのアクセスを要求するため、エンタープライズ IdP に問い合わせます。クロスアプリ接続が許可されているかを確認するためにアクセス ポリシーを適用した後、エンタープライズ IdP は ID-JAG と呼ばれるアサーションを生成します。Requesting App はこのアサーションを Resource App に提示し、API 利用のためのアクセストークンを取得します。  次の図で、Acme は、Requesting App (Agent0) および Resource App (Todo0) にアクセスする従業員が、Okta などのエンタープライズ IdP で認証されるエンタープライズ顧客です。 * Resource App (Todo0) の認可サーバーは、OIDC を介してエンタープライズ IdP とフェデレーションされているため、その IdP で認証されたエンドユーザー向けのアクセストークンを生成できます。 * Requesting App (Agent0) は、Resource App の認可サーバーからアクセストークンを要求するための有効な client\_id と資格情報を持つ OAuth 2.0 クライアントとして、Resource App の認可サーバーに登録されています。 * Acme の IT 管理者は、Agent0 と Todo0 間の XAA アクセス制御を定義しています。 XAA を機能させるには、Auth0 Resource App の認可サーバーとエンタープライズ IdP の両方を設定する必要があります。まず [Environment Setup](/docs/ja-jp/ai-agents-mcp/cross-app-access/set-up-xaa-test-environment) で Auth0 側を設定し、次に、フェデレーションする IdP と使用するプロトコルに応じて、IdP Integration の該当するガイド ([Okta as OIDC IdP](/docs/ja-jp/ai-agents-mcp/cross-app-access/idp/okta-as-oidc-idp) または [Okta as SAML IdP](/docs/ja-jp/ai-agents-mcp/cross-app-access/idp/okta-as-saml-idp)) を確認してください。
## エンドツーエンドの XAA フロー
Acme の例では、エンドツーエンドの XAA フローは次の手順で進行します。 1. Acme の従業員は、エンタープライズ IdP を使用した SSO により Requesting App (Agent0) にログインします。Requesting App は、Acme の従業員のアイデンティティを検証するために ID トークンを取得します。 2. Requesting App は IdP にトークン交換リクエストを送信し、ID トークンを、ID-JAG とも呼ばれるクロスドメイン Identity Assertion JWT Authorization Grant と交換します。IdP はリクエストを検証し、Acme の IT Admin が定義した XAA ポリシーを確認します。 3. XAA ポリシーで許可されている場合、IdP は ID-JAG を Requesting App に返します。 4. Requesting App は ID-JAG を使用して、Resource App 認可サーバーにトークンリクエストを送信します。 5. Resource App 認可サーバーは、IdP との OpenID Connect フローでも使用する公開鍵で ID-JAG を検証します。有効であれば、認可サーバーはアクセストークンを返します。 6. Requesting App はアクセストークンを使用して、Resource App の API にリクエストを送信します。 Requesting App と Resource App は、この SSO ステップでエンタープライズ IdP とフェデレーションするために、それぞれ OIDC または SAML を使用できます。各ケースでの XAA フローの仕組みについては、[エンドツーエンドテスト](/docs/ja-jp/ai-agents-mcp/cross-app-access/end-to-end-testing)を参照してください。 XAA フローを活用することで、Acme の IT Admin が定義したポリシーにより Agent0 から Todo0 へのアクセスを制御でき、エンドユーザーのリダイレクトや操作は不要です。
## 早期アクセスの制限事項
XAA 早期アクセスには、以下の制限があります。 * Enterprise IdP の発行者ごとに設定できる XAA 対応の接続は 1 つだけです。たとえば、同じ Okta テナントを複数の XAA 対応エンタープライズ接続に使用することはできません。 * 組織のサポートには制限があります。 * 接続は組織と 1 対 1 で割り当てられます。複数の組織を XAA アクセス用に同じ接続にマッピングすることはできません。 * Requesting App で Organizations の使用を必須にするよう設定している場合、ユーザーは事前に対象の organization のメンバーである必要があります。 * 動的なユーザー作成には対応していません。ユーザーは、設定済みのエンタープライズ接続を使用して事前に Resource App にログインしている必要があります。そうでない場合、ID-JAG アサーションをアクセストークンと交換する request は、`User not found error` で失敗します。
## レート制限
XAA 早期アクセスでは、Auth0 テナントの `/token` エンドポイントにおける ID-JAG 交換は、テナント全体の Authentication API レート制限の最大 50% までに制限されます。サブスクリプションプランごとの正確な制限を含む詳細については、[レート制限の構成](/docs/ja-jp/troubleshoot/customer-support/operational-policies/rate-limit-policy/rate-limit-configurations)を参照してください。