[2] 失効エンドポイントは、 アクセストークンや更新トークンを失効させる (revoke する) ためのエンドポイントです。
[3] 失効要求は、 クライアントが自身の保持するアクセストークンや更新トークンを無効化することを認可鯖に求めるものです。 >>1
[41] 認可サーバーは、 指定されたトークンを無効にすると共に、 関係する他のトークンやセッションデータ等の関係するデータを消去できます >>1。
[6] 実装は、 更新トークンの失効に対応しなければなりません >>1。
[7] 実装は、 アクセストークンの失効に対応するべきです >>1。
[4] OAuth はしばしば Webアプリケーションのログインの仕組みとして使われます。 そのようなWebアプリケーション (クライアント) は、 末端利用者 (資源所有者) がログアウトしたりアンインストールしたりした時に、 トークンを失効させることができます。 >>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 であることを検証しなければなりません。 クライアントは偽の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。application/x-www-form-urlencoded)
[20] クライアントは、クライアント認証 (または認証できない場合には
client_id 引数) も含めます >>1。
[32] 認可鯖は、 利用者エージェントベースのアプリケーションで使われるかもしれない場合には、 CORS に対応して構いません >>1。
[21] 認可鯖は、まず (機密のクライアントなら) クライアントcredentialsを検証します >>1。
[22] 認可鯖は、次にトークンが当該クライアントに発行されたものか検証します。 失敗した場合は、エラーを返して終わります。 >>1
[37] RFC には明記されていませんが、引数の重複や欠落などがあれば、 エラーを返して終わるべきと思われます。
[23] 認可鯖は、その後トークンを非妥当化します。非妥当化は直ちに行われ、 以後トークンは使えなくなります。実際には伝播遅延があるかもしれませんが、 できるだけ短期間で反映されるようにするべきです。 >>1
[29] token_type_hint の指定は、あまり意味がありません。
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 ( 版) https://github.com/reddit/reddit/wiki/OAuth2#user-content-manually-revoking-a-token
In order to revoke a token (i.e. remove the bridge between your application and Viadeo) use https://secure.viadeo.com/oauth-provider/revoke_access_token2 with access token as parameter
https://secure.viadeo.com/oauth-provider/revoke_access_token2?
client_id=<YOUR_API_KEY>&
client_secret=<YOUR_API_SECRET>&
redirect_uri=http://www.example.com/oauth_redirect&
access_token=<ACCESS_TOKEN_TO_REVOKE>
In response, you will get the following json response:
{"token_revoked"}
Revoking an authorization will block associated tokens from making further requests.
DELETE /oauth/authorizations/{authorization-id}
/disable_access_tokenPythonJavaRubyPHP
DESCRIPTION
Disables the access token used to authenticate the call. This method works for OAuth 1 and OAuth 2 tokens.
URL STRUCTURE
https://api.dropbox.com/1/disable_access_token
METHOD
POST
RETURNS
An empty JSON dictionary, which indicates success.
Revoke GET or POST /api/v1/oauth/revoke.json
refresh_token
string The refresh token returned in the previous code.
client_id
string The clientId obtained during application registration.
client_secret
string The client secret obtained during application registration.
grant_type
string This field must contain a value of revoke_token.
Deauthorization
Allows an application to revoke its access to an athlete’s data. This will invalidate all access tokens associated with the ‘athlete,application’ pair used to create the token. The application will be removed from the Athlete Settings page on Strava. All requests made using invalidated tokens will receive a 401 Unauthorized response.
Parameters
access_token: string required
Responds with the access token submitted with the request.
In order to revoke a token (i.e. remove the bridge between your application and Viadeo) use https://secure.viadeo.com/oauth-provider/revoke_access_token2 with access token as parameter
https://secure.viadeo.com/oauth-provider/revoke_access_token2?
client_id=<YOUR_API_KEY>&
client_secret=<YOUR_API_SECRET>&
redirect_uri=http://www.example.com/oauth_redirect&
access_token=<ACCESS_TOKEN_TO_REVOKE>
In response, you will get the following json response:
{"token_revoked"}
Applications can revoke access to an athlete’s data. This will invalidate all refresh tokens and access tokens that the application has for the athlete, and the application will be removed from the athlete’s apps settings page. All requests made using invalidated tokens will receive a 401 Unauthorized response.
The endpoint is POST https://www.strava.com/oauth/deauthorize.
access_token required string, in query Responds with the refresh tokens that were revoked.