認可（OAuth2）の新常識：Cross App Access がすごい。未来の認可はこうなる
はじめに — 「許可外API」を“設計で”消す次の一手
拙稿「トークンは通すがテナントは通さない — OAuth 2.0で“許可外API”を終わらせる【Slack/Box実装】」では、Slack/Box など SaaS の許可外テナントへの API 呼び出しを、実装・プロキシ・ゲートウェイでどう防ぐかを解説しました。要は、「人や Bot が“どこの誰に”つないでいるか」を見える化し、許可リスト外は通さないという考え方です。
この課題にプロトコル側の解が出てきました。Okta が提唱する Cross App Access（XAA） は、OAuth を拡張してアプリ↔アプリの接続を企業の IdP 管理下に移します。これにより、ユーザーのクリックに頼らない（ノーコンセント）安全なトークン仲介と中央集権的な可視化が可能になります。背景には IETF で進む Identity & Authorization Chaining と、その具体的プロファイル Identity Assertion Authorization Grant（ID-JAG） があります。
本情報は 2025年10月時点のドラフトを元にしています。仕様は今後変わる可能性があります。最新のドラフトやベンダー公式ドキュメントを確認してください。
1. Okta / Cross App Access とは
1.1 Okta とは
Okta は SSO（OIDC/SAML）やアクセス制御を提供する IdP です。2025年、Okta は Cross App Access を発表し、エージェントやアプリ間連携の“見えない OAuth”に可視性と統制をもたらす方向性を示しました（現在 Early Access）。
1.2 Cross App Access（XAA）とは？
- 正体（ID-JAG）：IdP が発行した ID アサーション（OIDC ID Token や SAML）を材料に、IdP 署名の特別な JWT（ID-JAG） を得て、別アプリの認可サーバからアクセストークンを取得する拡張。レスポンスでは issued_token_type=urn:ietf:params:oauth:token-type:id-jag、JWT の typ は oauth-id-jag+jwt を用います。
- 下敷き（Identity Chaining）：RFC 8693（Token Exchange） と RFC 7523（JWT Bearer Grant） を組み合わせ、“誰が／どんな権限／どの経路” をドメインをまたいで引き継ぐパターンを定義。
- Microsoft の関与：Identity Chaining の IETF WG 版の初期リビジョン（-01, 2024-02-19） では、Arndt Schwenkschuster / Pieter Kasselman の所属が Microsoft と明記されています（後続版では所属表記が変更）。
2. OAuth 2.0 vs XAA（ID-JAG）— フローを並べて理解を深めてみる
2.1 従来の OAuth 2.0（Auth Code + PKCE）
ユーザーのログイン＋同意画面が必ず挟まる一般的なフローです。
IdP は SSO までは把握できますが、A→B の個別接続は各アプリ内で完結しがちで、中央集権的な可視化・停止が難しいのが弱点でした。
2.2 XAA（ID-JAG）— IdP が“仲裁者”になる
ユーザーの追加操作なしに、IdP ポリシーで接続可否を裁くのが肝です。
ステップ1：IdP へ Token Exchange（紹介状＝ID-JAG をもらう）
A → IdP に「B へ行くための紹介状（ID-JAG） をください」と頼む段階です。
POST https://idp.example.com/oauth2/token
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&
subject_token=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...&
subject_token_type=urn:ietf:params:oauth:token-type:id_token&
resource=https://auth.b.example.com/
# + client authentication (client_secret / private_key_jwt)
| パラメータ | ざっくり意味 | 何を示す？ / なぜ必要？ |
|---|---|---|
| grant_type=...token-exchange | 「トークン交換したい」 | OAuth の“交換”モードで呼んでいることを IdP に伝える。 |
| requested_token_type=id-jag | 「欲しいのは ID-JAG」 | 通常のアクセストークンではなく、紹介状 JWT（ID-JAG）を要求。 |
| subject_token=<ID トークン> | 「この人の身元証明」 | すでに OIDC でログイン済。誰の文脈かを示す“元ネタ”。 |
| subject_token_type=id_token | 元ネタの種類 | それが ID トークン（SAML の場合は対応タイプ）であることを宣言。 |
| resource=<B_AS の issuer> | 紹介状の宛先 | ID-JAG の 行き先（B の認可サーバ） を特定。B 側の issuer 値 を入れる。※ audience は本プロファイルでは使用しない（MUST NOT）。 |
✅ IdP はポリシーを評価し、OK なら 短命の ID-JAG（JWT） を A に返します（短命＝最新ポリシーを常に反映させるため）。
ステップ2：B_AS へ JWT Bearer Grant（B 用アクセストークンに変換）
A → B の認可サーバ（B_AS）に、もらった ID-JAG を差し出して B 向けアクセストークンを発行してもらいます。
POST https://auth.b.example.com/oauth2/token
Content-Type: application/x-www-form-urlencoded
grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer&
assertion=eyJhbGciOiJSUzI1NiIsInR5cCI6Im9hdXRoLWlkLWphZytqd3QifQ...
# + client authentication
| パラメータ | ざっくり意味 | 何を示す？ / なぜ必要？ |
|---|---|---|
| grant_type=...jwt-bearer | 「JWT の紹介状を持参」 | JWT を提示してトークン発行を受ける方式であることを宣言。 |
| assertion=<ID-JAG JWT> | 紹介状そのもの | ステップ1で IdP が発行した ID-JAG。B_AS は署名や iss、aud などを検証。 |
✅ 検証に成功すると B の API で使えるアクセストークンが返り、A は Authorization: Bearer ... で B_API を呼び出せます。
2.3 並べて要点だけを比較
| 観点 | OAuth 2.0 | XAA（ID-JAG） |
|---|---|---|
| 接続の裁定者 | 各アプリの同意フロー内で決定。IdP は把握しにくい。 | IdP が裁定。A→B 接続を管理者が中央で 許可/停止。 |
| ユーザ操作 | 毎回 同意画面。 | 基本 ノーコンセント（管理者のポリシーで自動審査）。 |
| 可視化 | 事後追跡が難しい。 | Admin Console の Managed connection に一覧化、停止で新規交換をブロック。 |
| 標準位置付け | RFC6749/7523/8693。 | Identity Chaining（WG）＋ID-JAG（WG）。 |
| AI/エージェント | リダイレクト同意は不向き。 | エージェント/アプリ間の安全な連携に最適化。 |
3. 実装視点：Resource 側／Requesting 側／管理者がやること
3.1 Resource App（API 提供側：B）
- 企業 IdP と SSO（OIDC/SAML） を構成。
- 認可サーバで JWT Bearer Grant（RFC7523） を受け付ける。
- IdP の JWKS で ID-JAG を検証（iss/aud/sub/client_id など）。
- 短寿命トークン＋送信者拘束（DPoP/mTLS） を検討（Identity Chaining のセキュリティ考慮）。
3.2 Requesting App（呼び出し元：A）
- OIDC でユーザー確立 → IdP の Token Exchange で ID-JAG を取得。
- ID-JAG を B の認可サーバに JWT Bearer Grant で提出し、B 向けアクセストークンを入手。
- 更新戦略：refresh_token は SHOULD NOT。短寿命×再交換を前提に。
3.3 管理者（IdP）
- Admin Console の Manage Connections で A（Requesting）⇄B（Resource） を方向付きで登録/停止。
- ログ/監査：ID-JAG 付与イベントがイベントタイプに追加（app.oauth2.token.grant.id_jag）。
- 前提：両アプリが “Connect with Okta” App Feature をサポートしている必要あり（接続確立の要件）。
4. まとめ
4.1 まとめ
「誰が／どのアプリから／何に触れるか」 を IdP ポリシーに寄せることで、UX（ノーコンセント）とガバナンスを同時に前進させるのが XAA/ID-JAG。AI エージェント時代の基盤として押さえておく価値があります。
4.2 標準化と賛同する企業などの動向
- Identity & Authorization Chaining（IETF OAuth WG）：最新版は -06（2025-09-12）。Token Exchange + JWT Bearer の組み合わせを規定。
- ID-JAG（IETF OAuth WG）：WG 採択 -00（2025-09-08）。id-jag の型や JWT typ=oauth-id-jag+jwt などを規定。
- Microsoft の関与：Identity Chaining 初期版（-01）の著者所属が Microsoft。WG 設計段階からの関与が読み取れます。
- 製品状況（Okta）：Early Access として Cross App Access を提供。Admin Console に Manage Connections タブが追加。
4.3 付録：用語の超ざっくり説明
- Identity Chaining：複数ドメインをまたいでも、“誰/権限/経路”を失わないようにトークンを交換（RFC8693） し、JWT ベアラー（RFC7523） で受け渡すパターン。
- ID-JAG：IdP が署名する身元＋権限の“紹介状”JWT。issued_token_type=id-jag で払い出し、別ドメインの AS に提示してアクセストークンに変換する。
4.4参考リンク
IETF / OAuth WG
- OAuth Identity & Authorization Chaining Across Domains（datatracker）
- Identity Assertion Authorization Grant（datatracker）
- OAuth Specs — Active Drafts（oauth.net）
Okta（Cross App Access, ドキュメント/ブログ/製品）
- Configure Cross App Access | Okta Identity Engine
- Manage Cross App Access connections
- Cross App Access | Controlling AI agent and app connections
- Press Release: Okta introduces Cross App Access
- Developer Blog: Integrate Your Enterprise AI Tools with Cross-App Access
- Developer Blog: Build Secure Agent-to-App Connections with Cross App Access
- Application Cross App Access Connections API（OpenAPI）
Discussion