サービス内で複数のOP・ASを連鎖させる（OAuth/OIDC Numa (Immersion) Workshop 2026）

2026/08/25 開催
OAuth/OIDC Numa (Immersion) Workshop 2026 発表資料

サービス内で複数のOP・ASを連鎖させる
実案件で悩んだトークンのチェイン、“OAuth Identity and Authorization Chaining” と見比べてみた

GMOサイバーセキュリティ byイエラエ株式会社
名古屋 謙彦

Transcript

1. OAuth/OIDC Numa (Immersion) Workshop 2026 サービス内で複数のOP・ASを連鎖させる 実案件で悩んだトークンのチェイン、 “OAuth Identity and Authorization Chaining” と見比べてみた GMOサイバーセキュリティ byイエラエ株式会社 サイバーセキュリティ事業本部 高度解析部 調査分析課 名古屋 謙彦 （@ayokura） Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved. OAuth/OIDC Numa (Immersion) Workshop 2026 1
2. 自己紹介 基本属性 名古屋 謙彦 （なごや よしひこ） GMOサイバーセキュリティ byイエラエ サイバーセキュリティ事業本部 高度解析部 調査分析課 CISSP / 情報処理安全確保支援士 経歴 インフラ/情シス あよくら @ayokura Identity Architect Security Consultant 関心 Digital Identity クリスチャン デジタルアイデンティティ大好き！ Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved. OAuth/OIDC Numa (Immersion) Workshop 2026 2
3. I-Dがいう「chaining」とは I-D §1（原文） 日本語で3要素 All protected resources involved in such a request need to know on whose behalf the request was originally initiated, what authorization was granted and optionally which other resource servers were called prior to making an authorization decision. This information needs to be preserved, even when a request crosses one or more trust domains. This document refers to this as “chaining”. 誰のために始まった要求か 何を許可されたか 必要なら、前段でどのResource Serverが呼ばれたか Trust Domainを越えても、下流の認可判断に必要な情報を失わない。 それを、このI-Dでは“chaining”と呼ぶ。 draft-ietf-oauth-identity-chaining-17 §1 Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved. OAuth/OIDC Numa (Immersion) Workshop 2026 3
4. Identity Chainingは、どこで使われるのか Base I-D Appendix A — representative, not exhaustive Multi-cloud／ Hybrid CI → External Resources Partner API Security Extend SSO to API Access Cross-domain API Authorization 元Userと中間者の contextをworkload／ trust domain間で保持 build／repository contextを別途保護され たresourceへ運ぶ partner serviceが他社 APIへUser authorization context を保ったままaccess IdPのidentity assertion をSaaS AS向け authorization grantへ exchange 別trust domainのAPIへ、 追加のinteractive flow なしでaccess このあと具体化する例 Cross-App Access（XAA ／ ID-JAG） Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved. AI Agent → External Tool OAuth/OIDC Numa (Immersion) Workshop 2026 4
5. なぜB用Access Tokenを取得するのか 比較軸：Bのauthorization boundaryを置くか 別architecture（B RSが直接受理） A Access Token Identity Chaining I-D A-side credential B-targeted JWT Authorization Grant B Resource Server 成立に必要なB側の判断 ・Aをissuerとして受理 ・B resource向けaudienceとして受理 ・scope/claim semanticsをBが理解 ・Aのauthorizationをresource accessの根拠として受理 B Authorization Server local trust / mapping / policy B用Access Token B Resource Server Bのauthorization boundaryを通し、BのAuthorization Serverが発行する、BのResource Server用Access Tokenへlocalizeする。 既存のSaaS/APIであるDomain Bへ、後からAとのtrust/連携を追加する場合にも自然に適用できる。 deployment scenario — I-Dの必須条件ではない Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved. OAuth/OIDC Numa (Immersion) Workshop 2026 5
6. 全体flow：3つのartifactを、2つの protocolでつなぐ 3つのartifact ＝ 2つのtoken ＋ 1つのgrant Trust Domain A Authorization Server A Trust Domain B Authorization Server B Client Domain A起点 Resource Server B ① ClientがBのAuthorization Serverを特定 ② RFC 8693 Token Exchange request ③ B向けJWT Authorization Grant ④ RFC 7523 JWT Authorization Grantを提示 ⑤ B用Access Token ⑥ B用Access Tokenでaccess A-side input token Token Exchangeへ入力するtoken 必ずしもAccess Tokenに限定しな い RFC 8693 Token Exchange B-targeted JWT Authorization Grant A発行・B AS宛 JWTだがprotocol roleはAccess Tokenではなくgrant Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved. RFC 7523 JWT Authorization Grant B用Access Token B発行・B RS用 OAuth/OIDC Numa (Immersion) Workshop 2026 6
7. A側：RFC 8693 Token Exchange wire request AS A policy gate output artifact B-targeted JWT Authorization Grant grant_type= urn:ietf:params:oauth: grant-type:token-exchange &subject_token= <A-side input token> &subject_token_type=<token type> &resource=https://as.b.example/ ・resource 又は audience の どちらか一方 がREQUIRED（対象はB AS） ・scopeは必要に応じて指定 ・actor_token等、RFC 8693の他parameterは optional/deployment dependent iss = AS A aud = AS B token_type = N_A issued_token_type = urn:...:token-type:jwt requestはvalidか？ B ASはknown/acceptableか？ B向けexchangeを許可するか？ claimsをadd/change/removeする か？ 必要なscope/contextへ絞るか？ ・audはrequested B ASをMUST identify ・単一B ASへのrestrictionが RECOMMENDED Token Exchangeは単なるformat変換ではない。 Aが「Bへ何を渡すか」を決めるboundary。 Identity Chaining I-D §2.3.1–2.3.4 / RFC 8693 Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved. OAuth/OIDC Numa (Immersion) Workshop 2026 7
8. 返却表現：access_token parameterだが、 Access Tokenではない AS A → Client：Token Exchange response（I-D Figure 3） { access_token requested tokenを運ぶresponse parameter。historical nameであり、issued tokenはOAuth Access Tokenでなくてもよい "access_token": "<JWT>", "token_type": "N_A", "issued_token_type": "urn:ietf:params:oauth:token-type:jwt", "expires_in": 60 issued_token_type } issued security tokenのrepresentation。ここではJWT token_type token_type: N_A Access Tokenではない/Access Tokenとして使えない Access Tokenとしてどう使うか。Access Tokenでない/Access Tokenとして使 えない時は N_A parameter name ≠ protocol role access_token → JWT Authorization Grant access_token に入っている。でも、Access Tokenとして使うものではない。 Identity Chaining I-D Figure 3 / RFC 8693 §2.2.1 Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved. OAuth/OIDC Numa (Immersion) Workshop 2026 8
9. Role：AS A発行・AS B宛のJWT Authorization Grant decoded JWT（B-targeted JWT Authorization Grant） { "iss": "AS A", "sub": "<subject>", "aud": "AS B", "exp": "<expiration>", "...": "identity / authorization context" } Issuer Presented by Consumed by Audience Purpose Not for AS A Client AS B AS B B用Access Tokenをrequestするgrant B Resource Server A-side input token B-targeted JWT grant B用AT 提示する先 AS A AS B RS B Protocol role Token Exchange input Authorization Grant Access Token Issuer deployment dependent AS A AS B Representation token-type dependent JWT token-type dependent Target/audience token-type dependent AS B B resource 同じJWTに見えても、issuer/audience/consumer/roleが違う。 Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved. OAuth/OIDC Numa (Immersion) Workshop 2026 9
10. B側：grantを検証し、B用Access Tokenへ 引き換える Client → AS B AS B → Client AS B：validation / trust / local policy grant_type= JWT validation urn:ietf:params:oauth: grant-type:jwt-bearer &assertion= <B-targeted JWT Authorization Grant> "access_token": "<B用Access Token>", "token_type": "Bearer", "expires_in": 60 iss / signature ・ aud = AS B ・ exp / time subjectをidentifyできるか } Trust / authority Aのpublic keyをtrustするか AがB向けgrantを発行してよいauthorityを持つか scope / resource = B protected resource（必要に応 じて） { B-local policy claimsをB semanticsで解釈できるか Bのauthorization policyで許可するか どのscope/Access Tokenを発行するか keyを知っている ≠ grant issuance authorityを信頼する ・Bearer と 60 はI-D Figure 6の example ・B用ATのrepresentation/token typeはdeployment dependent AS A response：token_type: N_A → grant AS B response：token_type: Bearer → Access Token （example） Aから来たgrantをBが検証し、BのpolicyでB用Access Tokenへ引き換える。 Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved. OAuth/OIDC Numa (Immersion) Workshop 2026 10
11. FlowからContextへ：Claims Transcription FLOW CONTEXT artifact / protocol / transport subject / claims / semantics / responsibility 凡例（両pointで共通）：add／change／remove ・ subject mapping可 A-side input token B ASはsubjectをidentifyできなければ MUST deny 1. Subject identifier mapping AS A transcription B-targeted JWT Authorization Grant RFC 7523：sub claim MUST be present 2. Data minimization AS B transcription 3. Scope control / downscoping B-local authorization ／ B用Access Token 4. JWT grant claimsをB側ATへ含める どこでtranscribeするかはdeployment次第。 書く側と読む側は、claim semanticsとaccess controlへ合意する。 Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved. OAuth/OIDC Numa (Immersion) Workshop 2026 11
12. Security/Lifecycle Guardrails CONTEXT SECURITY / LIFECYCLE RFC 8693 RFC 7523 A-side input token B-targeted JWT Authorization Grant B用Access Token / RT Authorized use of Subject Token Bearer / Replay Sender Constraint / Lifecycle Client authentication + 提示権限 の確認 RFC 9700 BCP ＋ B Refresh Token → SHOULD NOT 最大の注意点 — short-lived / single-use / Client auth Privacy（3 artifact横断） minimum necessary claims ＋ privacy policy alignment across trust domains Flowを実装するだけでは足りない。 各artifactの提示権限・replay・寿命を決める。 Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved. OAuth/OIDC Numa (Immersion) Workshop 2026 12
13. 引き渡されるClaim：各Componentはど こまで責任を持つのか I-Dと似た設計経験を見比べる 1/3 — Claims When transcribing claims, it is important that both the place where the claims are given and where they are interpreted agree on the semantics and that the access controls are consistent. — I-D §2.5 AS A ・A-side credentialを検証 ・Bへ渡すclaimsを選択/transcribe ・B-targeted grantのissuerとして、 assertした内容に責任 AS B ・grantを検証 ・subjectをidentify/mapping ・B-local semanticsで解釈し authorization ・B用Access Tokenを発行 RS B ・B用Access TokenをBとのcontractとし て解釈 ・resource access controlを実行 provenance → mapping / semantics → final authorization contract 実案件（抽象化）：似た設計では、Bが複数経路を共通schemaへ正規化した。 値を揃えるだけでなく、source of truth/mapping/schema変更責任の明文化が必要だっ た。 Claims Transcriptionは値の変換だけではない。 意味と責任をdomain間で分解し、合意する。 Identity Chaining I-D §2.4.2 / §2.5 Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved. OAuth/OIDC Numa (Immersion) Workshop 2026 13
14. Lifecycle：AvailabilityとFreshnessをどう 両立するか I-Dと似た設計経験を見比べる 2/3 — Lifecycle B Refresh Token: SHOULD NOT MUST NOT ではない — I-D §5.4 Freshnessを優先する原則 Availabilityを優先する要件 ・B Refresh Tokenを持たない ・Access Token expiry → JWT Grantがvalid/reusableなら同じ grantを再提示 ・grantがunusableならAから新しいgrantを取得し、A-side state ／policyを再評価する ・A unavailable ・user-not-present / offline ・Bで一定時間、継続したい ・B独自credentialを持ち、A stateからの分離riskを引き受ける 正の例は一般のRFC 8693 §2.2.1。I-DのB RT推奨ではない。 logout / revocation A state bounded staleness window B credential absolute expiry Availabilityを得るなら、A stateとのstalenessを明示的にboundする。 Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved. OAuth/OIDC Numa (Immersion) Workshop 2026 14
15. 自然に見えるprotocolを、 実用へ持っていく難しさ I-Dと似た設計経験を見比べる — Implementation Reality Client → AS A Client → AS B RFC 8693 Token Exchange RFC 7523 JWT Authorization Grant 1. SDK / Library Support grant type/parameterを安全に 表現できるか 2. Conformance / Interoperability token type、claims、 issuer/audience、errorを同じ意 味で扱えるか 将来：RFC publication → implementation adoption → SDK/library support → common tests/interoperability → 導入しやすくなる 二つのtoken endpoint callに見える 3. Security Assurance authz-critical codeのreview、 hardening、testをどう得るか 4. Operations / Maintenance key rotation、observability、 upgrade、継続maintenanceを 誰が担うか AI-assisted implementation → coding cost ↓ Authorization assurance → review/interop/operationsは残る 仕様の自然さと、実装ecosystemの成熟は別。 supportが育つまで、どこまで待ち、どこまで自分で埋めるか？ Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved. OAuth/OIDC Numa (Immersion) Workshop 2026 15
16. Identity Chainingの具体例：Cross-App Access Identity Assertion JWT Authorization Grant（ID-JAG） User App A ／ Client 1 User authenticates（SSO） Shared IdP ／ AS A App B Authorization Server App B API 2 RFC 8693：Identity Assertionを subject_tokenに 3 ID-JAG（aud = App B Resource AS） 4 RFC 7523：ID-JAGをredeem 5 B用Access Token 6 B用Access Tokenでaccess Identity Chaining（generic base framework） → profiled for XAA → Identity Assertion JWT Authorization Grant（ID-JAG） IdPはSSO trustとcross-app brokeringを担う。 Resource ASはlocal policyとAccess Token issuanceを維持する。 Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved. OAuth/OIDC Numa (Immersion) Workshop 2026 16
17. AI AgentがExternal Toolへaccessするま で Identity binding → discovery → Tool-targeted ID-JAG → Tool用Access Token Tool Authorization Server ／ ID-JAG support discovered Agent identity binding established AI Agent → Enterprise IdP ／ AS A RFC 8693 Tool-targeted ID-JAG AI Agent → External Tool AS Tool AS RFC 7523 local subject scope policy Access Token Tool用Access Token AI Agent → Tool API Agentへ万能tokenを渡すのではない。 Tool向けgrantを、Tool用Access Tokenへ引き換える。 Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved. OAuth/OIDC Numa (Immersion) Workshop 2026 17
18. 技術の前に、現実の関係性と制約がある OAuth common pattern 現実の関係性と制約 Parties / Topology A-side credential RFC 8693 Token Exchange Trust / Authority architectureへ写す B-targeted JWT Authorization Grant RFC 7523 JWT Authorization Grant Claims / Subject B用Access Token Lifecycle Ecosystem Protocolは、現実の関係性を置き換えない。それをarchitectureへ写す。 Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved. OAuth/OIDC Numa (Immersion) Workshop 2026 18