アイデンティティ仕様マップ

OAuth、OpenID、ワークロードアイデンティティ、クレデンシャルの仕様をレイヤー別に並べた。各仕様の進捗、土台にしている仕様、対応を公式に文書化している製品をまとめている。

利用状況には、公式のドキュメント(ベンダーやプロジェクト自身のもの、または標準化団体がその名前を挙げているページ)に対応が明記されているものだけを載せている。引用した文言がそのページにまだあるかは毎週確認している。実験的・アルファ・ベータの対応は「プレビュー」として別に数える。

状態と出典の確認日時: 11月11日 16:48 UTC

いま動いている仕様

直近 90 日の動き (新しい revision、このサイトの解説、draft 名を挙げた ML スレッド) の多い順。

  1. WIMSE HTTP Message Signatures10 件の動き (90 日)WIMSE 週次 GitHub ダイジェスト:HTTP-Sig のテストベクターと nonce の例、共有トラストアンカーに関する issue が新規に立ち、綴り修正の PR が出た
  2. AI Identity Management System (AIMS)9 件の動き (90 日)evidence-binding の著者らは、停止された先行アクターに関する記述を RFC 8693 第4.1節と矛盾しないよう限定することにした。
  3. Selective Disclosure for JWTs (SD-JWT)6 件の動き (90 日)oauth-delegate-sd-jwt で、cnf、exp、nbf などのセキュリティクレームが delegate_payload からベースの KB-SD-JWT ペイロードへ移り、意味も定義される。
  4. Transaction Tokens5 件の動き (90 日)evidence-binding の著者らは、停止された先行アクターに関する記述を RFC 8693 第4.1節と矛盾しないよう限定することにした。
  5. Identity and Authorization Chaining4 件の動き (90 日)IETF 127 ハッカソンの WIMSE エージェント呼び出しチェーン相互運用計画に対し、失効とフェイルクローズを中心とした異常系シナリオが提案された。
  6. SD-JWT-based Verifiable Credentials (SD-JWT VC)4 件の動き (90 日)Secdir の査読者が draft-ietf-oauth-sd-jwt-vc-26 を「Ready」と評価し、以前の指摘はすべて解決済みとされた。

仕様ごとの詳細

グラントとフロー

OAuth 2.0

RFC として公開済みRFC 6749

認可の基本フレームワーク。クライアントが認可サーバーからアクセストークンを取得し、リソースサーバーに提示する。

関係図
flowchart LR
  s_oauth2["OAuth 2.0"]
  s_oauth21["OAuth 2.1"]
  s_pkce["PKCE"]
  s_par["Pushed Authorization Requests"]
  s_rar["Rich Authorization Requests"]
  s_device_grant["Device Authorization Grant"]
  s_first_party_apps["OAuth for First-Party Apps"]
  s_token_exchange["Token Exchange"]
  s_jwt_bearer["JWT Bearer Grant and Client Authentication"]
  s_introspection["Token Introspection"]
  s_dpop["DPoP"]
  s_mtls["Mutual-TLS Client Authentication and Certificate-Bound Tokens"]
  s_attestation_client_auth["Attestation-Based Client Authentication"]
  s_as_metadata["Authorization Server Metadata"]
  s_dcr["Dynamic Client Registration"]
  s_openid4vci["OpenID for Verifiable Credential Issuance"]
  s_openid4vp["OpenID for Verifiable Presentations"]
  s_oidc_core["OpenID Connect Core"]
  s_oauth_security_bcp["OAuth 2.0 Security Best Current Practice"]
  s_browser_based_apps["OAuth 2.0 for Browser-Based Applications"]
  s_native_apps["OAuth 2.0 for Native Apps"]
  s_iss_authz_response["Authorization Server Issuer Identification"]
  s_jar["JWT-Secured Authorization Request"]
  s_refresh_token_expiration["Refresh Token and Authorization Expiration"]
  s_revocation["Token Revocation"]
  s_aims["AI Identity Management System"]
  style s_oauth2 stroke-width:3px
  s_oauth21 -->|置き換え予定| s_oauth2
  s_pkce -->|拡張対象| s_oauth2
  s_par -->|拡張対象| s_oauth2
  s_rar -->|拡張対象| s_oauth2
  s_device_grant -->|拡張対象| s_oauth2
  s_first_party_apps -->|拡張対象| s_oauth2
  s_token_exchange -->|拡張対象| s_oauth2
  s_jwt_bearer -->|拡張対象| s_oauth2
  s_introspection -->|拡張対象| s_oauth2
  s_dpop -->|拡張対象| s_oauth2
  s_mtls -->|拡張対象| s_oauth2
  s_attestation_client_auth -->|拡張対象| s_oauth2
  s_as_metadata -->|拡張対象| s_oauth2
  s_dcr -->|拡張対象| s_oauth2
  s_openid4vci -->|土台とする仕様| s_oauth2
  s_openid4vp -->|土台とする仕様| s_oauth2
  s_oidc_core -->|土台とする仕様| s_oauth2
  s_oauth_security_bcp -->|組み合わせ| s_oauth2
  s_browser_based_apps -->|拡張対象| s_oauth2
  s_native_apps -->|拡張対象| s_oauth2
  s_iss_authz_response -->|拡張対象| s_oauth2
  s_jar -->|拡張対象| s_oauth2
  s_refresh_token_expiration -->|拡張対象| s_oauth2
  s_revocation -->|拡張対象| s_oauth2
  s_aims -->|土台とする仕様| s_oauth2

解説

公式に文書化された対応

出典付きの対応情報はまだ集めていない。普及していないという意味ではない。

OAuth 2.1

WG ドラフトdraft-ietf-oauth-v2-1-172026-10-31

OAuth 2.0 とそのセキュリティのベストプラクティスを統合する。すべての認可コードフローで PKCE を使い、implicit と password グラントを廃止し、リダイレクト URI の完全一致を求める。

関係図
flowchart LR
  s_oauth21["OAuth 2.1"]
  s_oauth2["OAuth 2.0"]
  s_pkce["PKCE"]
  s_deferred_token_response["Deferred Token Response"]
  style s_oauth21 stroke-width:3px
  s_oauth21 -->|置き換え予定| s_oauth2
  s_oauth21 -->|土台とする仕様| s_pkce
  s_deferred_token_response -->|拡張対象| s_oauth21

解説

公式に文書化された対応

出典付きの対応情報はまだ集めていない。普及していないという意味ではない。

PKCE

RFC として公開済みRFC 7636

使い捨ての秘密値で認可コードを要求元のクライアントに結び付け、横取りされたコードを引き換えられないようにする。

関係図
flowchart LR
  s_pkce["PKCE"]
  s_oauth2["OAuth 2.0"]
  s_oauth21["OAuth 2.1"]
  s_fapi2["FAPI 2.0 Security Profile"]
  s_native_apps["OAuth 2.0 for Native Apps"]
  style s_pkce stroke-width:3px
  s_pkce -->|拡張対象| s_oauth2
  s_oauth21 -->|土台とする仕様| s_pkce
  s_fapi2 -->|土台とする仕様| s_pkce
  s_native_apps -->|土台とする仕様| s_pkce

解説

公式に文書化された対応

出典付きの対応情報はまだ集めていない。普及していないという意味ではない。

Pushed Authorization Requests (PAR)

RFC として公開済みRFC 9126

クライアントは認可リクエストを先にバックチャネルでサーバーへ送り、ブラウザーには参照値だけを渡す。

関係図
flowchart LR
  s_par["Pushed Authorization Requests"]
  s_oauth2["OAuth 2.0"]
  s_fapi2["FAPI 2.0 Security Profile"]
  s_jar["JWT-Secured Authorization Request"]
  style s_par stroke-width:3px
  s_par -->|拡張対象| s_oauth2
  s_fapi2 -->|土台とする仕様| s_par
  s_jar -->|組み合わせ| s_par

解説

公式に文書化された対応

  • PingFederate (IdP): PAR(Pushed Authorization Request)エンドポイント 出典 (確認 2026-11-11)
  • Keycloak (IdP): サーバーの対応機能として PAR を掲載 出典 (確認 2026-11-11)
  • Spring Authorization Server (ライブラリ): PAR(Pushed Authorization Request)エンドポイント 出典 (確認 2026-11-11)
  • Duende IdentityServer (ライブラリ): 対応仕様の一覧に RFC 9126 を掲載 出典 (確認 2026-11-11)

Rich Authorization Requests (RAR)

RFC として公開済みRFC 9396

粗いスコープ文字列の代わりに、金額や受取人を含む特定の支払いのような構造化された authorization_details を使う。

関係図
flowchart LR
  s_rar["Rich Authorization Requests"]
  s_oauth2["OAuth 2.0"]
  s_rar_metadata_remediation["RAR Metadata and Error Remediation"]
  style s_rar stroke-width:3px
  s_rar -->|拡張対象| s_oauth2
  s_rar_metadata_remediation -->|拡張対象| s_rar

解説

公式に文書化された対応

  • Auth0 (IdP): PAR を使う認可コードフローと CIBA で authorization_details を扱う 出典 (確認 2026-11-11)
  • PingFederate (IdP): OAuth の Rich Authorization Requests に対応 出典 (確認 2026-11-11)
  • node-oidc-provider (ライブラリ): 実装済み仕様の一覧に RFC 9396 を掲載 出典 (確認 2026-11-11)

Device Authorization Grant

RFC として公開済みRFC 8628

テレビや CLI のようにブラウザーやキーボードのないデバイスが、ユーザーに別のデバイスで承認してもらってトークンを取得する。

関係図
flowchart LR
  s_device_grant["Device Authorization Grant"]
  s_oauth2["OAuth 2.0"]
  s_cross_device_bcp["Security of Cross-Device Flows"]
  style s_device_grant stroke-width:3px
  s_device_grant -->|拡張対象| s_oauth2
  s_cross_device_bcp -->|組み合わせ| s_device_grant

解説

公式に文書化された対応

  • Microsoft Entra ID (IdP): デバイス認可グラントに対応 出典 (確認 2026-11-11)
  • Okta (IdP): org とカスタムの両方の認可サーバーでのデバイス認可グラント 出典 (確認 2026-11-11)
  • Keycloak (IdP): サーバーの対応機能としてデバイスフローを掲載 出典 (確認 2026-11-11)
  • Authlib (ライブラリ): RFC 8628 の汎用実装を提供 出典 (確認 2026-11-11)

OAuth for First-Party Apps

WG ラストコール・取りまとめdraft-ietf-oauth-first-party-apps-042026-08-26

認可サーバーと同じ事業者が提供するアプリ向けに、ブラウザーのリダイレクトを使わないネイティブな認可チャレンジのフローを定める。

関係図
flowchart LR
  s_first_party_apps["OAuth for First-Party Apps"]
  s_oauth2["OAuth 2.0"]
  style s_first_party_apps stroke-width:3px
  s_first_party_apps -->|拡張対象| s_oauth2

解説

公式に文書化された対応

出典付きの対応情報はまだ集めていない。普及していないという意味ではない。

Authorization Server Issuer Identification

状態不明

認可レスポンスに iss パラメータを加え、どの認可サーバーが応答したかをクライアントが判別できるようにする。mix-up 攻撃への対策。

関係図
flowchart LR
  s_iss_authz_response["Authorization Server Issuer Identification"]
  s_oauth2["OAuth 2.0"]
  style s_iss_authz_response stroke-width:3px
  s_iss_authz_response -->|拡張対象| s_oauth2

開く

公式に文書化された対応

出典付きの対応情報はまだ集めていない。普及していないという意味ではない。

JWT-Secured Authorization Request (JAR)

状態不明

認可要求のパラメータを署名 (任意で暗号化) した JWT に入れ、値または参照で渡す。要求に完全性・送信元認証・機密性を与える。

関係図
flowchart LR
  s_jar["JWT-Secured Authorization Request"]
  s_oauth2["OAuth 2.0"]
  s_jwt["JSON Web Token"]
  s_par["Pushed Authorization Requests"]
  style s_jar stroke-width:3px
  s_jar -->|拡張対象| s_oauth2
  s_jar -->|土台とする仕様| s_jwt
  s_jar -->|組み合わせ| s_par

開く

公式に文書化された対応

出典付きの対応情報はまだ集めていない。普及していないという意味ではない。

Refresh Token and Authorization Expiration

状態不明

リフレッシュトークンと、その元になるユーザー認可の有効期限をクライアントに伝える、トークンエンドポイントの新しい応答パラメータ。

関係図
flowchart LR
  s_refresh_token_expiration["Refresh Token and Authorization Expiration"]
  s_oauth2["OAuth 2.0"]
  style s_refresh_token_expiration stroke-width:3px
  s_refresh_token_expiration -->|拡張対象| s_oauth2

開く

公式に文書化された対応

出典付きの対応情報はまだ集めていない。普及していないという意味ではない。

Deferred Token Response

状態不明

トークンエンドポイントがトークンの代わりに deferral code とポーリング間隔を返せるようにし、どのグラントでもポーリングやコールバックで非同期に完了できるようにする。

関係図
flowchart LR
  s_deferred_token_response["Deferred Token Response"]
  s_oauth21["OAuth 2.1"]
  style s_deferred_token_response stroke-width:3px
  s_deferred_token_response -->|拡張対象| s_oauth21

開く

公式に文書化された対応

出典付きの対応情報はまだ集めていない。普及していないという意味ではない。

RAR Metadata and Error Remediation

状態不明

サーバーが対応する authorization details の型を発見するためのメタデータと、authorization details 不足による失敗を通知・是正する標準的な方法。

関係図
flowchart LR
  s_rar_metadata_remediation["RAR Metadata and Error Remediation"]
  s_rar["Rich Authorization Requests"]
  s_as_metadata["Authorization Server Metadata"]
  style s_rar_metadata_remediation stroke-width:3px
  s_rar_metadata_remediation -->|拡張対象| s_rar
  s_rar_metadata_remediation -->|組み合わせ| s_as_metadata

開く

公式に文書化された対応

出典付きの対応情報はまだ集めていない。普及していないという意味ではない。

セキュリティ実践

OAuth 2.0 Security Best Current Practice

状態不明

OAuth 2.0 の現行セキュリティ指針。更新された脅威モデル、RFC 6749 以降に見つかった攻撃への対策、implicit grant など安全性の低い方式の非推奨化をまとめる。

関係図
flowchart LR
  s_oauth_security_bcp["OAuth 2.0 Security Best Current Practice"]
  s_oauth2["OAuth 2.0"]
  s_security_topics_update["Updates to OAuth 2.0 Security BCP"]
  s_browser_based_apps["OAuth 2.0 for Browser-Based Applications"]
  style s_oauth_security_bcp stroke-width:3px
  s_oauth_security_bcp -->|組み合わせ| s_oauth2
  s_security_topics_update -->|拡張対象| s_oauth_security_bcp
  s_browser_based_apps -->|土台とする仕様| s_oauth_security_bcp

開く

公式に文書化された対応

出典付きの対応情報はまだ集めていない。普及していないという意味ではない。

Updates to OAuth 2.0 Security BCP

状態不明

RFC 6749・RFC 6750・RFC 9700 のセキュリティ指針を、公開後に見つかった脅威まで拡張する。

関係図
flowchart LR
  s_security_topics_update["Updates to OAuth 2.0 Security BCP"]
  s_oauth_security_bcp["OAuth 2.0 Security Best Current Practice"]
  style s_security_topics_update stroke-width:3px
  s_security_topics_update -->|拡張対象| s_oauth_security_bcp

開く

公式に文書化された対応

出典付きの対応情報はまだ集めていない。普及していないという意味ではない。

OAuth 2.0 for Browser-Based Applications

状態不明

OAuth 2.0 を使う SPA などブラウザベースアプリの脅威・影響・ベストプラクティス。backend-for-frontend パターンを含む。

関係図
flowchart LR
  s_browser_based_apps["OAuth 2.0 for Browser-Based Applications"]
  s_oauth_security_bcp["OAuth 2.0 Security Best Current Practice"]
  s_oauth2["OAuth 2.0"]
  style s_browser_based_apps stroke-width:3px
  s_browser_based_apps -->|土台とする仕様| s_oauth_security_bcp
  s_browser_based_apps -->|拡張対象| s_oauth2

開く

公式に文書化された対応

出典付きの対応情報はまだ集めていない。普及していないという意味ではない。

OAuth 2.0 for Native Apps

状態不明

ネイティブアプリの認可要求は外部ユーザーエージェント (主にシステムブラウザ) 経由に限る、という実践。その安全性・使い勝手上の理由と、アプリとサーバー側の実装方法。

関係図
flowchart LR
  s_native_apps["OAuth 2.0 for Native Apps"]
  s_oauth2["OAuth 2.0"]
  s_pkce["PKCE"]
  style s_native_apps stroke-width:3px
  s_native_apps -->|拡張対象| s_oauth2
  s_native_apps -->|土台とする仕様| s_pkce

開く

公式に文書化された対応

出典付きの対応情報はまだ集めていない。普及していないという意味ではない。

Security of Cross-Device Flows

状態不明

ある端末で始めて別の端末で完了するフローに対する脅威、実践的な対策、プロトコル選定の指針、形式解析の結果。

関係図
flowchart LR
  s_cross_device_bcp["Security of Cross-Device Flows"]
  s_device_grant["Device Authorization Grant"]
  s_ciba["Client-Initiated Backchannel Authentication"]
  style s_cross_device_bcp stroke-width:3px
  s_cross_device_bcp -->|組み合わせ| s_device_grant
  s_cross_device_bcp -->|組み合わせ| s_ciba

開く

公式に文書化された対応

出典付きの対応情報はまだ集めていない。普及していないという意味ではない。

委譲とチェーン

Token Exchange

RFC として公開済みRFC 8693

クライアントがあるトークンを別のトークンに交換する。たとえばユーザーに代わって別の audience に対して行動するために使う。

関係図
flowchart LR
  s_token_exchange["Token Exchange"]
  s_oauth2["OAuth 2.0"]
  s_identity_chaining["Identity and Authorization Chaining"]
  s_id_jag["Identity Assertion JWT Authorization Grant"]
  s_txn_tokens["Transaction Tokens"]
  style s_token_exchange stroke-width:3px
  s_token_exchange -->|拡張対象| s_oauth2
  s_identity_chaining -->|土台とする仕様| s_token_exchange
  s_id_jag -->|土台とする仕様| s_token_exchange
  s_txn_tokens -->|土台とする仕様| s_token_exchange

解説

公式に文書化された対応

  • Keycloak (IdP): RFC 8693 を実装した標準のトークン交換 出典 (確認 2026-11-11)
  • Google Cloud (クラウド): Security Token Service が標準の OAuth 2.0 トークン交換を実装 出典 (確認 2026-11-11)
  • Okta (IdP): カスタム認可サーバーでの On-Behalf-Of トークン交換 出典 (確認 2026-11-11)

JWT Bearer Grant and Client Authentication

RFC として公開済みRFC 7523

署名付き JWT を、トークンエンドポイントでの認可グラントやクライアント認証情報として使う。

関係図
flowchart LR
  s_jwt_bearer["JWT Bearer Grant and Client Authentication"]
  s_jwt["JSON Web Token"]
  s_oauth2["OAuth 2.0"]
  s_identity_chaining["Identity and Authorization Chaining"]
  s_id_jag["Identity Assertion JWT Authorization Grant"]
  s_spiffe_client_auth["OAuth SPIFFE Client Authentication"]
  style s_jwt_bearer stroke-width:3px
  s_jwt_bearer -->|土台とする仕様| s_jwt
  s_jwt_bearer -->|拡張対象| s_oauth2
  s_identity_chaining -->|土台とする仕様| s_jwt_bearer
  s_id_jag -->|土台とする仕様| s_jwt_bearer
  s_spiffe_client_auth -->|プロファイル対象| s_jwt_bearer

解説

公式に文書化された対応

出典付きの対応情報はまだ集めていない。普及していないという意味ではない。

Identity and Authorization Chaining

承認済み、RFC Editor 待ちdraft-ietf-oauth-identity-chaining-172026-08-21

あるトラストドメインのトークンを別のドメインで使えるグラントに交換し、ドメインをまたいでアイデンティティと認可を運ぶ。

関係図
flowchart LR
  s_identity_chaining["Identity and Authorization Chaining"]
  s_token_exchange["Token Exchange"]
  s_jwt_bearer["JWT Bearer Grant and Client Authentication"]
  s_id_jag["Identity Assertion JWT Authorization Grant"]
  style s_identity_chaining stroke-width:3px
  s_identity_chaining -->|土台とする仕様| s_token_exchange
  s_identity_chaining -->|土台とする仕様| s_jwt_bearer
  s_id_jag -->|プロファイル対象| s_identity_chaining

解説

公式に文書化された対応

出典付きの対応情報はまだ集めていない。普及していないという意味ではない。

Identity Assertion JWT Authorization Grant (ID-JAG)

WG ドラフトdraft-ietf-oauth-identity-assertion-authz-grant-062026-10-31

企業の IdP が短命なグラントを発行し、SSO でつながったアプリが同意のリダイレクトなしに別のアプリのアクセストークンを取得できるようにする。

関係図
flowchart LR
  s_id_jag["Identity Assertion JWT Authorization Grant"]
  s_identity_chaining["Identity and Authorization Chaining"]
  s_token_exchange["Token Exchange"]
  s_jwt_bearer["JWT Bearer Grant and Client Authentication"]
  style s_id_jag stroke-width:3px
  s_id_jag -->|プロファイル対象| s_identity_chaining
  s_id_jag -->|土台とする仕様| s_token_exchange
  s_id_jag -->|土台とする仕様| s_jwt_bearer

解説ディープダイブ

公式に文書化された対応

  • Model Context Protocol (仕様): Enterprise-Managed Authorization 拡張が ID-JAG の上に作られている 出典 (確認 2026-11-11)
  • Okta (IdP): Cross App Access(XAA)が ID-JAG のフローを実装している 出典 (確認 2026-11-11)
  • Ping Identity (PingFederate 13.1) (IdP): PingFederate 13.1 が OAuth のトークン交換で ID-JAG を発行する 出典 (確認 2026-11-11)
  • Keycloak (IdP)実験的: 受信側としてのみ ID-JAG を受け付ける(実験的機能) 出典 (確認 2026-11-11)

Transaction Tokens

WG ラストコール・取りまとめdraft-ietf-oauth-transaction-tokens-112026-08-21

API ゲートウェイの背後で、ユーザーとリクエストの文脈を内部のワークロードの連鎖に運ぶ短命なトークン。

関係図
flowchart LR
  s_txn_tokens["Transaction Tokens"]
  s_token_exchange["Token Exchange"]
  style s_txn_tokens stroke-width:3px
  s_txn_tokens -->|土台とする仕様| s_token_exchange

解説

公式に文書化された対応

  • IBM Verify (IdP): draft-ietf-oauth-transaction-tokens に基づくトランザクショントークンを発行する 出典 (確認 2026-11-11)

トークン形式

JSON Web Token (JWT)

RFC として公開済みRFC 7519

署名(または暗号化)されたクレームのコンパクトな集合。OAuth と OpenID の多くのトークンが使う形式。

関係図
flowchart LR
  s_jwt["JSON Web Token"]
  s_jwt_bearer["JWT Bearer Grant and Client Authentication"]
  s_jwt_at["JWT Access Token Profile"]
  s_jwt_bcp["JWT Best Current Practices"]
  s_sd_jwt["Selective Disclosure for JWTs"]
  s_wimse_creds["WIMSE Workload Credentials"]
  s_status_list["Token Status List"]
  s_oidc_core["OpenID Connect Core"]
  s_set["Security Event Token"]
  s_jar["JWT-Secured Authorization Request"]
  style s_jwt stroke-width:3px
  s_jwt_bearer -->|土台とする仕様| s_jwt
  s_jwt_at -->|プロファイル対象| s_jwt
  s_jwt_bcp -->|組み合わせ| s_jwt
  s_sd_jwt -->|土台とする仕様| s_jwt
  s_wimse_creds -->|土台とする仕様| s_jwt
  s_status_list -->|土台とする仕様| s_jwt
  s_oidc_core -->|土台とする仕様| s_jwt
  s_set -->|土台とする仕様| s_jwt
  s_jar -->|土台とする仕様| s_jwt

解説

公式に文書化された対応

出典付きの対応情報はまだ集めていない。普及していないという意味ではない。

JWT Access Token Profile

RFC として公開済みRFC 9068

JWT として発行するアクセストークンの標準的な構成を定め、異なるベンダーのリソースサーバーが同じ方法で検証できるようにする。

関係図
flowchart LR
  s_jwt_at["JWT Access Token Profile"]
  s_jwt["JSON Web Token"]
  s_introspection["Token Introspection"]
  style s_jwt_at stroke-width:3px
  s_jwt_at -->|プロファイル対象| s_jwt
  s_introspection -.-|代替| s_jwt_at

解説

公式に文書化された対応

出典付きの対応情報はまだ集めていない。普及していないという意味ではない。

JWT Best Current Practices (bis)

承認済み、RFC Editor 待ちdraft-ietf-oauth-rfc8725bis-102026-11-06

JWT を安全に検証するための RFC 8725 の指針を更新する。アルゴリズム、明示的な型付け、audience と issuer の確認を扱う。

関係図
flowchart LR
  s_jwt_bcp["JWT Best Current Practices"]
  s_jwt["JSON Web Token"]
  style s_jwt_bcp stroke-width:3px
  s_jwt_bcp -->|組み合わせ| s_jwt

解説

公式に文書化された対応

出典付きの対応情報はまだ集めていない。普及していないという意味ではない。

Token Introspection

RFC として公開済みRFC 7662

リソースサーバーが認可サーバーに、トークンが有効か、何を許可しているかを問い合わせる。

関係図
flowchart LR
  s_introspection["Token Introspection"]
  s_oauth2["OAuth 2.0"]
  s_jwt_at["JWT Access Token Profile"]
  s_revocation["Token Revocation"]
  style s_introspection stroke-width:3px
  s_introspection -->|拡張対象| s_oauth2
  s_introspection -.-|代替| s_jwt_at
  s_revocation -->|組み合わせ| s_introspection

解説

公式に文書化された対応

出典付きの対応情報はまだ集めていない。普及していないという意味ではない。

Selective Disclosure for JWTs (SD-JWT)

RFC として公開済みRFC 9901

保持者がクレームの一部だけを開示できる JWT。任意で鍵束縛の証明を付けられる。

関係図
flowchart LR
  s_sd_jwt["Selective Disclosure for JWTs"]
  s_jwt["JSON Web Token"]
  s_sd_jwt_vc["SD-JWT-based Verifiable Credentials"]
  s_delegate_sd_jwt["Delegate SD-JWT"]
  style s_sd_jwt stroke-width:3px
  s_sd_jwt -->|土台とする仕様| s_jwt
  s_sd_jwt_vc -->|プロファイル対象| s_sd_jwt
  s_delegate_sd_jwt -->|拡張対象| s_sd_jwt

解説

公式に文書化された対応

出典付きの対応情報はまだ集めていない。普及していないという意味ではない。

Token Revocation

状態不明

クライアントがリフレッシュトークンやアクセストークンが不要になったことを認可サーバーに伝えるエンドポイント。そのトークンと、場合によっては同じグラントから出た他のトークンも無効化する。

関係図
flowchart LR
  s_revocation["Token Revocation"]
  s_oauth2["OAuth 2.0"]
  s_introspection["Token Introspection"]
  style s_revocation stroke-width:3px
  s_revocation -->|拡張対象| s_oauth2
  s_revocation -->|組み合わせ| s_introspection

開く

公式に文書化された対応

出典付きの対応情報はまだ集めていない。普及していないという意味ではない。

Delegate SD-JWT

状態不明

Key Binding JWT 自体を SD-JWT (任意で独自の key binding 付き) にできるようにして、SD-JWT の holder が別の holder に委任できるようにする。エージェント型システム向け。

関係図
flowchart LR
  s_delegate_sd_jwt["Delegate SD-JWT"]
  s_sd_jwt["Selective Disclosure for JWTs"]
  style s_delegate_sd_jwt stroke-width:3px
  s_delegate_sd_jwt -->|拡張対象| s_sd_jwt

開く

公式に文書化された対応

出典付きの対応情報はまだ集めていない。普及していないという意味ではない。

送信者制約トークン

DPoP

RFC として公開済みRFC 9449

トークンをクライアントが持つ鍵に結び付け、リクエストごとの署名付きヘッダーでアプリケーション層から所持を証明する。

関係図
flowchart LR
  s_dpop["DPoP"]
  s_oauth2["OAuth 2.0"]
  s_mtls["Mutual-TLS Client Authentication and Certificate-Bound Tokens"]
  s_wpt["WIMSE Workload Proof Token"]
  s_fapi2["FAPI 2.0 Security Profile"]
  style s_dpop stroke-width:3px
  s_dpop -->|拡張対象| s_oauth2
  s_dpop -.-|代替| s_mtls
  s_wpt -.-|代替| s_dpop
  s_fapi2 -->|土台とする仕様| s_dpop

開く

公式に文書化された対応

  • Okta (IdP): RFC 9449 に基づく、DPoP による送信者制約アクセストークン 出典 (確認 2026-11-11)
  • Auth0 (IdP): 対応するグラントタイプで DPoP による送信者制約 出典 (確認 2026-11-11)
  • Keycloak (IdP): サーバーの対応機能として DPoP を掲載 出典 (確認 2026-11-11)
  • Duende IdentityServer (ライブラリ): 対応仕様の一覧に DPoP(RFC 9449)を掲載 出典 (確認 2026-11-11)

Mutual-TLS Client Authentication and Certificate-Bound Tokens

RFC として公開済みRFC 8705

TLS クライアント証明書でクライアントを認証し、アクセストークンをその証明書に結び付ける。

関係図
flowchart LR
  s_mtls["Mutual-TLS Client Authentication and Certificate-Bound Tokens"]
  s_oauth2["OAuth 2.0"]
  s_dpop["DPoP"]
  s_wimse_mtls["WIMSE Mutual TLS"]
  s_fapi2["FAPI 2.0 Security Profile"]
  style s_mtls stroke-width:3px
  s_mtls -->|拡張対象| s_oauth2
  s_dpop -.-|代替| s_mtls
  s_wimse_mtls -->|組み合わせ| s_mtls
  s_fapi2 -->|土台とする仕様| s_mtls

開く

公式に文書化された対応

  • Auth0 (IdP): mTLS のトークンバインディング(証明書に束縛されたトークン)。ディスカバリードキュメントで告知 出典 (確認 2026-11-11)
  • Spring Authorization Server (ライブラリ): RFC 8705 の tls_client_auth と self_signed_tls_client_auth によるクライアント認証 出典 (確認 2026-11-11)
  • Duende IdentityServer (ライブラリ): 対応仕様の一覧に RFC 8705 を掲載 出典 (確認 2026-11-11)
  • node-oidc-provider (ライブラリ): 実装済み仕様の一覧に RFC 8705 を掲載 出典 (確認 2026-11-11)

Attestation-Based Client Authentication

WG ラストコール・取りまとめdraft-ietf-oauth-attestation-based-client-auth-122026-10-18

秘密を保持できないアプリ向けに、クライアントインスタンスがバックエンドが発行するアテステーションと所持証明で認証する。

関係図
flowchart LR
  s_attestation_client_auth["Attestation-Based Client Authentication"]
  s_oauth2["OAuth 2.0"]
  s_spiffe_client_auth["OAuth SPIFFE Client Authentication"]
  style s_attestation_client_auth stroke-width:3px
  s_attestation_client_auth -->|拡張対象| s_oauth2
  s_spiffe_client_auth -->|プロファイル対象| s_attestation_client_auth

開く

公式に文書化された対応

出典付きの対応情報はまだ集めていない。普及していないという意味ではない。

OAuth SPIFFE Client Authentication

状態不明

RFC 7521・RFC 7523・attestation-based client authentication をプロファイルし、OAuth クライアントが client secret の代わりに SPIFFE の SVID (JWT・WIT・X.509) で認証できるようにする。

関係図
flowchart LR
  s_spiffe_client_auth["OAuth SPIFFE Client Authentication"]
  s_spiffe["SPIFFE"]
  s_jwt_bearer["JWT Bearer Grant and Client Authentication"]
  s_attestation_client_auth["Attestation-Based Client Authentication"]
  style s_spiffe_client_auth stroke-width:3px
  s_spiffe_client_auth -->|土台とする仕様| s_spiffe
  s_spiffe_client_auth -->|プロファイル対象| s_jwt_bearer
  s_spiffe_client_auth -->|プロファイル対象| s_attestation_client_auth

開く

公式に文書化された対応

出典付きの対応情報はまだ集めていない。普及していないという意味ではない。

ディスカバリーと登録

Authorization Server Metadata

RFC として公開済みRFC 8414

認可サーバーのエンドポイントと機能を列挙する well-known の JSON 文書。

関係図
flowchart LR
  s_as_metadata["Authorization Server Metadata"]
  s_oauth2["OAuth 2.0"]
  s_prm["Protected Resource Metadata"]
  s_rar_metadata_remediation["RAR Metadata and Error Remediation"]
  style s_as_metadata stroke-width:3px
  s_as_metadata -->|拡張対象| s_oauth2
  s_prm -->|組み合わせ| s_as_metadata
  s_rar_metadata_remediation -->|組み合わせ| s_as_metadata

開く

公式に文書化された対応

  • Model Context Protocol (仕様): MCP の認可仕様が RFC 8414 の Authorization Server Metadata(パス挿入あり)を使う 出典 (確認 2026-11-11)
  • Keycloak (IdP): Keycloak の MCP 対応表で RFC 8414 を対応済みとして掲載 出典 (確認 2026-11-11)

Protected Resource Metadata

RFC として公開済みRFC 9728

リソースサーバーが、信頼する認可サーバーと呼び出し方を示す well-known の文書。

関係図
flowchart LR
  s_prm["Protected Resource Metadata"]
  s_as_metadata["Authorization Server Metadata"]
  style s_prm stroke-width:3px
  s_prm -->|組み合わせ| s_as_metadata

開く

公式に文書化された対応

  • Model Context Protocol (仕様): MCP の認可仕様(2025-11-25)が、認可サーバーの発見に RFC 9728 の Protected Resource Metadata を使う 出典 (確認 2026-11-11)
  • Kong Gateway (OpenID Connect plugin) (製品): OIDC プラグインが、上流の API を RFC 9728 の保護リソースとして公開する 出典 (確認 2026-11-11)

Dynamic Client Registration

RFC として公開済みRFC 7591

クライアントが管理画面での手作業ではなく、API で認可サーバーに自身を登録する。

関係図
flowchart LR
  s_dcr["Dynamic Client Registration"]
  s_oauth2["OAuth 2.0"]
  s_cimd["Client ID Metadata Documents"]
  style s_dcr stroke-width:3px
  s_dcr -->|拡張対象| s_oauth2
  s_cimd -.-|代替| s_dcr

開く

公式に文書化された対応

出典付きの対応情報はまだ集めていない。普及していないという意味ではない。

Client ID Metadata Documents

WG ドラフトdraft-ietf-oauth-client-id-metadata-document-032026-11-02

client_id をクライアントのメタデータを返す HTTPS URL とし、サーバーごとの登録手順を不要にする。

関係図
flowchart LR
  s_cimd["Client ID Metadata Documents"]
  s_dcr["Dynamic Client Registration"]
  style s_cimd stroke-width:3px
  s_cimd -.-|代替| s_dcr

開く

公式に文書化された対応

  • Model Context Protocol (仕様): MCP の認可仕様が、認可サーバーが対応を示す場合に Client ID Metadata Documents を使うよう定める 出典 (確認 2026-11-11)
  • Ping Identity (PingFederate 13.1) (IdP): PingFederate 13.1 が OAuth クライアント向けに Client ID Metadata Documents に対応 出典 (確認 2026-11-11)
  • Keycloak (IdP)実験的: Keycloak の MCP 連携ガイドで、CIMD 対応を実験的機能として掲載 出典 (確認 2026-11-11)

ワークロードアイデンティティ

SPIFFE

IETF・OpenID 以外出典

CNCF のワークロードアイデンティティ標準。SPIFFE ID、X.509 と JWT の SVID、Workload API を定め、SPIRE が実装する。

関係図
flowchart LR
  s_spiffe["SPIFFE"]
  s_wimse_arch["WIMSE Architecture"]
  s_spiffe_client_auth["OAuth SPIFFE Client Authentication"]
  s_workload_identity_practices["Workload Identity Practices"]
  s_wimse_identifier["Workload Identifier"]
  style s_spiffe stroke-width:3px
  s_wimse_arch -->|組み合わせ| s_spiffe
  s_spiffe_client_auth -->|土台とする仕様| s_spiffe
  s_workload_identity_practices -->|組み合わせ| s_spiffe
  s_wimse_identifier -->|組み合わせ| s_spiffe

開く

公式に文書化された対応

  • Istio (製品): SPIRE 連携ガイドで、ワークロードが使う SPIFFE ID の形式を定めている 出典 (確認 2026-11-11)
  • Google Cloud (クラウド): マネージドなワークロードアイデンティティが SPIFFE に基づいている 出典 (確認 2026-11-11)
  • Anthropic (Claude API) (製品): ワークロードアイデンティティ連携で SPIFFE の JWT-SVID を受け付ける 出典 (確認 2026-11-11)
  • OpenAI API (製品): ワークロードアイデンティティ連携で SPIFFE の JWT-SVID を subject token として受け付ける 出典 (確認 2026-11-11)

WIMSE Architecture

WG ドラフトdraft-ietf-wimse-arch-082026-07-06

システムやクラウドをまたぐワークロードアイデンティティの IETF のアーキテクチャ。呼び出しの連鎖で受け渡すトークンも扱う。

関係図
flowchart LR
  s_wimse_arch["WIMSE Architecture"]
  s_spiffe["SPIFFE"]
  s_wimse_creds["WIMSE Workload Credentials"]
  s_aims["AI Identity Management System"]
  s_workload_identity_practices["Workload Identity Practices"]
  s_wimse_identifier["Workload Identifier"]
  style s_wimse_arch stroke-width:3px
  s_wimse_arch -->|組み合わせ| s_spiffe
  s_wimse_creds -->|土台とする仕様| s_wimse_arch
  s_aims -->|土台とする仕様| s_wimse_arch
  s_workload_identity_practices -->|組み合わせ| s_wimse_arch
  s_wimse_identifier -->|土台とする仕様| s_wimse_arch

開く

公式に文書化された対応

出典付きの対応情報はまだ集めていない。普及していないという意味ではない。

WIMSE Workload Credentials

WG ドラフトdraft-ietf-wimse-workload-creds-032026-10-30

ワークロード識別子に鍵を結び付ける Workload Identity Token(JWT)と Workload Identity Certificate(X.509)を定める。

関係図
flowchart LR
  s_wimse_creds["WIMSE Workload Credentials"]
  s_wimse_arch["WIMSE Architecture"]
  s_jwt["JSON Web Token"]
  s_wpt["WIMSE Workload Proof Token"]
  s_wimse_httpsig["WIMSE HTTP Message Signatures"]
  s_wimse_mtls["WIMSE Mutual TLS"]
  style s_wimse_creds stroke-width:3px
  s_wimse_creds -->|土台とする仕様| s_wimse_arch
  s_wimse_creds -->|土台とする仕様| s_jwt
  s_wpt -->|土台とする仕様| s_wimse_creds
  s_wimse_httpsig -->|土台とする仕様| s_wimse_creds
  s_wimse_mtls -->|土台とする仕様| s_wimse_creds

開くディープダイブ

公式に文書化された対応

  • SPIFFE (仕様): WIT-SVID 仕様が、すべての WIT-SVID を WIMSE の Workload Identity Token と定めている 出典 (確認 2026-11-11)
  • Solo.io (Istio 1.30.x ambient) (製品)アルファ: Solo の Istio ambient ディストリビューションが、WIMSE の Workload Identity Token にアルファ機能として対応 出典 (確認 2026-11-11)

WIMSE Workload Proof Token

WG ドラフトdraft-ietf-wimse-wpt-022026-08-27

リクエストごとの署名付き JWT で、Workload Identity Token の鍵の所持を、対象とメッセージに結び付けて証明する。

関係図
flowchart LR
  s_wpt["WIMSE Workload Proof Token"]
  s_wimse_creds["WIMSE Workload Credentials"]
  s_dpop["DPoP"]
  s_wimse_httpsig["WIMSE HTTP Message Signatures"]
  style s_wpt stroke-width:3px
  s_wpt -->|土台とする仕様| s_wimse_creds
  s_wpt -.-|代替| s_dpop
  s_wimse_httpsig -.-|代替| s_wpt

開く

公式に文書化された対応

出典付きの対応情報はまだ集めていない。普及していないという意味ではない。

WIMSE HTTP Message Signatures

IESG 審査中draft-ietf-wimse-http-signature-082026-10-28

Workload Identity Token の鍵で HTTP メッセージに署名(RFC 9421)し、ワークロード間を認証する。

関係図
flowchart LR
  s_wimse_httpsig["WIMSE HTTP Message Signatures"]
  s_wimse_creds["WIMSE Workload Credentials"]
  s_wpt["WIMSE Workload Proof Token"]
  style s_wimse_httpsig stroke-width:3px
  s_wimse_httpsig -->|土台とする仕様| s_wimse_creds
  s_wimse_httpsig -.-|代替| s_wpt

開く

公式に文書化された対応

出典付きの対応情報はまだ集めていない。普及していないという意味ではない。

WIMSE Mutual TLS

WG ドラフトdraft-ietf-wimse-mutual-tls-032026-10-30

Workload Identity Certificate を使い、トランスポート層でワークロード間を認証する。

関係図
flowchart LR
  s_wimse_mtls["WIMSE Mutual TLS"]
  s_wimse_creds["WIMSE Workload Credentials"]
  s_mtls["Mutual-TLS Client Authentication and Certificate-Bound Tokens"]
  style s_wimse_mtls stroke-width:3px
  s_wimse_mtls -->|土台とする仕様| s_wimse_creds
  s_wimse_mtls -->|組み合わせ| s_mtls

開く

公式に文書化された対応

出典付きの対応情報はまだ集めていない。普及していないという意味ではない。

AI Identity Management System (AIMS)

状態不明

WIMSE アーキテクチャと OAuth 2.0 系の上で AI エージェントのやり取りを認証・認可するためのベストプラクティス。どの既存標準を使い、どこにギャップがあるか。

関係図
flowchart LR
  s_aims["AI Identity Management System"]
  s_wimse_arch["WIMSE Architecture"]
  s_oauth2["OAuth 2.0"]
  style s_aims stroke-width:3px
  s_aims -->|土台とする仕様| s_wimse_arch
  s_aims -->|土台とする仕様| s_oauth2

開く

公式に文書化された対応

出典付きの対応情報はまだ集めていない。普及していないという意味ではない。

Workload Identity Practices

状態不明

コンテナオーケストレータやクラウド基盤上のワークロードが、長期秘密情報を自分で管理せずに外部認証用のクレデンシャルを得る現在の実践。

関係図
flowchart LR
  s_workload_identity_practices["Workload Identity Practices"]
  s_wimse_arch["WIMSE Architecture"]
  s_spiffe["SPIFFE"]
  style s_workload_identity_practices stroke-width:3px
  s_workload_identity_practices -->|組み合わせ| s_wimse_arch
  s_workload_identity_practices -->|組み合わせ| s_spiffe

開く

公式に文書化された対応

出典付きの対応情報はまだ集めていない。普及していないという意味ではない。

Workload Identifier

状態不明

トラストドメイン内でワークロードを一意に指す URI ベースの正規識別子。X.509 証明書や JWT 系トークンに入れて認証・認可・ポリシーに使う。

関係図
flowchart LR
  s_wimse_identifier["Workload Identifier"]
  s_wimse_arch["WIMSE Architecture"]
  s_spiffe["SPIFFE"]
  style s_wimse_identifier stroke-width:3px
  s_wimse_identifier -->|土台とする仕様| s_wimse_arch
  s_wimse_identifier -->|組み合わせ| s_spiffe

開く

公式に文書化された対応

出典付きの対応情報はまだ集めていない。普及していないという意味ではない。

検証可能なクレデンシャル

SD-JWT-based Verifiable Credentials (SD-JWT VC)

IESG 審査中draft-ietf-oauth-sd-jwt-vc-262026-11-06

SD-JWT の上に、型(vct)、発行者の鍵のディスカバリー、型メタデータを加えたクレデンシャル形式。デジタルアイデンティティウォレットで使われる。

関係図
flowchart LR
  s_sd_jwt_vc["SD-JWT-based Verifiable Credentials"]
  s_sd_jwt["Selective Disclosure for JWTs"]
  s_status_list["Token Status List"]
  s_openid4vci["OpenID for Verifiable Credential Issuance"]
  s_openid4vp["OpenID for Verifiable Presentations"]
  style s_sd_jwt_vc stroke-width:3px
  s_sd_jwt_vc -->|プロファイル対象| s_sd_jwt
  s_sd_jwt_vc -->|土台とする仕様| s_status_list
  s_openid4vci -->|組み合わせ| s_sd_jwt_vc
  s_openid4vp -->|組み合わせ| s_sd_jwt_vc

開く

公式に文書化された対応

出典付きの対応情報はまだ集めていない。普及していないという意味ではない。

Token Status List

承認済み、RFC Editor 待ちdraft-ietf-oauth-status-list-212026-11-03

発行者が公開する圧縮ビット列で、検証者はトークンやクレデンシャルが失効・停止されていないかを確認できる。

関係図
flowchart LR
  s_status_list["Token Status List"]
  s_jwt["JSON Web Token"]
  s_sd_jwt_vc["SD-JWT-based Verifiable Credentials"]
  style s_status_list stroke-width:3px
  s_status_list -->|土台とする仕様| s_jwt
  s_sd_jwt_vc -->|土台とする仕様| s_status_list

開く

公式に文書化された対応

出典付きの対応情報はまだ集めていない。普及していないという意味ではない。

OpenID for Verifiable Credential Issuance

FinalFinal1.0、2025 年 9 月承認

ウォレットに検証可能なクレデンシャルを発行するための、OAuth ベースの API。

関係図
flowchart LR
  s_openid4vci["OpenID for Verifiable Credential Issuance"]
  s_oauth2["OAuth 2.0"]
  s_sd_jwt_vc["SD-JWT-based Verifiable Credentials"]
  s_haip["OpenID4VC High Assurance Interoperability Profile"]
  style s_openid4vci stroke-width:3px
  s_openid4vci -->|土台とする仕様| s_oauth2
  s_openid4vci -->|組み合わせ| s_sd_jwt_vc
  s_haip -->|プロファイル対象| s_openid4vci

開く

公式に文書化された対応

  • EU Digital Identity Wallet reference implementation (政府): OpenID4VCI を実装したリファレンスライブラリ 出典 (確認 2026-11-11)

OpenID for Verifiable Presentations

FinalFinal1.0、2025 年 7 月承認

検証者がウォレットにクレデンシャルの提示を要求し、受け取るためのプロトコル。

関係図
flowchart LR
  s_openid4vp["OpenID for Verifiable Presentations"]
  s_oauth2["OAuth 2.0"]
  s_sd_jwt_vc["SD-JWT-based Verifiable Credentials"]
  s_haip["OpenID4VC High Assurance Interoperability Profile"]
  style s_openid4vp stroke-width:3px
  s_openid4vp -->|土台とする仕様| s_oauth2
  s_openid4vp -->|組み合わせ| s_sd_jwt_vc
  s_haip -->|プロファイル対象| s_openid4vp

開く

公式に文書化された対応

  • Google Wallet (ウォレット): ISO mdoc のデジタル ID を OpenID4VP で検証者に提示する 出典 (確認 2026-11-11)

OpenID4VC High Assurance Interoperability Profile

FinalFinal1.0、2025 年 12 月承認

政府のウォレットのような高保証のデプロイメント向けに、OpenID4VCI と OpenID4VP の選択肢を絞り込む。

関係図
flowchart LR
  s_haip["OpenID4VC High Assurance Interoperability Profile"]
  s_openid4vci["OpenID for Verifiable Credential Issuance"]
  s_openid4vp["OpenID for Verifiable Presentations"]
  style s_haip stroke-width:3px
  s_haip -->|プロファイル対象| s_openid4vci
  s_haip -->|プロファイル対象| s_openid4vp

開く

公式に文書化された対応

出典付きの対応情報はまだ集めていない。普及していないという意味ではない。

アイデンティティとプロファイル

OpenID Connect Core

FinalFinal1.0(エラッタセット 2 を反映)

OAuth 2.0 に認証を加える。誰がサインインしたかをクライアントに伝える ID Token と、UserInfo エンドポイントを定める。

関係図
flowchart LR
  s_oidc_core["OpenID Connect Core"]
  s_oauth2["OAuth 2.0"]
  s_jwt["JSON Web Token"]
  s_ciba["Client-Initiated Backchannel Authentication"]
  style s_oidc_core stroke-width:3px
  s_oidc_core -->|土台とする仕様| s_oauth2
  s_oidc_core -->|土台とする仕様| s_jwt
  s_ciba -->|拡張対象| s_oidc_core

解説

公式に文書化された対応

出典付きの対応情報はまだ集めていない。普及していないという意味ではない。

FAPI 2.0 Security Profile

FinalFinal2025 年 2 月承認

オープンバンキングのような API 向けの高セキュリティプロファイル。PAR、PKCE、送信者制約トークンを必須とする。

関係図
flowchart LR
  s_fapi2["FAPI 2.0 Security Profile"]
  s_par["Pushed Authorization Requests"]
  s_pkce["PKCE"]
  s_dpop["DPoP"]
  s_mtls["Mutual-TLS Client Authentication and Certificate-Bound Tokens"]
  style s_fapi2 stroke-width:3px
  s_fapi2 -->|土台とする仕様| s_par
  s_fapi2 -->|土台とする仕様| s_pkce
  s_fapi2 -->|土台とする仕様| s_dpop
  s_fapi2 -->|土台とする仕様| s_mtls

解説

公式に文書化された対応

  • ConnectID (Australia) (製品): エコシステムに FAPI 2.0 を採用(OpenID FAPI WG のページによる) 出典 (確認 2026-11-11)
  • Authlete (製品): FAPI 2.0 Security Profile に対応 出典 (確認 2026-11-11)

Client-Initiated Backchannel Authentication (CIBA)

FinalFinal2021 年 9 月承認

クライアントが開始し、ユーザーが別のデバイスで承認する認証。コールセンターや店頭などで使う。

関係図
flowchart LR
  s_ciba["Client-Initiated Backchannel Authentication"]
  s_oidc_core["OpenID Connect Core"]
  s_cross_device_bcp["Security of Cross-Device Flows"]
  style s_ciba stroke-width:3px
  s_ciba -->|拡張対象| s_oidc_core
  s_cross_device_bcp -->|組み合わせ| s_ciba

解説

公式に文書化された対応

出典付きの対応情報はまだ集めていない。普及していないという意味ではない。

認可 API

AuthZEN Authorization API

FinalFinalAuthorization API 1.0、2026 年 1 月承認

ポリシー実施点(PEP)とポリシー決定点(PDP)の間の標準的なリクエストとレスポンス。subject、action、resource と判定を扱う。

解説

公式に文書化された対応

  • OpenFGA (製品)実験的: AuthZEN 準拠の PDP として動作できる(実験的フラグ) 出典 (確認 2026-11-11)
  • Keycloak (IdP)実験的: AuthZEN Authorization API の PDP 対応(26.7.0、実験的) 出典 (確認 2026-11-11)

セキュリティイベント

Security Event Token (SET)

RFC として公開済みRFC 8417

セッションの失効や資格情報の変更のようなセキュリティイベントを表す JWT。

関係図
flowchart LR
  s_set["Security Event Token"]
  s_jwt["JSON Web Token"]
  s_ssf["Shared Signals Framework"]
  style s_set stroke-width:3px
  s_set -->|土台とする仕様| s_jwt
  s_ssf -->|土台とする仕様| s_set

開く

公式に文書化された対応

出典付きの対応情報はまだ集めていない。普及していないという意味ではない。

Shared Signals Framework (SSF)

FinalFinal1.0、2025 年 9 月承認

送信側と受信側が Security Event Token のストリームを設定し、プッシュまたはポーリングで配信する方法を定める。

関係図
flowchart LR
  s_ssf["Shared Signals Framework"]
  s_set["Security Event Token"]
  s_caep["CAEP"]
  s_risc["RISC"]
  style s_ssf stroke-width:3px
  s_ssf -->|土台とする仕様| s_set
  s_caep -->|プロファイル対象| s_ssf
  s_risc -->|プロファイル対象| s_ssf

開く

公式に文書化された対応

  • Google Workspace (製品)ベータ: CAEP のセッション失効を受け取る SSF 受信側(クローズドベータ) 出典 (確認 2026-11-11)

CAEP

FinalFinal1.0、2025 年 9 月承認

Continuous Access Evaluation Profile。セッションや資格情報の変化を SSF のイベントとして伝え、リライングパーティがアクセスを再評価できるようにする。

関係図
flowchart LR
  s_caep["CAEP"]
  s_ssf["Shared Signals Framework"]
  style s_caep stroke-width:3px
  s_caep -->|プロファイル対象| s_ssf

開く

公式に文書化された対応

  • Okta Identity Threat Protection (IdP): CAEP に準拠した Security Event Token を受け取る 出典 (確認 2026-11-11)
  • Jamf (製品): SSF の送信側として CAEP 準拠のシグナルを送る 出典 (確認 2026-11-11)

RISC

FinalFinal1.0、2025 年 9 月承認

Risk Incident Sharing and Coordination。資格情報の漏洩のようなアカウント侵害を SSF のイベントとして伝える。

関係図
flowchart LR
  s_risc["RISC"]
  s_ssf["Shared Signals Framework"]
  style s_risc stroke-width:3px
  s_risc -->|プロファイル対象| s_ssf

開く

公式に文書化された対応

  • Google Cross-Account Protection (IdP): Cross-Account Protection が RISC に基づいている 出典 (確認 2026-11-11)