Skip to content

MS_TokenRevocation

Jump to bottom
nishi_74322014 edited this page Aug 12, 2026 · 1 revision

OAuth 2.0 Token Revocation

概要

  • OAuth 2.0 のトークン（refresh_token, access_token）を
    無効化するメカニズムでコア仕様を補足

  • 取消し要求は、当該トークンと、該当する場合、
    同じ authorization grant の他のトークンを無効化する。

  • この動作により、

    • Resource Owner が認識していない、
    • 特定の Client に対して有効な、
    • authorization grant がまだ存在する状況が回避される。

目的

  • トークンの悪用を防ぐ。
  • より良い UX を促進する。

ケース

  • Resource Owner がサインアウトした場合。
  • Resource Owner が ID を変更した場合。
  • Client をアンインストールした場合。

シーケンス

  1. Client は Authorization Server の Revocation Endpoint URL へ
    トークンが必要でなくなったことを通知する。
  2. Authorization Server は、そのトークンに関連するデータ、
    authorization grant をクリーンアップする。

移行メモ（誤字）: 元ページの「Resource Owner がが」は重複である。

仕様

Revocation Endpoint

  • Authorization Endpoint の規則と同様
    • HTTP 要求の平文認証情報の送信
    • SSL/TLS（サーバ証明）の利用
  • 自動検出など、URL を取得する手段は、この仕様の範囲外
  • CORSをサポートしても良い。

Request

HTTP POST 要求（application/x-www-form-urlencoded）を使用して、
以下のパラメタを Revocation Endpoint に送信する。

  • 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=45ghiukldjahdnhzdauz&token_type_hint=refresh_token

Process

  • クライアント認証
  • トークン検証
  • トークン無効化
    • 直ちに無効化され、トークン再使用不可（使用禁止）
    • 実際には、伝播遅延が存在する可能性がある。
    • 関連するトークンおよびその基礎となる認可付与の無効化
      • access_token：合わせて、refresh_token も無効化できる（MAY）。
      • refresh_token：同じ authorization grant に基づく
        全 access_token を無効化する。

補足（この非対称性が重要）: refresh_token を失効させると
紐づく全 access_token も失効するが、逆は任意（MAY）である。

失効させるもの 影響
refresh_token その grant の全 access_token も失効（SHOULD）
access_token refresh_token も失効させてよい（MAY）

「ログアウトしたら全部切る」という要件なら、
refresh_token を失効させるのが正しい。
access_token だけ失効させても、
Client が refresh_token で再取得できてしまう。

Response

  • 成功
    • HTTP status code 200
    • レスポンス本文の内容は無し。
  • 失敗
    • ケース: クライアント認証に失敗 / トークン検証に失敗
    • レスポンス: HTTP status code 503
      追加エラー コード unsupported_token_type
      （提示されたトークン・タイプの取り消しをサポートしない）

移行メモ（正誤）: 元ページは失敗時を「HTTP status code 503」と
しているが、RFC 7009 の定義は次のとおりである。

ケース ステータス
クライアント認証に失敗 401 Unauthorized
unsupported_token_type 400 Bad Request
サーバ側の一時的な事情 503 Service Unavailable（Retry-After 付き）

503 は「一時的に処理できない」場合の話であり、
認証失敗やトークン種別の非対応とは別である。

補足（無効なトークンでも 200）: Introspectionと
同様、存在しない・既に失効しているトークンを渡されても 200 を返す
のが仕様である（RFC 7009）。
「そのトークンは存在しない」と教えてしまうと、
トークンの有効性を判定する手段を与えることになるためである。

実装

注意

  • access_token は自己完結型であるため、

    • トークン・ハンドル化するか、
    • jti クレームを追加するか、

    など、何らかの ID を付与する必要がある。

  • トークン・ハンドル化や jti クレームを追加した場合、
    Authorization Server, Resource Server 間の
    バックエンドに、いくつかの（非標準化）相互作用が必要になる。

考察

  • トークン・ハンドルや jti などの ID の導入で、
    無効化された ID を管理する実装が無難。
  • 危ない場合は、攻撃に関わる Client や Resource Owner の削除を行うで良い気もする。
  • 必要に応じて、Resource Server も Client や Resource Owner の
    チェックを行うと良いかと思う。

補足（自己完結型トークンの失効という難問）: この節が指摘するとおり、
JWT形式のアクセス トークンは原理的に「失効できない」。
署名が正しく期限内なら、Resource Server は有効と判定してしまう。

実務での対処は次の 3 つに整理できる。

方針 内容 コスト
有効期限を短くする 5〜15 分。refresh_token で更新 最も簡単。実務の第一選択
失効リスト（denylist） 失効した jti を共有ストア（Redis 等）に置き、RS が毎回照会 自己完結型の利点を失う
Introspectionに切り替える ハンドル型にする 性能を犠牲にする

「即時失効が本当に必要か」を要件として確認し、
必要でないなら有効期限を短くするだけで済ませるのが
最も見通しがよい。

参考

Tags: 移行, IT国際標準, 認証基盤, クレームベース認証, OAuth

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally