はじめに
お世話になっています、バクラク事業部アカウント基盤開発部の id:convto です！(10月に組織変更があり、所属部が変更になりました)
これは AI Agent ブログリレー の45日目の記事です。昨日は numashi さんの AIエージェント機能を継続的に生み出すプロダクトマネジメントについて でした。
さて昨今 AI Agent 関連の話題は尽きないですね。そのなかでもアカウント基盤開発部としてはやはり認可に関連する議論を定期的に観察しています。 昨今の議論で特に注目しているのが IdP による中央集権的な認可を可能とするような OAuth 2.0 拡張仕様である Identity Assertion Authorization Grant (通称ID-JAG)についての議論です。
ここでは ID-JAG の紹介と、そのメリットや想定される困りごとなどについて紹介していきます。
ID-JAG とは
IETF にて議論中の Identity Assertion Authorization Grant で取り扱われている仕様です。
ざっくりいうと、 OAuth 2.0 ではユーザーの明確な consent を通じて認可の同意をとりますが、それが IdP に移譲するイメージです。
図をそのまま引用すると以下のようになります。
+---------+ +--------------+ +---------------+ +--------------+
| | | | | Resource | | Resource |
| | | IdP | | Application | | Application |
| Client | | Authorization| | Authorization | | Resource |
| | | Server | | Server | | Server |
+----+----+ +-------+------+ +-------+-------+ +------+-------+
| | | |
| | | |
| --------------> | | |
| 1 User SSO | | |
| | | |
| ID Token | | |
| <- - - - - - - - | | |
| | | |
| | | |
| | | |
| 2 Token Exchange | | |
| ----------------> | | |
| | | |
| ID-JAG | | |
| <- - - - - - - - | | |
| | | |
| | | |
| | | |
| 3 Present ID-JAG | | |
| ------------------+----------------> | |
| | | |
| Access Token | | |
| <- - - - - - - - - - - - - - - - - - | |
| | | |
| | | |
| | | |
| 4 Resource Request with Access Token| |
| -----------------------------------------------------> |
| | | |
| | | |
| | | |
流れは次の通りです。
- IdP との ID Token を発行
- Token Exchange: ID Token と必要情報を入力し
token-type:id-jagのトークンを発行- このとき IdP は事前に設定された内容などを参照し、この認可要求を受け入れてよいか判断
token-type:id-jagのトークンは JWT であり検証可能
- ID-JAG のトークンを認可サーバーに渡し Access Token を発行
- このときトークンを検証することで認可取得が IdP により許可されていることが確認できる
- IdP に認可判断を移譲し Access Token を発行
- Access Token を使ってリソースサーバーにアクセス…
シーケンスを見ると、検証可能なトークンを利用して認可の判断を安全に IdP に移譲できていそうです。
仕様の文章をみると Token Exchange のステップでは、 IdPは登録情報を元に対象 scope への認可を許可すべきか判断するようです。
The IdP evaluates administrator-defined policy for the token exchange request and determines if the client should be granted access to act on behalf of the subject for the target audience and scopes.
ID-JAG の利用は MCP でも検討されており、10月ころに仕様ドラフトに取り込まれています。
Token Exchange 入力
token-type:id-jag のトークンは IdP が発行するので、入力内容は IdP で検証することができます。現在の仕様によると、入力される内容は以下です。
requested_token_type: REQUIRED- 値を
urn:ietf:params:oauth:token-type:id-jagとすることで ID-JAG Assertion Token が要求されていることを表します
- 値を
audience: REQUIRED- Assertion Token を利用して Access Token を発行する OAuth 2.0 認可サーバーを指定
resource: OPTIONAL- Resource Indicators for OAuth 2.0 で定義されるリソース識別子
scope: OPTIONAL- 要求 scope
subject_token: REQUIRED- OIDCやSAMLで獲得した IdP へのトークン
subject_token_type: REQUIREDsubject_tokenのトークン種別- RFC8693 Section 3 で定められているものを利用する
- OIDC:
urn:ietf:params:oauth:token-type:id_token - SAML assertion:
urn:ietf:params:oauth:token-type:saml2
- OIDC:
これをみると、resource や scope については Optional ではあるものの、渡された場合は IdP による検証が可能そうです。
渡されない場合にどのような挙動にするかは実装に委ねられていそうです。固めに作るなら渡されなかった場合は最小の scope のみ付与する、あたりの挙動になるんでしょうか。
仕様のレスポンスの scope 項目についての案内を見るに、このような IdPへの要求 scope と実際に許可された scope が一致しない場合も想定されていそうです。
OPTIONAL if the scope of the issued token is identical to the scope requested by the client; otherwise, it is REQUIRED. Various policies in the IdP may result in different scopes being issued from the scopes the application requested.
ID-JAG の何がうれしいのか
ID-JAG を利用することにより、IdP を介して中央集権的に認可の制御をすることができ、特にエンタープライズ領域でより高度な情報統制が可能になるのではと期待されています。
また見落としがちですが、それぞれの外部リソースに対して組織としてどのような認可を許可しているかを中央集権的に一覧できる点も嬉しいポイントです。これにより認可の棚卸しなどが容易になります。
まとめると
- 柔軟な認可の定義が中央集権的に可能
- 中央集権的な管理なので一覧性が高く、管理しやすい
あたりがメリットとなりそうです。
これらは厳格な情報統制や管理を行いたいエンタープライズ領域で非常に嬉しい性質です。
また、先述のとおり MCP などのプロトコルも ID-JAG を利用した提案をドラフト仕様として取り込んでおり、AI Agent が利用する外部リソースへの認可を中央集権的に制御する方法としても注目されています。
現状で困りそうなことと、エコシステム発展の予想
IdP やその管理者の目線からすると、各種リソースについての認可をすべて中央集権的に定義する必要があり、やや煩雑です。
Protected Resource Metadata の仕様を実装していれば、リソースサーバーがサポートしているスコープがわかります。が、これは単なる JSON Array なのであるスコープがどのように機能するかは自明ではないです。リソースごとにどのようなスコープが存在し、必要なワークロードのためにどこまで認可すべきかを事前に設定する必要がありそうです。
このあたりは中央集権的な設定を持つ IdP 側で考慮する形となりそうですが、先駆けて実装している Okta の設定などを触ってみた限り、IdP 側で許可する scope の設定などはまだできなさそうでした。
以下の手順で実際に触れるのでご興味ある方は試してみてください！
将来的には IdP による高度な設定などやりたくなりそうで、個人的には Protected Resource Metadata の仕様をもう少し拡張できると便利そうだなと考えています。
今の Protected Resource Metadata の supported_scopes は単なる JSON Array であり、以下のような値です。(RFCの例をそのまま引用)
"scopes_supported": ["profile", "email", "phone"]
これだけだと各種スコープの意味や許可される操作がわかりません。
ここでスコープ関連のメタデータ構造についてさらなる標準化がなされて、詳細な説明や、そのスコープを要求するリソースサーバーAPI一覧などが返せるようになると、IdP側で中央集権的に設定していく際にかなり参考になりそうです。
あくまでイメージですが、たとえば以下のようなものです。
"scope_details": [ "profile": { "endpoints_requiring": ["GET /v1/profile", "POST /v1/profile"] "description": "profile scope, read/write" } "email": [...], "phone": [...], ]
IdP 側で認可に関する設定を持つ可能性があるので、このような解釈可能な形での scope 体系の共有についての仕様整理がされていきそうな気がしています。
さいごに
今回は ID-JAG の紹介をしていきました。
特にエンタープライズ領域で高度な制御が実現でき嬉しいことが多そうですね！
もともとエンタープライズ領域だと外部リソースへの認可は管理しづらく課題がありました。
そこに AI Agent の発展が重なり、より最小の認可を管理者が中央集権的に管理したいニーズが強くなっていると感じています。
今回紹介した ID-JAG は AI Agent にの認可制御の文脈でも注目されています。AI Agent は MCP に限らず複数のツールを利用する可能性がありますが、そこで与える認可を中央集権的に安全に管理できる可能性があるためです。
一つの認可の整理の形として興味深く、引き続き関連議論をウォッチしていきたいと思います。
アカウント基盤開発部では、認証や認可にまつわる機能開発を日々進めています。
特に AI Agent 機能の高速なデリバリを支えるために、中長期でより高度な認可制御が必要になる見込みがあります。このあたりは以前テックブログにも記載しています。
https://tech.layerx.co.jp/entry/2025/09/25/213844
絶賛メンバー募集中ですので、ご興味ある方はぜひお話しさせてください〜〜！
