マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

目次

概要

  • OAuth 2.0 のトークン(refresh_token, access_token)を無効化するメカニズムでコア仕様を補足
  • 取消し要求は、当該トークンと、該当する場合、同じauthorization grantの他のトークンを無効化する。
  • この動作により、
    • Resource Ownerが認識していない、
    • 特定のClientに対して有効な、
    • authorization grantがまだ存在する状況が回避される。

目的

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

ケース

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

シーケンス

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

仕様

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を無効化する。

Response

  • 成功
    • HTTP status code 200
    • レスポンス本文の内容は無し。
  • 失敗
    • ケース
      • クライアント認証に失敗
      • トークン検証に失敗
    • レスポンス
      • HTTP status code 503
      • OAuth 2.0 のError Responseをベースに追加エラー コード

        unsupported_token_type:提示されたトークン・タイプの取り消しをサポートしない。

実装

注意

  • access_tokenは自己完結型であるため、
    • トークン・ハンドル化するか、
    • jtiクレームを追加するか、

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

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

考察

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

参考

OAuth 2.0 Token Introspection


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


トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2018-10-09 (火) 22:15:19 (70d)