こんにちは、ネクストモード株式会社テクニカルサポート担当です。
前回Cross App Accessについての検証ブログを公開致しましたが、そもそもCross App Accessとはどのような考えにもとづくのか、背景にあるID-JAG(Identity Assertion JWT Authorization Grant)に触れながら少し深ぼってみようと思います。
本記事では、以下の観点から考察します。これらを整理することで、AIエージェント時代のセキュリティ設計を紐解いていきます。
企業内でMCPサーバーの利用が増え、AIエージェントが乱立し始めると、以下のような課題に直面します。
OktaのCross App Accessは、「アプリ間の認可」を個々のアプリ任せにせず、IdP(Identity Provider)の管理下で一元的に制御する仕組みです。
これにより、ユーザーは煩わしいOAuth同意画面から解放され、管理者は認可ポリシーとアクセスログを一箇所で管理できるようになります。
まず、AIエージェント導入におけるよくあるシナリオから考えてみましょう。
ある企業で、情シス部門がAIアシスタント「Aria」を導入したとします。このAIエージェントは、社員の代わりに次のようなタスクを自律的に行います。
これらはすべて「ユーザー本人に代わって、AIエージェントが他のSaaSのAPIを実行」する動作です。この時、管理者は3つの壁に直面します。
従来のOAuth 2.0は「ユーザー←→アプリ」の1対1の関係には強力ですが、「多数のアプリ←→多数のアプリ」を一元管理する観点は手薄になりがちです。
Cross App Accessは、このギャップを埋めるために設計されました。
「AIエージェントと業務アプリの信頼関係は、ユーザー個人の同意ではなく、IdP管理者のポリシー設定で決定する」
この点が最大の特徴です。
Cross App Accessの仕組みを簡潔に表現すると、以下のようになります。
この関係性を整理するために、用語を定義しておきます。
| 用語 | 役割・イメージ |
|---|---|
| Requesting App | 代理でAPIを呼ぶ側(例：AIアシスタント「Aria」) |
| Resource App | データを持つ側(例：経費精算SaaS) |
| Managed Connection | 上記2つの「事前に許可された接続ルート」 |
| Cross App Access | これらを統合管理するOktaの機能群 |
ポイントは、「ユーザー単位の同意(Consent)」ではなく、「アプリ間の接続単位の許可」を扱う という点です。
ここからは少し技術的な仕組みに踏み込みます。
AIアシスタント「Aria」が社員Bさんの経費データにアクセスする際、システムの裏側では以下の3点を検証する必要があります。
Cross App Accessは、ID-JAGでこれらを解決します。具体的な流れは以下の通りです。
ID-JAGはIETFのOAuthワーキンググループで議論されている仕様で、「Identity Assertion(身元の主張)を用いてアクセストークンを取得する」ための Grant Type です。
ID-JAGの最新の仕様は以下のGitHubで確認することができます。
ここからは、実際のプロトコルレベルでの動作を、シーケンス図とともに詳しく見ていきます。
以下は、全体のフローを示したシーケンス図です。
https://developer.okta.com/blog/2025/06/23/enterprise-ai をもとに作成
社員Bさんは通常通りOktaにサインインし、AIアシスタント「Aria」を利用開始します。ここまでは一般的なOpenID Connect(OIDC)のフローです。
この時点で、ユーザーはAriaにログインした状態になります。
次に、AriaはOktaに対してToken Exchange(RFC 8693)リクエストを送信します。
主なパラメータ
requested_token_type ：ID-JAGを要求audience：リソースアプリ(経費SaaS)の認可サーバーのIssuer URLsubject_token： Step7で取得したIDトークンsubject_token_type： IDトークンであることを示す識別子Oktaは以下のチェックを実行します。
すべての検証をクリアすると、OktaはID-JAGを発行します。
このJWTは、Oktaが通常IDトークンに署名するのと同じ鍵で署名されています。これにより、リソースアプリ側はSSO設定で既に知っている公開鍵を使って検証できます。
Ariaは、取得したID-JAGを持って、経費SaaSの認可サーバーにアクセストークンをリクエストします。これはJWT Bearer Authorization Grant(RFC 7523)の形式です。
経費SaaSの認可サーバーは以下を実施します。
検証が成功すると、経費SaaSはアクセストークンを発行します。
Ariaは取得したアクセストークンを使って、経費SaaSのAPIにリクエストを送信します。これは通常のOAuthフローで取得したトークンと同じように機能します。
「既存のToken Exchange(RFC 8693)やJWT Bearerと何が違うのか？」と思われるかもしれません。
技術的なベースは同じですが、Cross App Accessとして実装されることで運用上のインパクトが大きく異なります。
Identity Assertion には「どのユーザーが、どのエージェントを使って、どのリソースへ行こうとしたか」という情報が含まれます。IdPが発行の起点となるため、「いつ、誰が、どのAIエージェントでデータに触れたか」をIdPのログから追跡可能になります。
インシデント発生時、IdP側で停止ポイントを制御できます。
昨今のMCP(Model Context Protocol)などのトレンドは、「AIエージェントから見たツール呼び出しの標準化」に注力しています。しかし、「そのツールの裏側でどう認証認可を通すか」は実装者に委ねられています。
Cross App Access・ID-JAGの考え方を取り入れると、以下のように役割分担できます。
これにより、エージェントやツールが増えても認可のガバナンスが破綻しにくくなります。Oktaを利用しない場合でも、「ユーザーの身元と代理関係を1つのトークンに封入して検証する」というID-JAGの設計パターンは、セキュアなエージェント基盤構築の参考になるはずです。
Cross App AccessやID-JAGは、まだ採用しているSaaSやAIエージェントがほとんどない新しい仕組みです。しかし、将来的にAIエージェントの活用が広がった際に備えて、以下の観点を整理しておくとよいと思います。
本記事では、Okta Cross App Accessの背後にあるID-JAG(Identity Assertion JWT Authorization Grant)という考え方を中心に解説しました。
ID-JAGの本質は、「誰が、誰の代わりに、どのリソースにアクセスしているのか」という代理関係を、1つのJWTトークン(Identity Assertion)に封入し、IdPが一元的に発行・検証するという点にあります。
これにより、以下のメリットが生まれます。
AIエージェントが企業システムに組み込まれていく時代において、ID-JAGの設計パターンは、セキュアな認可基盤を構築するための重要な指針となるはずです。
これから自社のAIエージェント基盤を設計される方は、ぜひID-JAGの考え方を参考にしてみてください。