「[[マイクロソフト系技術情報 Wiki>http://techinfoofmicrosofttech.osscons.jp/]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。

-[[戻る>OAuth 2.0 拡張]]

* 目次 [#he299d61]
#contents

*概要 [#df2301a2]
-[[OAuth]] 2.0 のトークン(refresh_token, access_token)を無効化するメカニズムでコア仕様を補足

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

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

**目的 [#j1c45799]
-トークンの悪用を防ぐ。
-より良いUXを促進する。

**ケース [#xb3ee361]
-Resource Ownerががサインアウトした場合。
-Resource OwnerがIDを変更した場合。
-Clientをアンインストールした場合。

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

*仕様 [#l5d8df77]
**Revocation Endpoint [#q677cd0f]
-Authorization Endpointの規則と同様
--HTTP要求の平文認証情報の送信
--SSL/TLS(サーバ証明)の利用

-自動検出など、URLを取得する手段は、この仕様の範囲外
-[[CORS>クロス ドメイン接続]]をサポートしても良い。

***Request [#j56d5a2f]
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 [#jf0c255c]
-クライアント認証

-トークン検証

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

***Response [#e846c97b]
-成功
--HTTP status code 200
--レスポンス本文の内容は無し。

-失敗
--ケース
---クライアント認証に失敗
---トークン検証に失敗
--レスポンス
---HTTP status code 503
---[[OAuth]] 2.0 のError Responseをベースに追加エラー コード
>unsupported_token_type:提示されたトークン・タイプの取り消しをサポートしない。

*実装 [#h9f5fd55]
**注意 [#dcdb485c]
-access_tokenは自己完結型であるため、
--トークン・ハンドル化するか、
--jtiクレームを追加するか、

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

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

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

*参考 [#p0f111ab]
-RFC 7009 - OAuth 2.0 Token Revocation~
https://tools.ietf.org/html/rfc7009
-OAuth 2.0 Token Revocation~
http://openid-foundation-japan.github.io/rfc7009.ja.html

-OAuth 2.0のToken無効化に関する仕様について調べた - r-weblife~
http://d.hatena.ne.jp/ritou/20110323/1300888935
-OAuthのToken Revocationっていう仕様がLast Callに - r-weblife~
http://d.hatena.ne.jp/ritou/20130418/1366237852

**[[OAuth 2.0 Token Introspection]] [#ndf0701b]

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

トップ   編集 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS