Okta Cross App Access（XAA）とは？ID-JAGの仕組みとAgent SSO GA後の導入判断【2026年10月】

Okta Cross App Access（XAA）は、AIエージェントや業務アプリが別のアプリのAPIを呼ぶときの許可を、利用者ごとの同意画面ではなく企業のIdP（アイデンティティプロバイダー）のポリシーで決める仕組みです。中身はIETFで策定中のOAuth拡張「Identity Assertion JWT Authorization Grant（ID-JAG）」で、Oktaは2026年8月にこれを「Agent SSO」として全顧客向けにGA（一般提供）にしました。この記事では、ID-JAGの2段階のトークン交換をリクエスト例つきで追い、Okta・Auth0・MCPそれぞれの2026年10月時点の提供状況と、導入を見送るべき条件を整理します。

まとめ：XAAの正体と2026年10月時点の提供状況

• XAAとID-JAGの関係：ID-JAGはIETF OAuth WGの草案（最新はdraft-04・2026年5月21日）で、草案自身が「Cross-App Access（XAA）とも呼ばれる」と書いています。RFCにはまだなっていません。
• 仕組み：アプリはSSOで得たIDトークンをIdPに渡してID-JAGを受け取り（RFC 8693のToken Exchange）、それを相手アプリの認可サーバーに出してアクセストークンに換えます（RFC 7523のJWT Bearer）。許可するかどうかはIdPのポリシーが決めます。
• Okta：2026年8月17日に本番環境でGAとなり、8月24日に「Agent SSO」として発表されました。中核のOkta SSOプランに追加料金なしで含まれますが、ID-JAGは利用者1人・Resource App 1つにつき月250個のソフト上限があります。エージェント同士の接続やライフサイクル管理は別サブスクリプションのOkta for AI Agentsが必要です。
• Auth0：Resource App側のXAAは2026年7月27日からOpen Early Accessで、Enterprise・B2B Pro・B2B Essentialプランなら追加料金なしで本番利用できます。Requesting App側もEarly Accessです。
• MCP：同じ仕組みが「Enterprise-Managed Authorization」拡張として、2026年6月18日にStable（安定版）化が発表されました。コア仕様ではなく任意採用の拡張です。
• 判断：Oktaを全社IdPにしていて、AIエージェントが静的APIキーで社内SaaSにつながっている企業は検証を始める価値があります。連携先のSaaSが未対応の接続や、対象アプリが同じIdPを信頼していない接続では、まだ効果が出ません。

XAA・ID-JAG・Enterprise-Managed Authorizationの呼び分け

同じ仕組みが文脈ごとに3つの名前で呼ばれているため、資料を読むときに混乱しやすくなっています。対応関係は次のとおりです。

ID-JAGの草案は2025年9月8日にWG文書（-00）として採択され、2026年5月21日の-04まで改訂が続いています。著者はOktaのAaron Parecki氏、Ping IdentityのBrian Campbell氏ほかで、Okta以外のIdPやSaaSも実装できるオープンな仕様です。「xaa rfc」で調べる人もいますが、RFC番号はまだ付いていません。-04の有効期限は2026年11月22日で、RFCになるまでにパラメーター名や処理規則が変わる余地があります。

AIエージェントで利用者ごとのOAuth同意が破綻する理由

通常のOAuthでは、アプリAがアプリBのAPIを使うとき、利用者がBの同意画面で「許可」を押します。人が1つのツールをつなぐだけならこれで足りますが、1つのAIエージェントが社内の10個のSaaSを呼び、それを数百人が使うと、同意の判断が数千回に分散します。その結果、IT管理者は「どのエージェントが、誰の権限で、どのアプリに触れているか」を把握できなくなります。

同意画面を避けるために、エージェントへ共有のAPIキーやサービスアカウントの長期シークレットを持たせる運用も広がりました。この方式では誰の操作かがAPI側から見えず、退職者のアクセスを止めるにもキーを1本ずつ失効させる必要があります。XAAは、この許可の判断を、社員がすでにSSOでログインしているIdPに集めます。

ID-JAGの2段階トークン交換の処理フロー

以下はdraft-04の第4章に沿った流れです。登場するのは、APIを呼びたい側（Requesting App／Client）、企業のIdP、呼ばれる側の認可サーバー（Resource Authorization Server）の3者です。

前提となる同一IdPでのSSO

ID-JAGは、Requesting AppとResource Appの両方が同じ企業IdPでシングルサインオン（SSO）済みであることを前提にしています。Resource側の認可サーバーは、SSOですでに信頼しているIdPが署名したID-JAGだから受け入れる、という信頼の組み立てです。そのため最初の手順は、Requesting AppがOpenID ConnectまたはSAMLで利用者をログインさせ、IDトークン（またはSAMLアサーション）を持つことです。

第1段階：IdPへのToken ExchangeによるID-JAG取得

Requesting AppはIdPのトークンエンドポイントに、RFC 8693のToken Exchangeを送ります。requested_token_typeにID-JAGを、audienceに相手の認可サーバーの発行者識別子を指定するのが要点です。

POST /oauth2/token HTTP/1.1
Host: acme.idp.example
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&requested_token_type=urn:ietf:params:oauth:token-type:id-jag
&audience=https://acme.chat.example/
&resource=https://api.chat.example/
&scope=chat.read+chat.history
&subject_token=eyJraWQiOiJzMTZ0cVNtODhwREo4VGZCXzdrSEtQ...
&subject_token_type=urn:ietf:params:oauth:token-type:id_token
&client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer
&client_assertion=eyJhbGciOiJSUzI1NiIsImtpZCI6IjIyIn0...

上の例はdraft-04の4.3.1節の説明用の例で（改行とトークンの省略があるため、そのままでは送信できません）、Requesting App自身のIdPへのクライアント認証にJWT（client_assertion）を使っています。IdPはここで管理者のポリシーを評価し、許可する場合だけID-JAGを返します。要求されたスコープを絞って発行することもでき、その場合は応答のscopeに実際に許可した値が入ります。

{
  "issued_token_type": "urn:ietf:params:oauth:token-type:id-jag",
  "access_token": "eyJhbGciOiJIUzI1NiIsI...",
  "token_type": "N_A",
  "scope": "chat.read chat.history",
  "expires_in": 300
}

フィールド名はaccess_tokenですが、中身はアクセストークンではありません。Token Exchangeの応答形式に合わせた歴史的な理由によるもので、token_typeがN_Aになっているのはそのためです。ID-JAGそのものではAPIを呼べず、次の段階の引換券としてだけ使います。

第2段階：jwt-bearerによるResource側アクセストークン取得

Requesting Appは受け取ったID-JAGを、相手の認可サーバーにRFC 7523のJWT Bearerグラントとして提示します。ここで使うgrant_typeはjwt-bearerで、第1段階のtoken-exchangeとは別物です。第2段階を実装するときは、第1段階のgrant_typeを流用しないでください。

POST /oauth2/token HTTP/1.1
Host: acme.chat.example
Authorization: Basic yZS1yYW5kb20tc2VjcmV0v3JOkF0XG5Qx2
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
&assertion=eyJhbGciOiJIUzI1NiIsI...

Requesting Appは、Resource側の認可サーバーに登録した自分のクライアント資格情報で認証します。検証に通れば通常のBearerアクセストークンが返り、以降は普通のOAuthと同じようにAPIを呼びます。

Resource側が検証するtypヘッダーとクレーム

ID-JAGは署名付きのJWTで、ヘッダーのtypはoauth-id-jag+jwtでなければなりません（MUST）。Resource側の認可サーバーは、署名と発行者に加えて主に次のクレームを確認します。

Resource側がID-JAGに対応しているかどうかは、認可サーバーのメタデータのauthorization_grant_profiles_supportedにurn:ietf:params:oauth:grant-profile:id-jagが載っているかで判定できます。ただし草案は、この値が載っていても特定の発行者やテナントからの要求を必ず受け付けるという意味ではない、と念押ししています。

refresh_tokenを返さない設計と期限切れ時の再取得

draft-04は、ID-JAGと引き換えにアクセストークンを出すときにResource側がリフレッシュトークンを返さないよう求めています（SHOULD NOT）。アクセストークンが切れたら、Requesting Appは同じID-JAGを再提出でき、ID-JAGも切れていればIdPに新しいID-JAGを取りに行きます。Resource側に長期のリフレッシュトークンが残らないため、管理者がIdPで接続を止めると、新しいID-JAGの発行はそこで止まります。ただし、発行済みのID-JAGとアクセストークンは期限まで使える可能性があります。草案の例ではID-JAGのexpires_inが300秒、アクセストークンが86,400秒（24時間）です。停止を早く効かせたい場合は、Resource側のアクセストークンの寿命を短くするか、失効の仕組みを用意する必要があります。

なお-04では、IdPが発行したリフレッシュトークンを第1段階のsubject_tokenに使うことも認めています（MAY）。その場合、IdPは通常のrefresh_tokenグラントと同じ検証（期限切れ・失効していないか等）を行わなければならず（MUST）、ID-JAGには現在の利用者属性とポリシーを反映することが望ましいとされています（SHOULD）。IDトークンが切れるたびにSSOをやり直さずに済み、利用者が無効化されていれば、IdPはその時点で新しいID-JAGの発行を拒否できます。

Okta Agent SSOとしての提供状況と料金

2025年6月の発表から2026年8月のGAまでの経緯

Agent SSO・Okta for AI Agents・OIGで分かれる機能の範囲

Oktaの2026年8月24日の発表では、Agent SSOは中核のOkta SSOに追加料金なしで含まれます。XAA対応のエージェントが企業アプリに接続すると、Universal Directoryに人間の従業員と並ぶIDとして登録され、保存済みの資格情報の代わりに短命のトークンが発行されます。Oktaのサポート記事（2026年9月30日更新）によると、管理画面は［Directory］→［AI Agents］で、作業にはスーパー管理者の権限が必要です。AI Agent Admin Roleでは操作できません。

どこからが有料かは次のように分かれます。

• Agent SSO（追加料金なし）：エージェントをワークロードプリンシパルとして登録し、XAA対応のOINアプリや、XAA対応の自社SAML・OIDCアプリへ接続する。
• Okta for AI Agents（別サブスクリプション）：エージェント同士の接続、ライフサイクルのガバナンス、未登録のシャドーAIエージェントの検出。2026年5月からGA。
• 人間の所有者の割り当て：Okta for AI AgentsかOkta Identity Governance（OIG）のどちらかが必要。

エージェントがアプリを呼ぶだけなら追加契約はいりませんが、利用量には目安があります。Oktaのサポート記事（2026年8月18日更新）によると、SSOプランでのXAAは利用者1人・Resource App 1つにつき月250個のID-JAGまでのソフト上限です。超えても当該請求期間中は遮断されませんが、継続的に多い場合は追加容量かOkta for AI Agentsの購入が案内されています。集計は注文書の開始日を基準に毎月リセットされ、未使用分は繰り越されません。仮にエージェントが1時間ごとにID-JAGを取り直す設計にすると、1人・1アプリで月720個前後になり上限を超えます。ID-JAGの再取得の頻度は、設計の段階で見積もっておく必要があります。「どのエージェントの責任者が誰か」を台帳として管理したい場合は、OIGかOkta for AI Agentsの契約が前提になります。Okta全体のプラン構成はOkta（オクタ）とは？認証の仕組み・機能・料金・セキュリティを2026年版で解説で整理しています。

対応を表明した企業とAnthropic Claudeとの連携

2026年6月23日の発表で、Oktaは25件を超えるXAA連携を公表しました。発表での分類は次のとおりです（Zoomは両側に入っています）。

• Requesting App側：Claude（Anthropic）、Cursor、Docker、VS Code、Zoom
• Resource App側：Asana、Atlassian、Canva、Datadog、Figma、Glean、Granola、Linear、Serval、Slack、Supabase、Zoom
• ID基盤・ゲートウェイ：Aquera、Archestra.AI、Cloudflare、Keycard、Keycloak、MintMCP、Scalekit、Stytch、WorkOS、Zuplo

このうちClaudeについては、2026年6月18日にClaude Enterprise向けのベータが発表されています。IT管理者がMCPコネクタを組織単位で一度だけ認可し、Oktaのグループやロールで利用範囲を絞り、退職時にはOkta側でアクセスを取り消せる、という内容です。名前が挙がったコネクタはAsana、Atlassian、Canva、Figma、Granola、Linear、Supabaseでした。発表時点ではベータで、広く提供する時期は「予定」と書かれるにとどまっています。

Auth0でのXAA対応とResource App側の条件

自社のSaaSをXAAの「呼ばれる側」にしたい開発者向けに、Auth0は2026年7月27日にResource App向けのXAAをOpen Early Accessにしました。Auth0の変更履歴によると、Enterprise・B2B Pro・B2B EssentialプランのEnterprise Connections経由なら追加料金なしで本番利用でき、Freeテナントでは試用期間中に試せます。企業IdPはSAML・OIDCの両方に対応しています。Auth0側がRequesting Appになる機能もEarly Accessで、OIDC接続とOkta Workforce接続に対応しています。

Auth0のドキュメントにはEarly Access期間中の制約が複数載っています。最初の接続でつまずきやすいのは次の3点です。

• Resource Appで、企業IdPの発行者1つにつきXAA有効な接続は1つまで。
• 利用者が事前にその企業接続でResource Appにログインしていないと「User not found」エラーになる。
• Auth0テナントの/tokenでのID-JAG交換は、テナント全体のAuthentication APIのレート制限の最大50%まで。

2点目は運用上の落とし穴です。導入初日に、まだ一度もSSOでログインしていない社員のエージェントが失敗するので、パイロットでは対象者に先に一度ログインしてもらう手順を入れておく必要があります。Auth0側のAIエージェント向け機能の全体像はAuth0 for AI Agentsとは？GA後の4機能とCIBA・Token Vault実装・料金を解説【2026年版】にまとめています。

MCPのEnterprise-Managed Authorization拡張とSDKの対応

MCP（Model Context Protocol）は、エージェントがツールやデータに接続する方法を定める規格です。誰がどのMCPサーバーを使ってよいかを企業が決める部分は、拡張「Enterprise-Managed Authorization」（識別子io.modelcontextprotocol/enterprise-managed-authorization）が担います。これはID-JAGをMCPに当てはめたプロファイルで、MCPクライアントがRequesting App、MCPサーバーの認可サーバーがResource Authorization Serverに当たります。

この拡張は2025年10月にext-authリポジトリへ追加され、draft-04に内容を合わせたうえで、2026年6月18日にMCP公式ブログでStable化が発表されました。リポジトリの説明では、拡張は任意採用（Optional）で、コアプロトコルの動作を変えないものと位置づけられています。対応していないMCPサーバーには、従来の利用者ごとのOAuthでつなぐことになります。MCPクライアントの登録方式についてはCIMD（Client ID Metadata Documents）とは？MCPでDCRに代わるOAuthクライアント登録の仕組みと実装【2026年9月時点】で解説しています。

公式SDKのID-JAG関連の実装は次のとおりです（2026年10月時点の各リポジトリのmainブランチ）。採用時は、使うリリースのドキュメントで対応範囲を確認してください。

Javaで組む場合は、使うSDKや認証ライブラリがID-JAGに対応しているかを先に確かめ、足りなければToken ExchangeとJWT Bearerの2つのリクエストを自前で実装します。MCPサーバーに権限設計を組み込む手順全般はAIエージェントにMCPで外部ツールを接続する実装手順とは？tool定義・権限・認可の設計を解説【2026年版】を参照してください。

Oktaで動作を確かめる手順：xaa.devとIntegrator Free Plan

本番テナントに触れずに試す方法は2つあります。1つ目は、Oktaが2026年1月に公開した無料の検証環境xaa.dev（ベータ）です。IdPテナントを用意しなくても、Requesting Appを登録して2段階の交換を手元のサンプルで動かせます。2つ目は、SSO機能を持つOkta組織（Okta Integrator Free Planでも可）を使う方法で、Oktaの公式ガイドの手順は次のとおりです。

1. スーパー管理者のアカウントを用意し、XAAに対応したRequesting AppとResource Appを手元にそろえる。
2. 管理コンソールの［Applications and Resources］→［Applications］でResource Appを選び、［Machine Assignments］タブの［Callers］からCross App Access（XAA）を有効にして保存する。
3. ［Directory］→［AI agents］の［Register AI agent］でエージェントを登録する。
4. 登録したエージェントの［Resource connections］タブで［Add resource connection］を選び、XAAを有効にしたResource Appを追加する。

2026年前半の開発者ブログには、［Settings］→［Features］→［Early access］でCross App Accessを有効にする手順が載っています。しかしOktaのリリースノートでは、2026年7月の版に「セルフサービス機能としてのCross App Accessの削除」が載り、8月17日に全顧客向けのGAとなりました。古い手順の画面が見当たらない場合は、上の現行ガイドに従ってください。

XAAで防げるリスクと防げないリスク

XAAが守るのは「アプリ間の接続を誰が許可したか」という経路です。効く範囲と効かない範囲を分けておかないと、導入しただけでエージェントの安全性が担保されたと誤解します。

IdPがchat.writeまで許可していれば、悪意ある指示を読み込んだエージェントはその範囲で書き込めます。XAAが記録するのは「誰の権限で接続したか」までで、エージェントが何を書いたかの妥当性は判断しません。スコープを読み取りから始め、書き込み系は対象アプリを絞って足すのが現実的です。機械IDの管理全般はノンヒューマンアイデンティティ（NHI）とは？機械IDの管理・リスクと実装者向けの守り方を解説【2026年時点】で扱っています。

既存の認可方式との使い分けと導入を見送る条件

APIキー・個別OAuth同意・SSOとの使い分け

今は導入を見送るべき条件

次のどれかに当てはまる企業では、2026年10月時点でXAAに予算を割いても効果が出ません。

• 連携したいSaaSが未対応：XAAは接続の両側が対応して初めて動きます。社内の主要SaaSが上記の対応リストやOINのXAA対応アプリに無ければ、IdP側だけ有効にしても何も変わりません。
• 対象の接続で同じIdPを信頼していない：ID-JAGは、Resource側がSSOで信頼しているIdPが発行することを前提にしています。Entra IDとOktaが混在していても、接続ごとにResource側が発行元のIdPを信頼できれば導入対象になります。エージェントを使う部門のIdPと対象SaaSのSSO先が別々のままの接続には使えません。
• エージェントの本番利用がまだ無い：解決したい課題がまだ表に出ていない段階です。先にエージェントとそのAPIキーの棚卸しを済ませるほうが、後の移行が速くなります。

逆に、Oktaを全社IdPにしてSaaSのSSOを集約済みで、Claude・Cursor・VS Codeなど対応済みのRequesting Appを業務で使っている企業は、Agent SSOがSSOプランに含まれています。対象SaaSの対応状況と月間のID-JAG発行数を見積もったうえで、接続先を絞った検証から始めるのが妥当です。

よくある質問

クロスアプリアクセス（Cross App Access）の仕組みを簡単に言うと？

アプリが、社員のSSOログインの証明（IDトークン）を企業のIdPに見せて「このアプリのAPIを使ってよいか」を尋ね、IdPが許可した場合にだけ発行される引換券（ID-JAG）を相手アプリでアクセストークンに換える仕組みです。許可の判断を、利用者の同意画面からIdPの管理者ポリシーに移します。

XAAとID-JAGは何が違いますか？

ID-JAGはIETFで策定中の仕様の名前で、XAAはその通称、かつOktaの製品・エコシステム名です。仕様はオープンなので、Okta以外のIdPやSaaSも実装できます。

XAAはRFCになっていますか？

なっていません。2026年10月時点の最新はInternet-Draftのdraft-ietf-oauth-identity-assertion-authz-grant-04（2026年5月21日）です。実装時は参照した草案の版番号を記録しておくと、改訂への追従が楽になります。

XAAとMCPはどういう関係ですか？

MCPの拡張「Enterprise-Managed Authorization」が、ID-JAGをMCPに当てはめたものです。コア仕様ではなく任意採用の拡張なので、MCPサーバーごとに対応の有無を確認する必要があります。

XAAを提供しているのはどの企業ですか？

IdP側ではOktaがAgent SSOとしてGA済みで、Auth0はResource App向けをOpen Early Access（本番利用可）で提供しています。2026年6月の発表では、Claude・Cursor・VS Code・Slack・Atlassian・Figmaなど25件を超えるアプリと、WorkOS・Stytch・Keycloak・Cloudflareなどの基盤が対応を表明しました。

関連記事

• Okta（オクタ）とは？認証の仕組み・機能・料金・セキュリティを2026年版で解説
• Auth0 for AI Agentsとは？GA後の4機能とCIBA・Token Vault実装・料金を解説【2026年版】
• AIエージェントにMCPで外部ツールを接続する実装手順とは？tool定義・権限・認可の設計を解説【2026年版】
• CIMD（Client ID Metadata Documents）とは？MCPでDCRに代わるOAuthクライアント登録の仕組みと実装【2026年9月時点】
• ノンヒューマンアイデンティティ（NHI）とは？機械IDの管理・リスクと実装者向けの守り方を解説【2026年時点】