#目次
- はじめに -RFC7009について
- MUSTとSHOULDなど整理
- tokenについて
- OAuth保護について
1. はじめに -RFC7009について
RFC7009 OAuth 2.0 Token Revocation
英語版：https://tools.ietf.org/html/rfc7009
日本語訳：https://openid-foundation-japan.github.io/rfc7009.ja.html
このRFCには簡単に言うと、
- アクセストークン、リフレッシュトークンの有効期間内でそのトークンが不要になった場合に、トークンを失効できる機能を提供しましょう。
- HTTPリクエストエンティティボディにパラメーターtokenで失効したいトークンを入れましょう。
といったことが記載されています
以前、トークン失効の機能をAPIとして実装しようとしていてをパッと読んで「簡単そうじゃん！」と思っていました。
いざ作成しようとした時にRFCをじっくり読み返すと、RFCの意図していることが見えてきてその注意点について記載いたします。詳細については上記リンクからRFCを読んでください。
2. ポイントとなるMUSTとSHOULDなど整理
一番大事なところだけ整理してまとめてみました。
| 内容 | Requirement Levels |
|---|---|
| リフレッシュトークンを失効させる機能 | MUST |
| アクセストークンを失効させる機能 | SHOULD |
| token | MUST |
| token_type_hint | OPTIONAL |
3. tokenについて
tokenは、HTTPリクエストエンティティボディに必須で入るパラメーターです。
値は失効させたいアクセストークン値 or リフレッシュトークン値が入ります。
######①リフレッシュトークン値が入っている場合
同じ認可元のアクセストークン全てを失効させるべきである。(SHOULD)
※アクセストークンを失効させる機能を実装させない場合、RFCの6.Security Considerationsにあるようにセキュリティーに気をつけなければなりません。
######②アクセストークン値が入っている場合
同じ認可元のすべてのリフレッシュトークンを失効させてもよい。（MAY）
######③リフレッシュトークンでもアクセストークンでも当てはまらない値が入っている or 無効なリフレッシュトークン、アクセストークン が入っている場合
失効させるトークンはないが、レスポンスコードは200を返却する。
これは、クライアント側が失効させたいトークンがすでに使えない状態になっているので問題ないと言うことと理解しました。なのでエラーレスポンスではなく200で返却です。
4. OAuth保護について
当然のようにセキュリティー的に、この機能もOAuth保護（Authorization: Bearer <アクセストークン>）をするだろう。そうしなければ、他のAPIでOAuth保護で使っているトークンとか晒されることになるのでは？と思っていました。
結論からいうと
「OAuth保護しない」が正しいです。
RFCのサンプルでもBasic認証をしているようです。
なぜか考えたのですが、以下の考えにたどり着きました。
OAuth保護ありでトークンの失効をする場合、アクセストークンの有効期限が切れていてリフレッシュトークンを失効させるが実施できない。
アクセストークンのは基本的に寿命短としているため、リフレッシュトークン(寿命長め)を元にトークン失効することが考えられるがOAuth保護ありではトークン失効をする前に認証で弾かれてしまう。
トークン失効をするために再度アクセストークンの再発行することはクライアントにとって合理的ではない。
その代わりのセキュリティー保護としては、Basic認証やクライアントID、クライアントシークレットで守るしかないと思います。