こんばんは、ritouです。
久々なので、短めな仕様を調べました。
draft-lodderstedt-oauth-revocation-02 - Token Revocation
Refresh/Access Tokenの無効化
OAuthのToken無効化と言えば、Twitterで怪しげなClientの暴挙を止めるためにAccess TokenをRevokeするという場面が思い浮かぶかと思います。
Token無効化は、セキュリティや使いやすさととても深く関連しています。TwitterのOAuthさんは私たちにいろいろなことを教えてくれますね。
今回の仕様では、ClientからAuthZ ServerにToken無効化のリクエストを送る方法が定義されています。
Clientは、AuthZ Serverのドキュメント等に書いてあるToken Revocation Endpointに次のようなリクエストを送ります。
- HTTP POST(MUST)
- TLS 1.2(MUST)
- "application/x-www-form-urlencoded"
パラメータは以下のとおりです。
- token : Revoke対象のToken 種類(Access/Refresh)は実装に依存され、AuthZ Serverはそれをしれっと特定する
- Client Credential : client_id/client_secretなど
サンプル：
POST /revoke HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencodedtoken=45ghiukldjahdnhzdauz&
client_id=s6BhdRkqt3&
client_secret=gX1fBat3bV
簡単ですね。
AuthZ Serverの処理
- Client Credentialの検証。Tokenを受け取ったClientのみがRevokeできるとかの仕様はAuthZ Serverの実装に依存
- Tokenの無効化。まぁすぐに反映されるかなどは実装依存
Refresh Tokenが指定された場合、関連する全てのAccess Tokenを無効する。
レスポンスは、次のようになります。
- 200 : 成功
- 401 : Client認証失敗
- 403 : Token無効化の権限なし
- 400 : その他多くのエラー
その他のエラーとして、次の２つが定義されています。
- unsupported_token_type : 指定されたTokenの種類がサポートされていなかった場合
- invalid_token : 既に無効なTokenの場合
以上です。
全体的にシンプルですね。
ただ、これだけならRevocation専用ではなく、Token Endpointと共存できるような仕様にしておいても良いのかなって思います。なんて考えましたが、今のOAuth 2.0の仕様ではToken EndpointにAccess Tokenを取得するリクエストが集約されているので、別でいいですね。
この仕様が実装されると、Client側からも明確に"もらったTokenは完全に廃棄しましたよ"と言えるので、安全面でも素晴らしいですね。
(訂正)この仕様が実装されると、Client側が不要になったTokenを自ら廃棄できるようになるので、今までよりも少しだけ安全な世の中になるかもしれませんね。
TwitterのOAuthは信用できないので、是非mixiさんあたりには実装していただきたいものです。
ではまた！
