Cross App Access (XAA)

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

このガイドは、エンタープライズIDプロバイダー (IdP) としてOktaを使用し、テストに利用できるOktaテナントに管理者としてアクセスできることを前提としています。お持ちでない場合は、Oktaテナントを作成して設定するを参照してください。

エンタープライズ環境でサードパーティアプリやAIエージェントを接続すると、主に2つの問題が生じます。IT部門がデータ共有を十分に可視化できないことと、ユーザーが同意フローを何度も繰り返さなければならないことです。

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

XAAは、策定中のOAuth拡張仕様であるIdentity Assertion Authorization Grantを実装しています。これにより、AIエージェントまたはアプリケーション (Requesting App) は、エンタープライズIDプロバイダー (IdP) を通じて安全なトークンを取得できます。このトークンを使用すると、Requesting Appはエンドユーザーに代わって別のアプリケーション (Resource App) のAPIを呼び出せます。詳しくは、仕組みを参照してください。

​

主なメリット

XAA は、企業エコシステムにおけるあらゆる役割に主要なメリットをもたらします。

• エンタープライズ IT 管理者向け: アプリケーションによる企業データやユーザーデータへのアクセスを一元的に制御・可視化し、ポリシーを適用できます。
• SaaS プロバイダーおよび開発者向け: エコシステムの成長を後押しする、エンタープライズAI向けの標準化された安全な統合。
• エンドユーザー向け: アプリケーション間の接続を簡素化してシームレスにし、複雑な OAuth 同意フローを不要にします。

​

ユースケース

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

• AI エージェントをエンタープライズアプリケーションに接続する: 従業員が AI エージェントを使ってカレンダーアプリの情報を読み取り、エンタープライズメッセージングアプリに自身の予定状況の更新を投稿します。従業員にリダイレクトフローや同意プロンプトを経由させる代わりに、企業のアクセスポリシーで承認されている場合、AI エージェントは XAA を使用してエンタープライズ IdP からアクセストークンを取得し、カレンダーアプリとメッセージングアプリの両方の API を安全に呼び出します。
• SaaS アプリケーションを接続する: 前の例では、エンタープライズカレンダーとメッセージングアプリはどちらも XAA をサポートしています。従業員は、企業のアクセスポリシーに従いながら、ユーザーのリダイレクトや同意なしに、メッセージングアプリを接続してカレンダーアプリの API にシームレスにアクセスできます。

​

仕組み

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

• 要求元アプリ: リソースへのアクセスを必要とするアプリケーションまたは AI エージェント。
• リソースアプリ: 保護されたリソースを所有し、API を介して公開するアプリケーション
• Enterprise IdP: Okta など、従業員を認証する IdP。

エンドユーザーが エンタープライズ IdP で認証されると、要求元アプリ は エンタープライズ IdP に対して、ユーザーに代わって リソースアプリ へのアクセスを要求します。次に、クロスアプリ接続が許可されているかどうかを確認するためにアクセスポリシーが適用され、エンタープライズ IdP は ID-JAG と呼ばれるアサーションを生成します。要求元アプリ はその ID-JAG を リソースアプリ に提示し、API の利用に必要なアクセストークンを取得します。 

次の図では、Acme は企業顧客であり、その従業員は Okta などの Enterprise IdP で認証して、要求元アプリ (Agent0) と リソースアプリ (Todo0) にアクセスします。

• リソースアプリ (Todo0) の認可サーバーは、OIDC を介して Enterprise IdP とフェデレーションされているため、その IdP で認証されたエンドユーザー向けのアクセストークンを生成できます。
• 要求元アプリ (Agent0) は、OAuth 2.0 クライアントとして リソースアプリ の認可サーバーに登録されており、有効な client_id と、リソースアプリ の認可サーバーにアクセストークンを要求するための認証情報を備えています。
• Acme の IT 管理者は、Agent0 と Todo0 の間の XAA アクセス制御を定義しています。

​

エンドツーエンドの XAA フロー

Acme の例で見ると、エンドツーエンドの XAA フローは次の手順で進みます。

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

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

​

Beta の制限事項

XAA Beta には、次の制限事項があります。

• 要求元アプリ は、Auth0 テナント内の confidential client であり、かつファーストパーティアプリである必要があります。SPA や Native App などの public client はサポートされていません。
• 委任管理はサポートされていません。エンタープライズ顧客は、Auth0 テナント上で SSO 接続を直接設定できません。セルフサービス SSO のサポートは、今後のリリースで予定されています。
• 上流の IdP 発行者ごとに、XAA 対応の接続は 1 つしか設定できません。同じ Okta テナントを複数の XAA 対応エンタープライズ接続で使用することはできません。
• 組織のサポートには制限があります。
  • 接続と組織は 1:1 で割り当てられます。XAA アクセスでは、複数の組織を同じ接続にマッピングすることはできません。
  • 要求元アプリ が組織の使用を必須とするよう設定されている場合、ユーザーは事前に対象の組織のメンバーである必要があります。
• ID-JAG リクエストで resource パラメーターが指定されていない場合、対象 API は tenant.default_audience によって決定されます。
• 動的なユーザー作成はサポートされていません。ユーザーは、設定された Okta 接続を使用して、事前に リソースアプリ にログインしている必要があります。そうでない場合、ID-JAG アサーションをアクセストークンに交換するリクエストは、User not found error で失敗します。

​

レート制限

XAA Beta では、Auth0 テナントの /token エンドポイントでの ID-JAG 交換は、5 RPS に制限されます。