RFC 7009 - OAuth 2.0 Token Revocation

概要

RFC 7009 は、OAuth 2.0 においてクライアントが認可サーバーに対してトークンの無効化を通知するプロトコル（Token Revocation）を定義している。2013年8月に IETF によって標準化された。

OAuth 2.0（RFC 6749）では、一度発行されたアクセストークンやリフレッシュトークンを失効させる標準的な手段が定義されていなかった。本仕様はその問題を解決し、クライアントが不要になったトークンを安全に失効させるためのエンドポイントと手順を定義する。

解決する課題

ログアウト時のトークン残留問題

OAuth 2.0 ではトークンの有効期限が切れるまで、そのトークンは有効であり続ける。ユーザーがアプリケーションからログアウトした後も、発行済みのアクセストークンやリフレッシュトークンが有効な状態で残り続けるため、以下の問題が生じる：

• ログアウト後もトークンを使えばリソースへのアクセスが可能な状態が継続する
• 盗まれたトークンをすぐに無効化する手段がない
• 認可サーバーが不要なトークンに関連するデータをクリーンアップできない

リフレッシュトークンの廃棄

リフレッシュトークンはアクセストークンを繰り返し取得できる長命なトークンであり、不要になった際に確実に廃棄する手段が必要である。Token Revocation により、クライアントはリフレッシュトークンを安全に廃棄できる。

主要概念・用語

用語	説明
Revocation Endpoint	認可サーバーが提供するトークン失効用エンドポイント
Token Type Hint	失効対象のトークン種別を示すヒント（access_token, refresh_token）。検索効率化に使用
Cascading Revocation	リフレッシュトークンを失効させた際に、関連するアクセストークンも連鎖して失効させる動作

プロトコルフロー

フローの説明

1. ユーザーがアプリケーションからログアウトを要求する
2. クライアントは認可サーバーの Revocation Endpoint に HTTP POST でトークンを送信する
3. 認可サーバーはトークンを検索し、有効であれば無効化する
4. 認可サーバーは成功・失敗を問わず HTTP 200 を返す（例外あり）
5. クライアントはローカルのトークン情報を破棄し、ログアウト処理を完了する

エンドポイント仕様

リクエスト

Revocation Endpoint への HTTP POST リクエスト。

• メソッド: POST
• Content-Type: application/x-www-form-urlencoded
• 認証: 必須（機密クライアントはクライアント認証が必要）
• プロトコル: HTTPS 必須

リクエストパラメータ:

パラメータ	必須	説明
token	必須	失効させるトークン値
token_type_hint	任意	トークン種別のヒント（access_token, refresh_token 等）

リクエスト例（リフレッシュトークンの失効）:

POST /revoke HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW

token=45ghiukldjahdnfkdhb83&token_type_hint=refresh_token

レスポンス

成功時（HTTP 200）:

HTTP/1.1 200 OK

レスポンスボディは空またはコンテンツを持たない。仕様では、トークンが存在しない場合・無効な場合でも 200 を返すと定義されている。これにより、攻撃者がトークンの存在確認に失効エンドポイントを悪用することを防ぐ。

エラー時:

ステータスコード	エラー	説明
400	unsupported_token_type	指定されたトークン種別の失効をサポートしない
400	invalid_request	リクエストが不正
401	invalid_client	クライアント認証失敗
503	-(エラーレスポンス任意)	サーバー一時利用不可。トークンは失効していない

エラーレスポンスは RFC 6749 Section 5.2 に準拠した JSON 形式で返す。

token_type_hint の処理

token_type_hint パラメータは、認可サーバーがトークンを効率的に検索するためのヒントとして機能する。

認可サーバーは token_type_hint を必ず尊重する義務はなく、あくまで検索の最適化ヒントとして扱う。

リフレッシュトークン失効の連鎖動作

RFC 7009 では、リフレッシュトークンを失効させた場合の動作についても規定している。

認可サーバーは、失効するリフレッシュトークンに関連するアクセストークンも無効化すべきである（SHOULD）。

この「連鎖失効（Cascading Revocation）」により、リフレッシュトークン一本を失効させれば関連するアクセストークンも無効化できる。一方、アクセストークンを失効させた場合、認可サーバーは関連するリフレッシュトークンを失効させてもよい（MAY）が、必須ではない。リフレッシュトークンを確実に廃棄したい場合は、明示的にリフレッシュトークンに対して失効リクエストを送ることが推奨される。

セキュリティに関する考慮事項

クライアント認証の必須化

機密クライアント（サーバーサイドアプリケーション等）は、Revocation Endpoint へのリクエストにクライアント認証情報を含める必要がある。これにより、他のクライアントが発行したトークンを第三者が不正に失効させることを防ぐ。

HTTPS の強制

Revocation Endpoint は TLS による保護が必須である。トークン値が平文で送信されるため、通信経路の暗号化が不可欠である。

DoS 攻撃への対策

token_type_hint に無効な値を指定することで、認可サーバーに不必要なデータベース検索を強制するサービス妨害攻撃が考えられる。認可サーバーはレート制限などの対策を実施すべきである。

無効トークンへの一貫した応答

存在しないトークンや既に無効なトークンに対しても HTTP 200 を返すことで、トークンの存在確認に失効エンドポイントが利用されることを防ぐ。この設計は Token Introspection（RFC 7662）の active: false 応答と同様の思想に基づく。

自己包含型トークンの注意点

JWT のような自己包含型トークン（Self-Contained Token）の場合、リソースサーバーが認可サーバーに問い合わせず署名検証だけでアクセスを許可するケースがある。この場合、失効エンドポイントでトークンを失効させても、アクセストークンの有効期限が切れるまでリソースサーバーでは有効扱いされる可能性がある。短い有効期限の設定や Token Introspection の組み合わせが推奨される。

関連仕様

仕様	関係
RFC 6749	OAuth 2.0 の基盤仕様。アクセストークン・リフレッシュトークンの概念を定義
RFC 6750	Bearer トークンの使用方法
RFC 7662	Token Introspection。失効済みトークンは active: false を返す
RFC 8414	Authorization Server Metadata。Revocation Endpoint の URL を公開する際に使用
RFC 7519	JWT。自己包含型トークンの場合、失効の即時反映に注意が必要

参考文献

• RFC 7009 原文