【Okta】ID-JAGの設計思想から読み解くCross App Accessの背景と技術の裏側【生成AIセキュリティ対策シリーズ】

はじめに

こんにちは、ネクストモード株式会社テクニカルサポート担当です。

前回Cross App Accessについての検証ブログを公開致しましたが、そもそもCross App Accessとはどのような考えにもとづくのか、背景にあるID-JAG(Identity Assertion JWT Authorization Grant)に触れながら少し深ぼってみようと思います。

本記事では、以下の観点から考察します。これらを整理することで、AIエージェント時代のセキュリティ設計を紐解いていきます。

• どのような課題を解決しようとしているのか
• 背景にあるID-JAGの仕組み
• 企業のAIエージェント基盤を設計する際、認可をどう捉えるべきか

Cross App Accessが解決したい課題

課題：Cross App Accessが登場前の世界

企業内でMCPサーバーの利用が増え、AIエージェントが乱立し始めると、以下のような課題に直面します。

• 「このAIエージェントを経費精算システムやCRMに接続したいが、どこまでアクセスを許可すべきか判断できない」
• 「MCPサーバーとの連携で、ユーザー自身にAPIキーの管理を任せることに不安がある」
• 「連携のたびにユーザーにOAuthの同意画面を承認させるのは現実的ではない」
• 「どのエージェントが、いつ、どのシステムにアクセスしたのかを確認する手段がない」

解決：Cross App Accessが実現する世界

OktaのCross App Accessは、「アプリ間の認可」を個々のアプリ任せにせず、IdP(Identity Provider)の管理下で一元的に制御する仕組みです。

これにより、ユーザーは煩わしいOAuth同意画面から解放され、管理者は認可ポリシーとアクセスログを一箇所で管理できるようになります。

なぜ「アプリ間の認可」が課題となるのか

まず、AIエージェント導入におけるよくあるシナリオから考えてみましょう。

AIアシスタント「Aria」の一日

ある企業で、情シス部門がAIアシスタント「Aria」を導入したとします。このAIエージェントは、社員の代わりに次のようなタスクを自律的に行います。

• 社員のカレンダーを確認し、空き時間にミーティングを設定する
• 経費精算SaaSから「承認待ち申請」を取得し、サマリを送る
• CRMから顧客情報を取得し、訪問直前の顧客の要約をSlackで通知する

これらはすべて「ユーザー本人に代わって、AIエージェントが他のSaaSのAPIを実行」する動作です。この時、管理者は3つの壁に直面します。

1. OAuth同意の氾濫
   連携先(カレンダー、経費、CRM…)が増えるたびにユーザーへ同意を求めると、体験が悪化し、ユーザーが何も確認せずに「承認」ボタンを押す習慣がついてしまいます。
2. ガバナンスの分散
   「どのAIエージェントが、誰のデータに対して、どんな権限を持っているか」を確認するために、各SaaSの管理画面を巡回しなければなりません。
3. 監査と停止の困難さ
   インシデント時に「このAIエージェントの権限だけを一括で停止したい」と考えても、各SaaSに発行されたトークンを個別に無効化する必要があります。

従来のOAuth 2.0は「ユーザー←→アプリ」の1対1の関係には強力ですが、「多数のアプリ←→多数のアプリ」を一元管理する観点は手薄になりがちです。

Cross App Accessは、このギャップを埋めるために設計されました。

「AIエージェントと業務アプリの信頼関係は、ユーザー個人の同意ではなく、IdP管理者のポリシー設定で決定する」

この点が最大の特徴です。

Cross App Accessとは

Cross App Accessの仕組みを簡潔に表現すると、以下のようになります。

• ユーザーはOktaに一度ログインするだけでよい
• 「どのエージェントが、どの業務アプリに代理アクセス可能か」は、Okta管理者がManaged connectionとして事前に定義する
• AIエージェントは、その許可設定に基づいてOktaから業務アプリ用のアクセストークンを取得する

この関係性を整理するために、用語を定義しておきます。

ポイントは、「ユーザー単位の同意(Consent)」ではなく、「アプリ間の接続単位の許可」を扱う という点です。

「誰が、誰の代わりに、どのトークンを得るのか？」

ここからは少し技術的な仕組みに踏み込みます。

AIアシスタント「Aria」が社員Bさんの経費データにアクセスする際、システムの裏側では以下の3点を検証する必要があります。

1. AIエージェントは誰の代わりに動いているのか？(社員Bさん)
2. 読みたいデータはどのアプリにあるのか？(経費SaaS)
3. その組み合わせは管理者に許可されているか？

Cross App Accessは、ID-JAGでこれらを解決します。具体的な流れは以下の通りです。

1. Oktaが「このユーザーは社員Bさんです」という署名付き証明書(Identity Assertion)をAIエージェントに渡す
2. AIエージェントがその証明書を提示し、「社員Bさんとして経費SaaSにアクセスするトークンをください」とOktaに要求する
3. OktaがManaged Connectionを確認し、許可されていればアクセストークンを発行する

ID-JAGのフローを理解する

ID-JAGはIETFのOAuthワーキンググループで議論されている仕様で、「Identity Assertion(身元の主張)を用いてアクセストークンを取得する」ための Grant Type です。

ID-JAGの最新の仕様は以下のGitHubで確認することができます。

登場人物

• ユーザー：社員Bさん
• Requesting App：AIアシスタント「Aria」
• Resource App：経費精算SaaS
• IdP / Authorization Server：Okta

ID-JAGの詳細フロー

ここからは、実際のプロトコルレベルでの動作を、シーケンス図とともに詳しく見ていきます。

全体のシーケンス図

以下は、全体のフローを示したシーケンス図です。

https://developer.okta.com/blog/2025/06/23/enterprise-ai をもとに作成

Step1～7：ユーザーがOktaにログイン(SSO)

社員Bさんは通常通りOktaにサインインし、AIアシスタント「Aria」を利用開始します。ここまでは一般的なOpenID Connect(OIDC)のフローです。

1. クライアント(Aria)がログインリクエストを開始
2. ユーザーのブラウザがIdP(Okta)にリダイレクト
3. ユーザーがIdPにログイン
4. IdPが認可コードをブラウザに返却
5. ブラウザが認可コードをクライアントに渡す
6. クライアントが認可コードをIDトークンに交換
7. IdPがIDトークンを返却

この時点で、ユーザーはAriaにログインした状態になります。

Step8～10：エージェントが「Identity Assertion JWT」を取得(Token Exchange)

次に、AriaはOktaに対してToken Exchange(RFC 8693)リクエストを送信します。

主なパラメータ

• requested_token_type ：ID-JAGを要求
• audience：リソースアプリ(経費SaaS)の認可サーバーのIssuer URL
• subject_token： Step7で取得したIDトークン
• subject_token_type： IDトークンであることを示す識別子

Step9：IdPによる検証とポリシー評価

Oktaは以下のチェックを実行します。

• IDトークンが、リクエストを送信しているクライアント(Aria)に発行されたものか
• ユーザー(社員Bさん)が存在し、アクティブな状態か
• ユーザーがリソースアプリ(経費SaaS)に割り当てられているか
• 管理者が設定したManaged Connectionで、この接続(Aria→経費SaaS)が許可されているか

すべての検証をクリアすると、OktaはID-JAGを発行します。

このJWTは、Oktaが通常IDトークンに署名するのと同じ鍵で署名されています。これにより、リソースアプリ側はSSO設定で既に知っている公開鍵を使って検証できます。

Step11～13：ID-JAGを使ってアクセストークンを取得

Ariaは、取得したID-JAGを持って、経費SaaSの認可サーバーにアクセストークンをリクエストします。これはJWT Bearer Authorization Grant(RFC 7523)の形式です。

経費SaaSの認可サーバーは以下を実施します。

• JWTのIssuer(発行者)を確認し、どのIdP(Okta)から来たトークンかを特定
• Oktaの公開鍵を使ってJWTの署名を検証
• その他のクレーム(audience、expiration等)を検証

検証が成功すると、経費SaaSはアクセストークンを発行します。

Step14～15：リソースへのアクセス

Ariaは取得したアクセストークンを使って、経費SaaSのAPIにリクエストを送信します。これは通常のOAuthフローで取得したトークンと同じように機能します。

単なるToken Exchangeとの違い

「既存のToken Exchange(RFC 8693)やJWT Bearerと何が違うのか？」と思われるかもしれません。

技術的なベースは同じですが、Cross App Accessとして実装されることで運用上のインパクトが大きく異なります。

アプリ間の「道」を管理者が設計できる

• 従来：開発者が個別にOAuth連携を実装し、管理者は感知しにくい。
• Cross App Access：「このAIエージェントは、このSaaSとだけ繋がって良い」というルールを、Okta管理者がコンソール上で一元管理できます。

トレーサビリティの向上

Identity Assertion には「どのユーザーが、どのエージェントを使って、どのリソースへ行こうとしたか」という情報が含まれます。IdPが発行の起点となるため、「いつ、誰が、どのAIエージェントでデータに触れたか」をIdPのログから追跡可能になります。

緊急停止(Kill Switch)の明確化

インシデント発生時、IdP側で停止ポイントを制御できます。

• 特定のユーザーのみAIエージェント利用を停止したい → ユーザー単位の無効化
• AIエージェント自体に欠陥が見つかった → Managed Connectionの無効化(全ユーザーに対し、そのAIエージェントからのアクセスを即時遮断)

AIエージェント・MCPとの親和性

昨今のMCP(Model Context Protocol)などのトレンドは、「AIエージェントから見たツール呼び出しの標準化」に注力しています。しかし、「そのツールの裏側でどう認証認可を通すか」は実装者に委ねられています。

Cross App Access・ID-JAGの考え方を取り入れると、以下のように役割分担できます。

• 認可ロジック(Oktaに集約)
  • OAuthの複雑な処理、ポリシー判定、監査ログ
• ツール・エージェント側(シンプル化)
  • 「どのResource Appを呼びたいか」「どのスコープが必要か」だけを知っていれば良い

これにより、エージェントやツールが増えても認可のガバナンスが破綻しにくくなります。Oktaを利用しない場合でも、「ユーザーの身元と代理関係を1つのトークンに封入して検証する」というID-JAGの設計パターンは、セキュアなエージェント基盤構築の参考になるはずです。

将来的な導入検討のポイント

Cross App AccessやID-JAGは、まだ採用しているSaaSやAIエージェントがほとんどない新しい仕組みです。しかし、将来的にAIエージェントの活用が広がった際に備えて、以下の観点を整理しておくとよいと思います。

• IdPへの委任範囲の検討：すべてのアプリ間連携をこの仕組みに移行するのか、それとも「AIエージェント ↔ 主要SaaS」のようなハイリスクな連携に絞るのか。
• 既存実装との共存計画：すでに各SaaSと直接OAuth連携しているアプリがある場合、新しい仕組みとどう共存させるか、移行のタイミングをどう設計するか。
• スコープ設計の粒度：Resource App側で「読取専用」「書込許可」「管理者権限」など、適切な粒度のスコープが用意されているか、将来的に必要になるか。
• 監査ログの運用体制：「誰が・何を使って・どこにアクセスしたか」のログを、将来的にどう管理・モニタリングするかの体制を検討する。

おわりに

本記事では、Okta Cross App Accessの背後にあるID-JAG(Identity Assertion JWT Authorization Grant)という考え方を中心に解説しました。

ID-JAGの本質は、「誰が、誰の代わりに、どのリソースにアクセスしているのか」という代理関係を、1つのJWTトークン(Identity Assertion)に封入し、IdPが一元的に発行・検証するという点にあります。

これにより、以下のメリットが生まれます。

• アプリ間の信頼関係をIdPに集約し、管理者が一元管理できる
• 「誰が・どのエージェントで・どこにアクセスしたか」のトレーサビリティが向上する
• インシデント時の緊急停止ポイントが明確化される

AIエージェントが企業システムに組み込まれていく時代において、ID-JAGの設計パターンは、セキュアな認可基盤を構築するための重要な指針となるはずです。

これから自社のAIエージェント基盤を設計される方は、ぜひID-JAGの考え方を参考にしてみてください。