仕様書

意味

[3] 失効要求revocation requestは、 クライアントが自身の保持するアクセストークンや更新トークンを無効化することを認可鯖に求めるものです。 >>1

[41] 認可サーバーは、 指定されたトークンを無効にすると共に、 関係する他のトークンやセッションデータ等の関係するデータを消去できます >>1。

[6] 実装は、 更新トークンの失効に対応しなければなりません >>1。

[7] 実装は、 アクセストークンの失効に対応するべきです >>1。

[5] トークンを失効させることで、 ログアウト等の後末端利用者が気づかないままトークンが残ってしまうことを防げますし、 乱用されることも防げます。 >>1

[43] 認可鯖が末端利用者に対して認可承諾の一覧を提示している場合には、 そこからも消去されるでしょう。 >>1 使わなくなったクライアントが一覧に残り続けるよりは良さそうです。

[24] クライアントは、 revokeエンドポイントが 200 を返した後そのトークンを使おうと試みてはなりません >>1。

[26] なお、トークンはこの仕組み以外でも無効になることがあります。 クライアントは、いつでもトークンが無効にされる可能性を考慮しておかなければなりません >>1。例えば資源所有者が revoke するかもしれませんし、 認可鯖が自身の判断で無効化するかもしれません。

クライアントの要求

[9] クライアントは、 POST 要求を使います >>1。 JSONP を使う場合には GET 要求でも構いません >>1。

[13] クライアントが revokeエンドポイントの URL を得る方法は、 OAuth 仕様の範囲外です。鯖のドキュメントから調べても構いませんし、 自動的な発見の仕組みを使っても構いません。いずれにせよ信頼できる情報源に拠る必要があります。 >>1

[14] revokeエンドポイントの URL は、 HTTPS でなければなりません。 認可鯖は TLS を使わなければなりません。 クライアントは HTTPS の URL であることを検証verifyしなければなりません。 クライアントは偽のrevokeエンドポイントを検出するため、証明書の検証などにより認証しなければなりません。 >>1

[15] サーバーは、失効エンドポイントが素のHTTP でも利用できるなら、 そちらでの失効にも対応するべきです。 しかしこれを失効エンドポイントの URL として出版してはなりません。 >>1

[11] revokeエンドポイントの URL は、 application/x-www-form-urlencoded 形式の query を含んでいても構いません >>1, >>10。

[12] URL に引数を追加する時は、元の query を残さなければなりません >>1, >>10。

[17] クライアントは POST 要求の payload body または JSONP GET 要求の URL query に application/x-www-form-urlencoded 形式で次の引数を指定します >>1。

[20] クライアントは、クライアント認証 (または認証できない場合には client_id 引数) も含めます >>1。

認可鯖の処理

[32] 認可鯖は、 利用者エージェントベースのアプリケーションで使われるかもしれない場合には、 CORS に対応して構いません >>1。

[21] 認可鯖は、まず (機密のクライアントなら) クライアントcredentialsを検証validateします >>1。

[22] 認可鯖は、次にトークンが当該クライアントに発行されたものか検証verifyします。 失敗した場合は、エラーを返して終わります。 >>1

[37] RFC には明記されていませんが、引数の重複や欠落などがあれば、 エラーを返して終わるべきと思われます。

[23] 認可鯖は、その後トークンを非妥当化します。非妥当化は直ちに行われ、 以後トークンは使えなくなります。実際には伝播遅延があるかもしれませんが、 できるだけ短期間で反映されるようにするべきです。 >>1

[29] token_type_hint の指定は、あまり意味がありません。

[25] 認可鯖は、 revoke に関する方針次第で、 関連するトークンや元になった認可承諾をも revoke して構いません。 更新トークンの revoke においては、 認可鯖がアクセストークンの revoke にも対応しているなら、同じ認可承諾に基づくすべてのアクセストークンをも revoke するべきです。 アクセストークンの revoke においては、 対応する更新トークンも revoke して構いません。 >>1

[27] 認可鯖は、 revoke に成功したい場合や、 非妥当なトークンが指定されていた場合は、 200 応答を返します >>1。

[88] 認可鯖は、誤りの場合には、 400 応答で次の引数を JSON (application/json) payload body の JSONオブジェクトの名前と値 (文字列なら JSON文字列、 数値なら JSON数値) に含めます >>1, >>30。

[40] 認可鯖は、 DoS攻撃に注意しなければなりません >>1。

[28] クライアントは、 200 応答の payload body を無視します >>1。

[31] クライアントは、 503 応答を受信したらトークンはまだ有効と判断しなければならず、 適当な間を置いて再試行して構いません。鯖は Retry-After: で利用できないと思われる期間を示すことができます。 >>1

[34] クライアントは、 JSONP の場合不正な revokeエンドポイントが不正なコードを注入する危険性があることに注意するべきです >>1。

歴史

[49] OAuth 1.0 本体には revoke API はありませんでした。

[53] OAuth Session Extension は revoke API を規定していました >>52。

[47] Google は OAuth 1.0 アクセストークンについて、 AuthSub の revokeエンドポイントを使って revoke できる >>48 としていました。

[51] Twitter は OAuth 2.0 向けに独自仕様の revokeエンドポイントを実装しています >>50。

メモ

[36] RFC 7009 は OAuth 関連仕様の中でも特に品質が低いようです。 他の RFC を参照している箇所は章番号だけでどの規定が引用されているのか自明ではなかったりしますし、 事実の文による状況の説明ばかりで助動詞が含まれる規定の文は少なく、 前世紀レベルです。 JSONP に関する部分に至っては規定がほとんどなく例示に頼っています。

[38] RFC は未だに JSONP を考慮しているようですが、出版された2013年の時点ではぎりぎりまだ必要があったかもしれません。 現在では最早何の意味もなく、危険なだけなので CORS を使うべきでしょう。

[54] OAuth2 · reddit/reddit Wiki (2015-03-05 16:30:32 +09:00 版) https://github.com/reddit/reddit/wiki/OAuth2#user-content-manually-revoking-a-token