Global Token Revocation

Web Authorization Protocol                                    A. Parecki
Internet-Draft                                                      Okta
Intended status: Standards Track                        25 February 2026
Expires: 29 August 2026

draft-parecki-oauth-global-token-revocation-06

Abstract

Global Token Revocation により、セキュリティインシデント管理ツールや外部の Identity Provider などの主体は、Authorization Server に対して要求を送信し、あるユーザーの既存トークンをすべて失効させ、新しいトークンを発行する前にそのユーザーへ再認証を求めるよう指示できる。

About This Document

この注記は、RFC として公開する前に削除される予定である。

このドラフトの最新改訂版は、draft-parecki-oauth-global-token-revocation/draft-parecki-oauth-global-token-revocation.html で参照できる。この文書のステータス情報は、datatracker の当該ドラフトページで参照できる。

この文書に関する議論は、Web Authorization Protocol Working Group のメーリングリストで行われており、アーカイブも公開されている。購読先も用意されている。

このドラフトのソースコードおよび issue tracker は、GitHub リポジトリで参照できる。

Status of This Memo

この Internet-Draft は、BCP 78 および BCP 79 の規定に完全に準拠して提出されている。

Internet-Draft は Internet Engineering Task Force (IETF) の作業文書である。他のグループも作業文書を Internet-Draft として配布することがある。現在の Internet-Draft の一覧は datatracker で参照できる。

Internet-Draft は最大 6 か月間有効な草案文書であり、いつでも更新、差し替え、または廃止される可能性がある。Internet-Draft を参照資料として用いたり、「work in progress」以外の形で引用したりするのは適切ではない。

この Internet-Draft は 2026 年 8 月 29 日に失効する。

Copyright Notice

Copyright (c) 2026 IETF Trust および文書著者として記載された者。All rights reserved.

この文書は、この文書の公開日に有効である BCP 78 および IETF Trust の IETF Documents に関する Legal Provisions の適用対象である。これらの文書には、この文書に関する権利および制限が記載されているため、注意深く確認すること。本文書から抽出された Code Components には、Trust Legal Provisions の Section 4.e に記載された Revised BSD License の文面を含めなければならず、また Revised BSD License に記載されたとおり、無保証で提供される。

Table of Contents

• Global Token Revocation
  • Abstract
  • About This Document
  • Status of This Memo
  • Copyright Notice
  • Table of Contents
  • 1. Introduction
  • 2. Conventions and Definitions
    • 2.1. Terminology
    • 2.2. Roles
  • 3. Token Revocation
    • 3.1. Revocation Endpoint
    • 3.2. Revocation Request
    • 3.3. Revocation Expectations
    • 3.4. Revocation Response
      • 3.4.1. Successful Response
      • 3.4.2. Error Response
    • 3.5. Authentication Using Private Key JWT
  • 4. Revocation of Access Tokens
  • 5. Revocation Completion Notification
  • 6. Authorization Server Metadata
  • 7. Security Considerations
    • 7.1. Authentication of Revocation Request
    • 7.2. Enumeration of User Accounts
    • 7.3. Malicious Authorization Server
  • 8. IANA Considerations
    • 8.1. OAuth Authorization Server Metadata
  • 9. References
    • 9.1. Normative References
    • 9.2. Informative References
  • Appendix A. Relationship to Related Specifications
    • A.1. RFC7009: Token Revocation
    • A.2. OpenID Connect Front-Channel Logout
    • A.3. OpenID Connect Back-Channel Logout
    • A.4. Shared Signals Framework
  • Appendix B. Document History
  • Acknowledgments
  • Author's Address

1. Introduction

OAuth Authorization Server は、ユーザーがクライアントを認可したことに応じてトークンを発行する。OAuth Authorization Server の外部にある主体は、特定のユーザーに属するトークンをすべて失効させ、そのユーザーが再認証するまでサーバーが新しいトークンを発行しないよう、Authorization Server に指示したい場合がある。

たとえば、セキュリティインシデント管理ツールがあるユーザーアカウントの異常な挙動を検出することがある。また、ユーザーが企業の Identity Provider を通じてログインしていた場合には、セキュリティインシデントの発生時や従業員の退職時に、その Identity Provider が当該ユーザーのトークンをすべて失効させたい場合がある。

この仕様は、外部主体からの要求を受け取り、特定ユーザーに関連付けられたすべてのトークンを失効させることができる、Authorization Server 上の新しい API endpoint を記述する。

2. Conventions and Definitions

この文書中のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここで示したようにすべて大文字で記載されている場合に限り、BCP 14 [RFC2119] [RFC8174] に記載された意味で解釈される。

2.1. Terminology

この仕様では、[RFC6749] で定義された「Access Token」、「Authorization Code」、「Authorization Endpoint」、「Authorization Server」(AS)、「Client」、「Client Authentication」、「Client Identifier」、「Client Secret」、「End-User」、「Grant Type」、「Protected Resource」、「Redirection URI」、「Refresh Token」、「Resource Owner」、「Resource Server」(RS)、「Token Endpoint」、および [OpenID] で定義された「OpenID Provider」(OP) と「ID Token」という用語を用いる。

この仕様では、「Identity Provider」(IdP) という用語を、End-User 認証に用いられる Authorization Server または OpenID Provider を指すために用いる。

TODO: RFC6749 への参照を OAuth 2.1 に置き換える。

2.2. Roles

典型的な OAuth の導入形態では、ユーザーがログインしてクライアントを認可すると、OAuth client は authorization server からトークンを取得する。多くの場合、ユーザーが authorization server で認証する方法は、外部の identity provider を経由するものである。

たとえば、モバイルのチャットアプリケーションは OAuth Client であり、チャットメッセージを保存する backend server からトークンを取得する。このモバイルチャットの backend は、OAuth における「Resource Server」と「Authorization Server」の役割を担う。

場合によっては、ユーザーは外部の（たとえば企業の）Identity Provider を使って Authorization Server にログインする。その場合、ユーザーがチャットアプリケーションにログインすると、backend server は新たな認可または認証フローにおいて、Identity Provider に対する OAuth client（または OpenID や SAML における「relying party」）の役割を担うことがある。

3. Token Revocation

失効要求は、subject identifier を含む HTTP POST リクエストを Global Token Revocation endpoint に送るものであり、識別された subject に対するすべてのトークンを失効させる処理を開始する。

3.1. Revocation Endpoint

Global Token Revocation endpoint は authorization server 上の URL であり、application/json 形式を用いて HTTP リクエストメッセージ本文にパラメータを入れた HTTP POST リクエストを受け付ける。Global Token Revocation endpoint の URL は https スキームを MUST とする。

authorization server が OAuth Server Metadata ([RFC8414]) をサポートしている場合、authorization server は Section 6 で定義される global_token_revocation_endpoint パラメータを用いて、自身の authorization server metadata 文書に Global Token Revocation endpoint の URL を含めるべきである。

authorization server は、代替手段として、この endpoint をそれを利用するツールへ直接登録してもよい。

3.2. Revocation Request

この要求は、application/json の本文を持つ POST リクエストであり、その本文には sub_id という 1 つのプロパティが含まれる。この値は、"Subject Identifiers for Security Event Tokens" [RFC9493] で定義された Security Event Token Subject Identifier である。

実際には、これは sub_id の値が format というプロパティと、format の値に応じて少なくとも 1 つ以上の追加プロパティを持つ JSON オブジェクトであることを意味する。

この要求は、認証も MUST である。この仕様では、Section 3.5 で述べる private key JWT の利用を RECOMMENDED とする。OAuth 2.0 Bearer Token [RFC6750] など、他の認証方式も適切な場合には利用してよい。

次の例は、[RFC9493] の Section 3.2.2 で定義された Email Identifier Format を用いて、メールアドレスで識別されるユーザーのすべてのトークンの失効を要求している。

POST /global-token-revocation
Host: example.com
Content-Type: application/json
Authorization: Bearer f5641763544a7b24b08e4f74045

{
  "sub_id": {
    "format": "email",
    "email": "user@example.com"
  }
}

失効要求を行うシステムが、authorization server におけるユーザー識別子を把握している場合、その要求は [RFC9493] の Section 3.2.4 で定義された "Opaque Identifier" 形式を使ってユーザー識別子を指定できる。

POST /global-token-revocation
Host: example.com
Content-Type: application/json
Authorization: Bearer f5641763544a7b24b08e4f74045

{
  "sub_id": {
    "format": "opaque",
    "id": "e193177dfdc52e3dd03f78c"
  }
}

authorization server が IdP におけるユーザー識別子を知っていることが期待される場合、その要求は [RFC9493] の Section 3.2.3 で定義された "Issuer and Subject Identifier" 形式を使うことができる。

POST /global-token-revocation
Host: example.com
Content-Type: application/json
Authorization: Bearer f5641763544a7b24b08e4f74045

{
  "sub_id": {
    "format": "iss_sub",
    "iss": "https://issuer.example.com/",
    "sub": "af19c476f1dc4470fa3d0d9a25"
  }
}

3.3. Revocation Expectations

失効要求を受信し、その要求を認可し、識別されたユーザーを検証したあと、Authorization Server は次を満たさなければならない。

• アクティブな Refresh Token をすべて失効させること。
• 技術的に Access Token を無効化できない場合があり得ることは認識されているものの、すべての Access Token を無効化するべきである（後述の Section 4 を参照）。
• 新たな Access Token または Refresh Token を発行する前に、ユーザーへ再認証を必ず求めること。

3.4. Revocation Response

この仕様では、成功条件およびエラー条件を HTTP レスポンスコードによって示し、レスポンス本文の形式や内容は定義しない。

3.4.1. Successful Response

要求が成功し、要求対象となったトークン集合の失効が開始されたことを示すために、サーバーは HTTP 204 レスポンスを返す。

3.4.2. Error Response

さまざまなエラー条件を示すために、次の HTTP レスポンスコードを利用できる。

• 400 Bad Request: 要求の形式が不正であった。たとえば、認識できない、またはサポートされていない種類の subject identifier が指定された場合である。
• 401 Unauthorized: 提供された認証情報が無効であった。
• 403 Forbidden: 認可が不十分であった。たとえば scope が不足している場合である。
• 404 User Not Found: subject identifier で示されたユーザーが見つからなかった。
• 422 Unable to Process Request: ユーザーをログアウトさせることができなかった。

3.5. Authentication Using Private Key JWT

呼び出し元が Identity Provider である場合、RECOMMENDED な認証方法は、[RFC7523] で定義された private_key_jwt client authentication method の構造に従って、署名済み JWT を HTTP Authorization ヘッダー内の Bearer token として送る方法である。

この JWT には、次の claims を MUST とする。

iss: Identity Provider の issuer identifier。OpenID Connect を使用する場合、これは IdP が ID Token において issuer 値として使う値と同じでなければならない。

sub: IdP 内における呼び出し元の識別子。OpenID Connect client では通常 client_id であり、SAML 連携では通常 appInstanceId である。

aud: Global Token Revocation endpoint の URL。これは、クエリ文字列パラメータやフラグメント識別子を含まない、正確な endpoint URL でなければならない。

jti: この JWT の一意な識別子。authorization server は、リプレイ攻撃を防ぐため、トークンの有効期間内にすでに見たことのある jti 値を使う要求を拒否するべきである。

iat: JWT が作成された時刻を表す Unix timestamp。

exp: JWT の有効期限。JWT は短命であるべきであり、5 分間の有効期間が RECOMMENDED である。

この JWT は、非対称アルゴリズム（たとえば RS256 や ES256）を用いて署名しなければならない。署名鍵は、IdP が ID Token や SAML Assertion に署名する際に使う秘密鍵と同じであるべきである。そうすることで authorization server は、IdP がすでに公開している公開鍵（たとえば OpenID Connect discovery document [RFC8414] から参照される IdP の JWKS endpoint 経由）を用いて署名を検証できる。

JWT は Bearer token として送られる。

POST /global-token-revocation
Host: as.example.com
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6IjEifQ...

{
  "sub_id": {
    "format": "email",
    "email": "user@example.com"
  }
}

JWT の payload は次のとおりである。

{
  "iss": "https://idp.example.com/",
  "sub": "client_id_of_integration",
  "aud": "https://as.example.com/global-token-revocation",
  "jti": "a3f8d2c1-4b7e-4f0a-9c2d-1e5b8a7f3d6c",
  "iat": 1741200000,
  "exp": 1741200300
}

authorization server は、JWT 署名を検証し、claims が正しい形式であることを確認し、さらに aud claim が失効 endpoint の URL と一致することを確認しなければならない。また、exp が過ぎていないこと、および jti が以前に使われていないことも検証しなければならない。

4. Revocation of Access Tokens

OAuth 2.0 では、Access Token の形式に関して柔軟な導入が可能である。Access Token は自己完結型（たとえば [RFC9068]）でありうる。この場合、protected resource へのアクセスを要求する client に対して認可判断を行うために、resource server はそれらのトークンを発行した authorization server と追加のやり取りを行う必要がない。これに対してシステム設計によっては、authorization server に保存された認可データを参照するハンドル型の Access Token（一般に「reference token」と呼ばれる）を用いることもある。

これらだけが唯一の選択肢ではないが、失効に関する含意を示す例にはなる。後者の reference token の場合、authorization server は保存領域から削除することで Access Token を失効できる。前者の場合、トークンを保存していなければ、追加の対策を講じない限りトークンを失効できないことがある。そのような対策の 1 つとして、[I-D.ietf-oauth-status-list] を用いて、分散可能で、かつ容易に圧縮可能なトークン失効状態の一覧を維持する方法がある。

このため、この仕様では Access Token の失効は任意である。実装者にとって負担が大きすぎる可能性があるためである。呼び出し元に成功コードを返すために、Access Token の失効は必須ではない。

5. Revocation Completion Notification

Section 3.4 で定義した 204 レスポンスは、authorization server が失効要求を受理し、失効処理が始まったことを示す。これは、レスポンスが返された時点で全トークンの失効が完了していることまでは保証しない。多くの導入形態では、特にトークン保存が分散している場合や自己完結型の Access Token を用いる場合、完全な失効は HTTP レスポンス送信後に非同期で完了することがある。

呼び出し元が失効の完全な完了確認を必要とする利用例、たとえばセキュリティインシデント管理ツールが、処理を進める前にすべてのアクティブセッションが終了したことを確認しなければならない場合には、通知の仕組みが必要になる。

Shared Signals Framework [SSF] をサポートする authorization server は、完了通知を呼び出し元へ届けるためにそれを使ってよい。具体的には、識別された subject に関するすべてのトークンが失効され、再認証要件が適用された時点で、authorization server はあらかじめ設定された呼び出し元向けの SSF ストリームへ CAEP の "Session Revoked" イベント [CAEP] を送信してよい。

完了通知のために SSF を使うことは完全に OPTIONAL である。完了確認を必要としない呼び出し元は、失効が開始されたことの指標として 204 レスポンスのみに依存してよい。この仕様で定義される Global Token Revocation endpoint は、いずれかの当事者が SSF をサポートしているかどうかとは独立に動作する。

authorization server が SSF ベースの完了通知をサポートする場合、その機能と、帯域外で配信するイベント型を文書化するべきである。この目的のための authorization server metadata パラメータは、ここでは定義されていないためである。

この場合の SSF ストリームの向きは、Appendix A.4 で説明する典型的な identity-provider-to-authorization-server の向きとは逆であることに注意されたい。ここでは authorization server が SSF transmitter として振る舞い、失効要求を開始した呼び出し元（たとえば identity provider やセキュリティツール）へイベントを返送する。

6. Authorization Server Metadata

Global Token Revocation に関するサーバーの機能と方針を示すために、次の authorization server metadata パラメータ [RFC8414] を導入する。

global_token_revocation_endpoint: authorization server の global token revocation endpoint の URL。

global_token_revocation_endpoint_auth_methods_supported: OPTIONAL。この endpoint がサポートする client authentication methods の一覧を含む JSON 配列。有効な client authentication method の値は、IANA の "OAuth Token Endpoint Authentication Methods" レジストリ [IANA.oauth-parameters] に登録されているもの、または IANA の "OAuth Access Token Types" レジストリ [IANA.oauth-parameters] に登録されているものとする。（これらの値は [RFC8414] の Section 7.2 により、現在も将来も互いに異なる値のままである。）省略された場合、サポートされる認証方式の集合は他の手段で判断しなければならない。

7. Security Considerations

7.1. Authentication of Revocation Request

失効要求は、Section 3.2 で述べたとおり認証されなければならない。RECOMMENDED な方法は、Section 3.5 で述べた private key JWT の仕組みであり、これにより資格情報は aud claim を通じて特定の endpoint URL に結び付けられ、その有効期間も制限されるため、資格情報の悪用やリプレイのリスクを低減できる。

失効要求は最終的に広範囲な影響を持つ（ユーザーはすべてのデバイスからログアウトされることが想定される）ため、これは新たな Denial of Service 攻撃ベクトルとなる。そのため、この要求に用いられる認証は、呼び出し元に不要な権限を与えないよう、できるだけ限定された scope にすべきである。

たとえば OAuth Bearer Token を用いる場合、そのトークンは失効要求だけを実行できる単一の scope で発行されるべきであり、他の種類のトークンにその scope を含めるべきではない。

authorization server がマルチテナントであり、異なる Identity Provider を通じて複数顧客をサポートしている場合、各 Identity Provider は、その同一テナント内のユーザーについてのみトークン失効を実行できるよう認可された、専用の scope を持つ資格情報を使うべきである。Section 3.5 で述べた private key JWT 認証を用いる場合、iss claim が自然にこの役割を果たす。各 IdP は自身の秘密鍵で署名するためである。

7.2. Enumeration of User Accounts

通常、ユーザー識別子を受け取り、そのユーザーが存在するかどうかに応じて異なるステータスを返す API は、ユーザーアカウントの列挙を可能にする攻撃ベクトルを提供してしまう。この仕様は "User Not Found" レスポンスを要求しているため、本来であればその類型に入る。しかし、この仕様で定義される endpoint への要求は認証必須であるため、これは公開 endpoint とは見なされない。

要求を行うツールが侵害され、攻撃者がそのツールからの要求をなりすませる場合（ツールに要求を送らせるか、資格情報を抽出することで）、攻撃者はユーザーアカウントを列挙できるようになる。しかし、この要求は単にユーザーアカウントの存在を試すだけではなく、成功した場合にはそのユーザーに紐づくトークンを実際に失効させるので、多数のユーザーのトークンが短時間で失効すれば、監査ログ上で容易に可視化される可能性が高い。

このように強力な API endpoint を提供することへの懸念をいくらか緩和するため、特定の client が失効要求できるユーザーは制限されるべきであり、また要求の認証は、Section 7.1 で述べたとおり、その client に認可されたユーザーだけに失効可能な対象を絞り込むために用いられるべきである。

たとえば、異なるテナントに属するユーザーごとに異なる署名鍵を使うマルチテナントの identity provider は、その同じ署名鍵を失効要求の認証にも使うことができる。たとえば [RFC7523] に述べられているように、client authentication に用いる JWT を作成する方法である。これにより、要求を受けた authorization server は、その identity provider 上の特定テナントに関連付けられたユーザーについてのみ失効要求を受け入れられるようになる。

7.3. Malicious Authorization Server

複数の downstream application との連携をサポートする identity provider の立場から見ると、downstream application が悪意を持って Global Token Revocation endpoint を設定し、ユーザー識別子や失効要求の認証情報を収集する機会がある。

Section 7.1 で述べたのと同様に、各連携は個別の認証資格情報を使うべきであり、各資格情報の scope も可能な限り狭くするべきである。そうすることで、悪意あるサーバーがこの認証情報を受け取ったとしても、それを他の場所で再利用して他システムに対して何らかの操作を行うことができないようにできる。

8. IANA Considerations

8.1. OAuth Authorization Server Metadata

IANA は、[RFC8414] によって確立された [IANA.oauth-parameters] の IANA "OAuth Authorization Server Metadata" レジストリに、次の値を（TBD として）登録した。

Metadata Name: global_token_revocation_endpoint

Metadata Description: authorization server の global token revocation endpoint の URL。

Change Controller: IESG

Specification Document: Section X of [[this specification]]

Metadata Name: global_token_revocation_endpoint_auth_methods_supported

Metadata Description: OPTIONAL。この endpoint がサポートする client authentication methods の一覧を示す。

Change Controller: IESG

Specification Document: Section X of [[this specification]]

9. References

9.1. Normative References

[IANA.oauth-parameters]
IANA, "OAuth Parameters".

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.

[RFC6749]
Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012.

[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017.

[RFC8414]
Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018.

[RFC9493]
Backman, A., Ed., Scurtescu, M., and P. Jain, "Subject Identifiers for Security Event Tokens", RFC 9493, DOI 10.17487/RFC9493, December 2023.

9.2. Informative References

[CAEP]
Tulshibagwale, A. and T. Cappalli, "Continuous Access Evaluation Profile 1.0", 2025.

[I-D.ietf-oauth-status-list]
Looker, T., Bastian, P., and C. Bormann, "Token Status List (TSL)", Work in Progress, Internet-Draft, draft-ietf-oauth-status-list-18, 18 February 2026.

[OpenID]
Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, "OpenID Connect Core 1.0 incorporating errata set 2", December 2023.

[RFC6750]
Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, DOI 10.17487/RFC6750, October 2012.

[RFC7009]
Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth 2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009, August 2013.

[RFC7523]
Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, May 2015.

[RFC9068]
Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens", RFC 9068, DOI 10.17487/RFC9068, October 2021.

[SSF]
Tulshibagwale, A., Cappalli, T., Scurtescu, M., Backman, A., Bradley, J., and S. Miel, "OpenID Shared Signals and Events Framework Specification 1.0", 2025.

Appendix A. Relationship to Related Specifications

A.1. RFC7009: Token Revocation

OAuth 2.0 Token Revocation [RFC7009] は、OAuth client が、以前に取得した Access Token または Refresh Token がもはや不要になったことを authorization server に通知するために使える endpoint を定義している。

この要求は OAuth client によって行われる。Token Revocation 要求への入力は、そのトークン自体と、client 自身の認証資格情報である。

これは、トークンを入力として受け取らず、代わりにユーザー識別子を入力として受け取る Global Token Revocation endpoint とは異なる。これは OAuth client によって呼び出されるのではなく、セキュリティ監視ツールや、ユーザーが authorization server で認証する際に利用した identity provider などの外部主体によって呼び出される。

A.2. OpenID Connect Front-Channel Logout

OpenID Connect Front-Channel Logout は、OpenID Provider が user agent のリダイレクトによって Relying Party からユーザーをログアウトさせる仕組みを提供する。

ログアウト要求の向き自体はこのドラフトが記述するものと同じだが、これは user agent のリダイレクトに依存するため、ユーザーが Web ブラウザ上でアプリケーションと能動的にやり取りしている場合にしか適用できない。

Global Token Revocation 要求は、ユーザーがそのアプリケーションを現在使っているかどうかに関係なく機能し、Web 以外のアプリケーションにも適用できる。

A.3. OpenID Connect Back-Channel Logout

OpenID Connect Back-Channel Logout は、OpenID Provider が、ログアウト対象ユーザーのユーザー識別子を含む back-channel の POST 要求を送ることによって、Relying Party からユーザーをログアウトさせる仕組みを提供する。

これは、既存のログアウト仕様の中では Global Token Revocation に最も近い。しかし、Global Token Revocation が可能にする利用例には不十分となる、いくつかの重要な違いがなお存在する。

OpenID Connect Back-Channel Logout は、Relying Party に対し、そのユーザーに関するセッション状態を消去することを求めているが、Access Token については何も述べていない。また、offline_access scope 付きで発行された Refresh Token は "SHOULD NOT be revoked" とも述べている。これは、Refresh Token が offline_access scope で発行されたかどうかに関係なく、そのユーザーのすべての Refresh Token の失効を要求する Global Token Revocation とは、具体的に異なる結果である。

OpenID Connect Back-Channel Logout は、Relying Party が OpenID Connect を実装していることも前提としている。そのため、Relying Party が実際には SAML など他の仕様を使って identity provider と連携している場合には、実装上の課題が生じる。

さらに、OpenID Connect Back-Channel Logout は、ID Token の sub claim を使ってユーザーを識別する。そのため、identity provider と authorization server の間で知られている可能性のあるメールアドレスや他の識別子でユーザーを識別する仕組みがなく、適用範囲が制限される。これに対し Global Token Revocation は、複数のユーザー識別方法を提供する Security Event Token Subject Identifiers ([RFC9493]) に依拠している。

Global Token Revocation は、ユーザーが認証に使うプロトコルに依存せず機能するため、OpenID Connect 連携でも SAML 連携でも同様に有効である。

A.4. Shared Signals Framework

OpenID Foundation の Shared Signals Framework には、セッションおよびトークンの失効に関連する機能を持つ仕様が 2 つある。

Continuous Access Evaluation Profile (CAEP) は、協調する当事者間で送信できる複数のイベント型を定義している。特に "Session Revoked" イベントは、ユーザーの identity provider 上のセッションが失効したときに、identity provider から authorization server へ送ることができる。この仕組みと Global Token Revocation 要求との主な違いは、CAEP イベントが受信者によって処理される場合もあれば処理されない場合もある signal であるのに対し、Global Token Revocation 要求は期待される結果の一覧が定義された command である、という点にある。

Risk Incident Sharing and Coordination (RISC) は、CAEP と比べてやや強い意味づけを持つイベントを定義している。特に "Account Disabled" イベントは意味が明確であり、受信者も指定されたアカウントを無効化すべきことを強く示唆する。しかし RISC には、ユーザーが自分のアカウントに関するイベント送信を拒否できる仕組みもあるため、Global Token Revocation 要求と同じ水準の保証は提供しない。

最後に、CAEP や RISC イベントの受信側を構成するのは、Global Token Revocation 要求の受信側を構成する場合に比べて複雑である。そのため、受信側が失効ユースケースだけをサポートしたいのであれば、このドラフトで記述されている単一の POST 要求をサポートするほうがはるかに簡単である。

SSF と Global Token Revocation は相補的な目的を果たすが、組み合わせて使うこともできる。Section 5 で述べたとおり、authorization server は失効が完全に完了した時点で、完了通知を呼び出し元へ返すために SSF を使ってよい。この場合、通常の signal の向きが反転し、AS が SSF transmitter として振る舞う。

Appendix B. Document History

（最終仕様から削除予定）

-06

• SSF を使って失効確認を行う方法の説明を追加した。
• Authorization Server への要求を認証するために private_key_jwt を使う方法の説明を追加した。

-05

• 編集上の明確化を行った。
• subject identifier format への具体的な参照を追加した。

-04

• 明確さのための修正を行った。
• subject を sub_id に改名した散文上の説明を修正した。

-03

• RFC9493 で定義された JWT claim 名との整合性のため、プロパティ名を subject から sub_id に変更した。
• draft-ietf-oauth-status-list への参照を追加した。
• 失効要求の認証および悪意ある authorization server に関する追加のセキュリティ考慮事項を追加した。

-02

• ユーザーアカウント列挙に関するセキュリティ考慮事項を追加した。
• この仕様と関連ログアウト仕様との差異を説明する付録を追加した。

-01

• 失効時に期待される動作を明確化した。
• endpoint の定義を改善した。
• Authorization Server Metadata における endpoint 定義の節を追加した。

-00

• Initial Draft

Acknowledgments

著者らは、この仕様への貢献とレビューを行った次の方々に感謝する: Apoorva Deshpande, George Fletcher, Karl McGuinness, Mike Jones.

Author's Address

Aaron Parecki
Okta
Email: aaron@parecki.com
URI: aaronparecki.com