こんにちは。LINEヤフー株式会社で認証・認可基盤Athenzの開発・運用を担当している金 廷祐（Kim, Jeongwoo）です。この記事では、AIエージェントがさまざまなサービスと連携する際のトークン管理の課題と、その解決方法として注目されているIdentity Assertion JWT Authorization Grant（以下、ID-JAG）について紹介します。
AI時代の課題
2026年現在、AIのパラダイムは単なるチャットを超え、実際の業務を遂行する実行中心へと変化する傾向にあります。今やAI Agentは、検索、データベース照会、メッセンジャーを通じたメッセージ送信、チケット作成など、組織内の多様なサービスをまるで自身のツールのように自由に使いこなし、Agentとして活躍する事例が増えています。
しかし、Agentが接続すべきサービスが増えるほど、システムの裏側では認証・認可のための運用コストと複雑さが増大する可能性があります。結果としてAIを導入して業務を加速させようとしたものの、複雑な連携や権限設定のせいで逆に減速してしまうという課題が発生する懸念があります。
このような課題を解決するものとして注目されている技術が、IETFのOAuth WGで標準化の議論が進められているID-JAGです。
ID-JAGの登場
ID-JAGは、現在Okta社などが中心となって提案している新たな認可標準の草案です。この技術は、2024年3月にIndividual Draftとして初めて公開されました。その後、議論とブラッシュアップが重ねられ、2025年6月23日にはOkta社が公式に支持する次世代標準候補として発表されました。これにより、単なる草案から業界が注目する次世代の有望なプロトコルとして認知度も高まりつつあり、関連する動きも活発化しています。
さらに、最近AIエコシステムで注目を集めているModel Context Protocol（MCP）のエンタープライズ権限付与のドラフト文書でも、既存の企業IdPを通じた中央集約型のアクセス制御を整理する方法としてID-JAGが言及されているほど、実運用に向けたエコシステム構築の動きが見られます。
そこで本記事では、ID-JAGの概念からコアとなる利点、そして注意事項までを詳細にまとめます。
ID-JAGとは？
結論から申し上げますと、ID-JAGはシングルサインオン（SSO）の信頼モデルを『APIアクセス』の領域へ拡張する仕様です。
IETFの公式ドラフトでは、その目的を以下のように説明しています。
"[ID-JAG] can be used to extend the SSO relationship of multiple SaaS applications to include API access between these applications as well... The same enterprise IdP that is trusted by applications for SSO can be extended to broker access to APIs." — Appendix A.1. Enterprise Deployment - draft-ietf-oauth-identity-assertion-authz-grant-02
これを一言で要約すると、以下のようになります 。
これまでSSOを通じて確立してきたIdPに対する信頼を、アプリ間、あるいはAgentとサービス間のAPIアクセスにも適用し、どのアプリが、どのアプリのAPIに、どのような権限でアクセスできるかをIdP側の中央ポリシーで一元管理することを目指しています。
技術的には、
という2つの既存RFC仕様を組み合わせます。すなわち、IdPが署名した検証可能なJWTを一種の『紹介状』として発行し、APIリソース側がこの紹介状を信頼して最終的なAccess Tokenを発行するというフローを定義しています。
ID-JAGの登場人物
全体的な動作原理を理解するために、ID-JAGのSection 2.1. Rolesの定義に基づき、登場人物を4つに定義してみましょう。
- Requesting Agent: 他アプリのAPIを呼び出そうとするAI Agentまたはアプリケーション
- Enterprise IdP: 社内SSOを提供し、中央認可ポリシーを保持する企業のIdP
- Authorization Server: 呼び出されるターゲットアプリの認可サーバー
- Resource Server: 実際に呼び出されるAPI
登場人物の役割が明確になったところで、この4者がどのように連携し、安全にAPIを呼び出しているのか。具体的な流れを見ていきましょう。
ID-JAGの基本フロー
基本フローは以下の5つのステップで進行します。
- SSO Login: ユーザーがRequesting Agentにログインし、Requesting AgentがIdPからID Tokenを取得します。
- Token Exchange Request: Requesting AgentがIdPにID Tokenを提示し、Token Exchangeを要求して、発行を受けるトークンタイプとしてID-JAGを指定します。（RFC 8693）
- Policy Evaluation and Response: IdPが組織の管理者ポリシーを評価し、許可されればRequesting AgentへID-JAGを返します。
- Access Token Exchange: Requesting AgentがAuthorization Serverに、発行されたID-JAGを提示し、最終的なAccess Tokenを取得します。（RFC 7523）
- API Access: Requesting Agentは、発行されたAccess Tokenを使用して、Resource Serverを呼び出します。（RFC 6749）
特徴的なポイントは、Requesting AgentとResource Server間の個別の関係性ではなく、組織が管理するEnterprise IdPとAuthorization Server間の関係性へと許可判断の視点が移った点、およびその結果であるID-JAGが暗号学的に検証可能なJWTであるという点です。
ID-JAGの導入により組織に期待される利点
単なるプロトコルの変化にとどまらず、ID-JAGの導入が実際の企業環境やエンジニアリング組織にどのような影響をもたらし得るのか整理してみました。
まず、もっとも分かりやすい利点は、ユー ザー体験の改善です。従来は、アプリを連携するたびにユーザーがConsent Screenで直接権限を許可しなければならない場面が多く見られました。しかし、ID-JAGの概念では、許可判断の手続きをIdPの管理者ポリシーに集約させることができます。特にAI Agentの文脈においては、ツールが増えるほどConsentのポップアップ画面も増えるという疲労問題が発生しがちですが、これを緩和することが期待できます。
"[The Resource Authorization Server] does not need obtain user consent directly from the resource owner." — 4.1. Overview - draft-ietf-oauth-identity-assertion-authz-grant-02
このようなユーザー体験の側面に加え、組織全体としては主に以下の2つの観点で利点があると考えられます。
監査に耐える可視化
IdPが発行するID-JAGは、どのAudienceとScopeを、どの主体に許可したかを明確に扱います。したがって、組織内のサービス間の複雑な接続の事実が、IdPを経由する構造であれば、IdP側に集約されやすくなります。また、単にどのアプリがトークンを持っているかを超えて、誰の代わりに、どのAgentが、どの範囲でアクセスしたかというコンテキストをトークンに保存することが可能です。
以下はEnterprise IdPが発行するID-JAGのサンプルです。各フィールドの意味をコメントで記載しています。
{
"sub": "sample-human-user", // scp(Scope)に対して、元の権限を保有している主体
"client_id": "ai-agent", // 上記の代わりにアクセスを要求するRequesting Agentの情報
"aud": "https://authorization.sample.server/v1", // どのAuthorization Serverへ
"scp": "api-writers api-readers", // どの範囲・権限で
"iss": "https://enterprise.idp.sample.server/v1", // Enterprise IdP自身
"exp": 1773839486, // このID-JAGの有効期限
"iat": 1773825086, // このID-JAGの発行時刻
"jti": "abcabca-7dc6-42ab-b326-27eb23ecfd8b", // このID-JAGの一意なID
// ...
}このようなID-JAG発行イベントがEnterprise IdPを中心に集まることで、セキュリティインシデント発生時にも責任の所在を把握しやすくなります。さらに、各種コンプライアンス要件に対する監査証跡のデータをIdPから比較的簡単に抽出し、証明しやすくなる点も重要です。
The IdP can then issue tokens that contain the necessary context about both the human user and the AI agent, facilitating secure delegation and maintaining a clear audit trail across systems.— Cross App Access: Securing AI agent and app-to-app connections - Okta, Inc.
リスクを抑える中央統制
組織内のユーザーがIT部門の承認を得ていないAIツールを任意に連携させ、会社のデータを扱うシャドーAIの問題は、データ流出のリスクを生み出します。ID-JAGの体系では、IdPが該当ツールの承認の可否を中間で判断しやすくなり、把握しにくかった外部AIの接続試行を正常な統制プロセスの中に組み込むことが期待できます。
"[As AI agents] proliferate, organizations need clear visibility into their access rights and granular control of the authorization process to be able to trust that agents will operate without compromising security and compliance." — Okta Newsroom (Jun 23, 2025)
Enterprise IdPは、Token Exchangeのリクエストに対して一元的なポリシー評価を実行し、最終的に許可するScopeを決定します。つまり、AIや外部アプリが要求するScopeと組織が実際に許可するScopeを分離し、組織のセキュリティ基準に合わせて権限を上書きし、統制するためのセーフティネットが生まれます。
"If scope is present, the IdP MUST process it according to Section 3.3 of [RFC6749] and evaluate policy to determine the granted scopes." — 4.3.2. Processing Rules - draft-ietf-oauth-identity-assertion-authz-grant-02
上記の前提があるため、不正アクセス、コスト問題、コンプライアンス違反など、接続を遮断しなければならない状況が発生した際にも、各エンドポイントをいちいち探して回って制御する手間を減らし、新規トークン発行の判断をIdP側に集約しやすくなります。
また、AI Agent導入時におけるセキュリティチームの主な悩みの種の1つは、API Key、Refresh Token、サービスアカウントの認証情報が増殖するトークンスプロール現象です。ID-JAGの仕様では、リソースサーバーが別途Refresh Tokenを発行するのではなく、クライアントがID-JAGを再提出してAccess Tokenを更新することを推奨しています。これにより、システムのあちこちに散らばっていた長期の認証情報を、プロトコルベースの動的な信頼に置き換えることができる構造です。
The Resource Authorization Server SHOULD NOT return a Refresh Token when an Identity Assertion JWT Authorization is exchanged for an Access Token— 4.4.3. Refresh Token - draft-ietf-oauth-identity-assertion-authz-grant-02
ID-JAG導入時の注意点
ID-JAGは現時点ではIETFのInternet-Draftであり、最終的なRFCとして確定した仕様ではありません。今後の議論によって動作方式が変わる可能性があるため、現在の仕様を前提にコアアーキテクチャを密結合させることにはリスクが伴います。
この前提を踏まえた上で、ID-JAGの導入上考慮すべき制約について、Enterprise DeploymentおよびLLM Agent using Enterprise Toolsのユースケースを前提に、仕様上の前提条件と実装・運用上の考慮点に分けて整理します。
仕様上の前提条件
実際のシステムにID-JAGを導入するには、ドラフトに明記されている以下の前提条件の検討が必要です：
- Requesting Agentは、Enterprise IdPとAuthorization Serverの双方にOAuth 2.0クライアントとして登録されている必要があります。
- Enterprise IdPとRequesting Agent、Enterprise IdPとAuthorization Serverとの間で、明示的な信頼関係を事前に確立しておく必要があります。
- Enterprise IdPは、企業ポリシーに基づき、Requesting Agentに対してAuthorization ServerへアクセスするためのScopeをあらかじめ付与している必要があります。
"The Client has a registered OAuth 2.0 Client with the IdP Authorization Server. The Client has a registered OAuth 2.0 Client with the Resource Authorization Server. Enterprise has established a trust relationship between their IdP and the Client for SSO and Identity Assertion JWT Authorization Grant. Enterprise has established a trust relationship between their IdP and the Resource Authorization Server for SSO and Identity Assertion JWT Authorization Grant. Enterprise has granted the Client permission to act on behalf of users for the Resource Authorization Server with a set of scopes" — A.1.1. Preconditions - draft-ietf-oauth-identity-assertion-authz-grant-02
また、ID-JAGを利用しても、システム間の論理的な責務の境界は維持される必要があります。意図しない権限の拡大を防ぐため、少なくともEnterprise IdP自身が自ら発行したID-JAGに対するアクセストークンの発行主体になってはなりません。物理的・製品的に統合された環境を利用する場合であっても、このような自己発行・自己交換のフローを組むことは、本仕様の安全性の前提に反します。
"Identity Provider MUST NOT issue access tokens in response to an ID-JAG it issued itself. Doing so could lead to unintentional broadening of the scope of authorization." — 8.3 Cross-Domain Use - draft-ietf-oauth-identity-assertion-authz-grant-02
実装・運用上の考慮点
セキュリティ上の理由から、シークレット値を安全に保管できるConfidential Clientの使用が推奨されています。モバイル単独アプリのようなPublic Clientでは、従来通りユーザーのインタラクティブな同意を伴うAuthorization Codeグラントの利用が推奨されます。
"[ID-JAG] SHOULD only be supported for confidential clients. Public clients SHOULD use the existing authorization code grant and redirect the user to the Resource Authorization Server with an OAuth 2.0 Authorization Request where the user can interactively consent to the access delegation." — 8.1 Client Authentication - draft-ietf-oauth-identity-assertion-authz-grant-02
実行時には、Enterprise IdPが主体トークンのセキュリティコンテキストを分析し、ポリシーに応じて追加認証を要求する場合があります。そのため、エラーを処理してユーザーに再認証を促す制御ロジックを設計に組み込むことが必要になる場合があります。
"The IdP may require step-up authentication for the subject if the authentication context in the subject's assertion does not meet policy requirements. An insufficient_user_authentication OAuth error response may be returned to convey the authentication requirements back to the client similar to OAuth 2.0 Step-up Authentication Challenge Protocol [RFC9470]." — 8.2 Step-up Authentication - draft-ietf-oauth-identity-assertion-authz-grant-02
さらに、システム分離の構造上、運用面での考慮も必要です。ID-JAGはJWT形式であるため、一度発行されてネットワーク上に伝播したトークンを中央から即時に無効化することは困難です。実効的な遮断を行うには、ID-JAGの有効期間を短く設定し、頻繁な更新を促す仕組みを導入するなど、トークン寿命の設計と合わせて検討していくことが必要になる場合があります。
おわりに
AI Agentの導入はIT環境に大きな変化をもたらしつつありますが、同時にこのAgentたちの権限をいかに安全かつ効率的に統制するかという新たな課題を残しました 。
認証・認可のパラダイムは、エンドポイントごとに個別にトークンを管理する方式から、IdPを中心に接続の信頼を中央で制御する方式へと移行する傾向にあります。IETFのドラフトとして活発に議論されているID-JAGは、このような文脈において有効な選択肢となり得ます。
最近では、私たちのオープンソース権限管理プラットフォームであるAthenzも、この流れに合わせID-JAGを公式にサポートし始めました。 もちろん、トークンの寿命管理や事前設定など、考慮すべき技術的制約は存在しますが、ID-JAGを取り入れたAthenzを活用すれば、サービスの安定性を維持しながらも、AIエコシステムの広大な拡張性を完全に受け入れる強力な基盤を構築できるでしょう。私たちLINEヤフーは、今後もグローバルな標準化の動向やオープンソースのエコシステムを継続的に注視し、開発者体験とセキュリティの双方を考慮した適切な基盤を現場に適用していきます。
次回のブログでは、AthenzとオープンソースのIdPを使用してID-JAGを発行し、実際にAIとどのように連携して動作させるかについてのハンズオン記事をお届けする予定です。ぜひご期待ください。
長文を最後までお読みいただき、ありがとうございました！
Jeongwoo Kimが書いた他の記事を見る
