メインコンテンツまでスキップ

2. Token Revocation (トークン無効化)

2. Token Revocation (トークン無効化)​

実装は、リフレッシュトークンの無効化をサポートしなければならず (MUST)、アクセストークンの無効化をサポートすべきです (SHOULD)（実装上の注意を参照）。

クライアントは、トークン無効化エンドポイント URL に HTTP POST リクエストを行うことで、特定のトークンの無効化をリクエストします。この URL は [RFC6749] セクション 3.1 で与えられるルールに準拠しなければなりません (MUST)。クライアントは、URL が HTTPS URL であることを確認しなければなりません (MUST)。

無効化エンドポイントの場所を取得する手段は、本仕様の範囲外です。たとえば、クライアント開発者はサーバーのドキュメントを参照したり、自動検出を使用したりする場合があります。このエンドポイントはセキュリティ資格情報を扱っているため、エンドポイントの場所は信頼できるソースから取得する必要があります。

トークン無効化エンドポイントへのリクエストは、HTTP リクエスト内での平文の資格情報の送信をもたらすため、トークン無効化エンドポイントの URL は HTTPS URL でなければなりません (MUST)。認可サーバーは、[RFC6749] セクション 1.6 に準拠したバージョンの Transport Layer Security (TLS) [RFC5246] を使用しなければなりません (MUST)。実装は、セキュリティ要件を満たす追加のトランスポート層セキュリティメカニズムもサポートしてもかまいません (MAY)。

トークン無効化エンドポイントのホストに HTTP 経由でも到達できる場合、サーバーは対応する HTTP URI でも無効化サービスを提供すべきですが (SHOULD)、この URI をトークン無効化エンドポイントとして公開してはなりません (MUST NOT)。これにより、誤って HTTP 経由で送信されたトークンが無効化されることが保証されます。

2.1. Revocation Request (無効化リクエスト)​

クライアントは、HTTP リクエストエンティティボディで "application/x-www-form-urlencoded" 形式を使用して次のパラメータを含めることでリクエストを構築します。

token : REQUIRED (必須)。クライアントが無効化したいトークン。

token_type_hint : OPTIONAL (任意)。無効化のために送信されたトークンのタイプに関するヒント。クライアントは、認可サーバーがトークン検索を最適化するのを助けるために、このパラメータを渡してもかまいません (MAY)。サーバーが指定されたヒントを使用してトークンを見つけられない場合、サポートされているすべてのトークンタイプに検索を拡張しなければなりません (MUST)。認可サーバーは、特にトークンタイプを自動的に検出できる場合、このパラメータを無視してもかまいません (MAY)。本仕様は、このような値を 2 つ定義しています。

  • access_token: [RFC6749] セクション 1.4 で定義されているアクセストークン

  • refresh_token: [RFC6749] セクション 1.5 で定義されているリフレッシュトークン

本仕様の特定の実装、プロファイル、および拡張は、セクション 4.1.2 で定義されているレジストリを使用して、このパラメータの他の値を定義してもかまいません (MAY)。

クライアントは、[RFC6749] のセクション 2.3 で説明されているように、認証資格情報も含めます。

たとえば、クライアントは次のリクエストでリフレッシュトークンの無効化をリクエストする場合があります。

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

認可サーバーは、最初にクライアント資格情報を検証し（機密クライアントの場合）、次にトークンが無効化リクエストを行っているクライアントに発行されたかどうかを確認します。この検証が失敗した場合、リクエストは拒否され、以下に説明するように認可サーバーによってエラーがクライアントに通知されます。

次のステップで、認可サーバーはトークンを無効にします。無効化は直ちに行われ、トークンは無効化後に再び使用することはできません。実際には、たとえば、一部のサーバーが無効化について知っているが他のサーバーは知らないといった伝播遅延がある可能性があります。実装はその時間を最小限に抑えるべきであり、クライアントはサーバーから HTTP 200 レスポンスを受け取った後にトークンを使用しようとしてはなりません。

認可サーバーの無効化ポリシーによっては、特定のトークンの無効化が、関連するトークンおよび基礎となる認可グラントの無効化を引き起こす場合があります。特定のトークンがリフレッシュトークンであり、認可サーバーがアクセストークンの無効化をサポートしている場合、認可サーバーは同じ認可グラントに基づくすべてのアクセストークンも無効にすべきです (SHOULD)（実装上の注意を参照）。リクエストに渡されたトークンがアクセストークンである場合、サーバーは対応するリフレッシュトークンも同様に無効にしてもかまいません (MAY)。

注：[RFC6749] に準拠したクライアントは、予期しないトークン無効化をいつでも処理できるように準備しなければなりません。本文書で指定された無効化メカニズムとは独立して、リソース所有者は認可グラントを無効にする場合や、認可サーバーがセキュリティの脅威を軽減するためにトークンを無効にする場合があります。したがって、トークンの連鎖的な無効化に関して異なるサーバーポリシーを持つことは、相互運用性の問題を引き起こすべきではありません。

2.2. Revocation Response (無効化レスポンス)​

トークンが正常に無効化された場合、またはクライアントが無効なトークンを送信した場合、認可サーバーは HTTP ステータスコード 200 で応答します。

注：クライアントはそのようなエラーを合理的な方法で処理できないため、無効なトークンはエラーレスポンスを引き起こしません。さらに、無効化リクエストの目的、つまり特定のトークンを無効にすることは、すでに達成されています。

必要なすべての情報はレスポンスコードで伝えられるため、レスポンスボディの内容はクライアントによって無視されます。

無効なトークンタイプヒント値は認可サーバーによって無視され、無効化レスポンスには影響しません。

2.2.1. Error Response (エラーレスポンス)​

エラー表示は [RFC6749] のセクション 5.2 の定義に準拠しています。トークン無効化エンドポイントには、次の追加のエラーコードが定義されています。

unsupported_token_type : 認可サーバーは、提示されたトークンタイプの無効化をサポートしていません。つまり、クライアントはこの機能をサポートしていないサーバー上でアクセストークンを無効にしようとしました。

サーバーが HTTP ステータスコード 503 で応答する場合、クライアントはトークンがまだ存在すると想定しなければならず、合理的な遅延の後に再試行してもかまいません。サーバーは、サービスがリクエスト元のクライアントに対して利用できなくなると予想される期間を示すために、レスポンスに "Retry-After" ヘッダーを含めてもかまいません。

2.3. Cross-Origin Support (クロスオリジンサポート)​

無効化エンドポイントが user-agent (ユーザーエージェント) ベースのアプリケーションとの組み合わせでの使用を目的としている場合、Cross-Origin Resource Sharing (クロスオリジンリソース共有、CORS) [W3C.WD-cors-20120403] をサポートしてもかまいません (MAY)。

さらに、レガシーユーザーエージェントとの相互運用性のために、追加のパラメータを持つ GET リクエストを許可することで、JSONP (Remote JSON - JSONP) [jsonp] も提供してもかまいません (MAY)。

callback : OPTIONAL (任意)。JavaScript 関数の完全修飾名。

たとえば、クライアントは次のリクエストでアクセストークンの無効化をリクエストする場合があります（改行は表示のみを目的としています）。

https://example.com/revoke?token=agabcdefddddafdd&
callback=package.myCallback

成功時のレスポンス：

package.myCallback();

エラーレスポンス：

package.myCallback({"error":"unsupported_token_type"});

クライアントは、JSONP に依存する場合、悪意のある無効化エンドポイントがクライアントに悪意のあるコードを挿入しようとする可能性があることに注意すべきです。

に最終更新