![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
「[[マイクロソフト系技術情報 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]]
