> ## Documentation Index > Fetch the complete documentation index at: https://docs-staging-feat-init-gt-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) export const ReleaseStageNotice = ({feature, stage, plans, contact, terms}) => { const stageTextMap = { "beta": "Beta", "ea": "早期アクセス" }; const stageText = stageTextMap[stage] || "製品リリース段階"; const prsLink = "/docs/troubleshoot/product-lifecycle/product-release-stages"; const linkify = (text, url) => { return {text}; }; const includeDetails = (plans, contact, terms) => { const hasDetails = terms || plans || contact; if (!hasDetails) return null; return {plans && <>この機能は{linkify(`${plans}プラン`, "https://auth0.com/pricing")}でご利用いただけます。 } {contact && "参加をご希望の場合は、" + contact + "までお問い合わせください。 "} {terms && <>この機能を使用することにより、Oktaの該当する無料トライアル規約および{linkify("Master Subscription Agreement", "https://www.okta.com/legal")}に同意したものとみなされます。} ; }; return {feature}機能は現在、{linkify(stageText, prsLink)}です。 {includeDetails(plans, contact, terms)} ; }; エンタープライズ環境で 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 フロー

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 管理者が定義した 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 管理者が定義したポリシーにより Agent0 から Todo0 へのアクセスを制御でき、エンドユーザーのリダイレクトや操作は不要です。

はじめに

Auth0 は XAA フロー の双方をサポートしています。エコシステムにおける役割に応じて、Auth0 テナントを Resource App、Requesting App、またはその両方として構成できます。

Auth0 を Resource App として設定する

SaaS アプリケーションが受信した ID-JAG リクエストを受け付け、API 用のアクセストークンを発行できるように、Auth0 テナントを Resource App の認可サーバーとして設定します。エンドユーザーの同意フローを介さずに、エンタープライズの AI agent やアプリケーションから安全に API を利用してもらいたい SaaS プロバイダーや API オーナーには、この方法が適しています。 | 参照先 | 目的 | | ------------------------------------------------------------------------------------------ | ------------------------------------------------ | | [Auth0 を Resource App として設定する](/docs/ja-jp/ai-agents-mcp/cross-app-access/resource-app) | 必要な作業と着手すべきポイントを把握する。 | | [環境の設定](/docs/ja-jp/ai-agents-mcp/cross-app-access/set-up-xaa-test-environment) | API を設定し、Auth0 テナントにテスト用の Requesting App を登録する。 | | [Okta を OIDC IdP として使用する](/docs/ja-jp/ai-agents-mcp/cross-app-access/idp/okta-as-oidc-idp) | Okta を Resource App の OIDC エンタープライズ IdP として設定する。 | | [Okta を SAML IdP として使用する](/docs/ja-jp/ai-agents-mcp/cross-app-access/idp/okta-as-saml-idp) | Okta を Resource App の SAML エンタープライズ IdP として設定する。 | | [エンドツーエンドのテスト](/docs/ja-jp/ai-agents-mcp/cross-app-access/end-to-end-testing) | Auth0 とエンタープライズ IdP の両方を設定した後、XAA フロー全体をテストする。 |

Auth0 を Requesting App として設定する

Auth0 テナントを Requesting App として設定すると、AI agent や SaaS アプリケーションが OAuth 同意フローを経ることなく、ユーザーに代わってサードパーティ API を呼び出せるようになります。アクセスの可否は、企業の IT 管理者が IdP で定めた policy によって制御されます。アプリケーションが XAA を通じて取得した tokens は、Auth0 が [Token Vault](/docs/ja-jp/secure/tokens/token-vault) に保存して再利用します。 | 参照するドキュメント | 目的 | | ------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------- | | [Auth0 を Requesting App として設定する](/docs/ja-jp/ai-agents-mcp/cross-app-access/requesting-app) | 必要な作業と着手すべき箇所を把握する。 | | [環境の設定](/docs/ja-jp/ai-agents-mcp/cross-app-access/requesting-app/set-up-xaa-test-environment) | テスト用の Resource App と、自分のテナントと Resource App テナントの間の OIDC 接続を設定する。 | | [Okta を OIDC IdP として使用する](/docs/ja-jp/ai-agents-mcp/cross-app-access/requesting-app/idp/okta-as-oidc-idp) | Requesting App の OIDC エンタープライズ IdP として Okta を設定する。 | | [Token Vault を使用した Cross App Access](/docs/ja-jp/secure/call-apis-on-users-behalf/token-vault/xaa-with-token-vault) | アプリケーションが XAA を通じて取得したアクセストークンを保存・再利用するために Token Vault を設定する。 |

早期アクセスの制限事項

XAA 早期アクセスには、以下の制限があります。 * Enterprise IdP の発行者ごとに、Resource App に設定できる XAA 対応の接続は 1 つだけです。たとえば、同じ Okta テナントを複数の XAA 対応エンタープライズ Resource App 接続に使用することはできません。 * XAA Requesting App をサポートする Token Vault では、token exchange の時点でユーザーのプロファイルにリンクされた有効な XAA 対応アイデンティティがちょうど 1 つ必要です。詳細については、[Token Vault を使用した Cross App Access](/docs/ja-jp/secure/call-apis-on-users-behalf/token-vault/xaa-with-token-vault) をお読みください。 * 組織のサポートには制限があります。 * 接続は組織と 1 対 1 で割り当てられます。複数の組織を XAA アクセス用に同じ接続にマッピングすることはできません。 * Requesting App で Organizations の使用を必須にするよう設定している場合、ユーザーは事前に対象の organization のメンバーである必要があります。 * 動的なユーザー作成には対応していません。ユーザーは、設定済みのエンタープライズ接続を使用して事前に Resource App にログインしている必要があります。そうでない場合、ID-JAG アサーションをアクセストークンと交換する request は、`User not found` エラーで失敗します。

レート制限

XAA 早期アクセスでは、Auth0 テナントの `/token` エンドポイントにおける ID-JAG 交換は、テナント全体の Authentication API レート制限の最大 50% までに制限されます。Private Cloud では、XAA Requesting App のトークン交換に、各サブスクリプションプランの Token Vault レート制限が適用されます。サブスクリプションプランごとの正確な制限を含む詳細については、[レート制限の構成](/docs/ja-jp/troubleshoot/customer-support/operational-policies/rate-limit-policy/rate-limit-configurations)を参照してください。