Skip to main content
エンタープライズ環境で AI agent やアプリケーションを他のリソースに接続すると、主に 2 つの課題が生じます。IT 部門によるデータ共有の可視性が不十分になることと、ユーザーに繰り返し同意を求めるフローが発生することです。 Cross App Access (XAA) は、AI agent などの SaaS アプリケーションがユーザーに代わって接続する際のアクセス制御を、IT 管理者が一元的に定義できるようにすることで、これらの課題に対処します。管理者は Okta Admin Console などの一元化されたダッシュボードでこれらの接続を管理できるため、エンドユーザーにとって煩わしい OAuth 同意プロンプトが不要になります。その結果、組織のセキュリティ、ガバナンス、ユーザーエクスペリエンスが向上します。 XAA は、現在策定中の OAuth 拡張である Identity Assertion Authorization Grant を実装しています。これにより、アプリケーションや AI agent などの Requesting App は、エンドユーザーに代わって別のアプリケーションの API (Resource App) を呼び出すために、エンタープライズ IdP から安全な token を取得できます。これは、アプリケーション間接続と agent からアプリケーションへの接続の両方に対応します。XAA は、MCP client として動作する AI agent が Resource App によって公開された MCP server にシームレスに接続できるようにする、MCP の Enterprise-Managed Authorization 拡張を実現するプロトコルソリューションです。詳細は、仕組みを参照してください。

​
主なメリット

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 フローの仕組みについては、エンドツーエンドのテストを参照してください。
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 を Requesting App として設定する

Auth0 テナントを Requesting App として設定すると、AI agent や SaaS アプリケーションが OAuth 同意フローを経ることなく、ユーザーに代わってサードパーティ API を呼び出せるようになります。アクセスの可否は、企業の IT 管理者が IdP で定めた policy によって制御されます。アプリケーションが XAA を通じて取得した tokens は、Auth0 が 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 をお読みください。
  • 組織のサポートには制限があります。
    • 接続は組織と 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 レート制限が適用されます。サブスクリプションプランごとの正確な制限を含む詳細については、レート制限の構成を参照してください。