背景

あるサービスがOAuth2.0に対応しているAPIを公開していまして、
そのAPIを利用したアプリケーションを個人的に開発しております。

利用しているAPIはリフレッシュトークンフローを採用しており

有効期限が短いaccess_token
有効期限が長いrefresh_token

が発行され、access_tokenの有効期限が切れた場合に、ユーザーの再認証なしに、
refresh_tokenで新しいaccess_tokenが取得できるようになっています。
(refresh_token自体も新しく発行される)

質問

ここで質問なのですが、

有効期限が切れてないaccess_token(①)があり、
それをrefresh_token(②)を使用して再発行を行った場合、
新しいaccess_token(③)と新しいrefresh_token(④)が取得できると思います。

感覚的には再発行を行なった時点で①と②は無効になる気がしてましたが、
どうやら、①でサービスにアクセスできユーザーの情報を取得することも可能であり、②でさらに新しいaccess_tokenを発行できるようです。

この挙動はOAuth2.0の仕様なのでしょうか。
それとも、サービス固有なものなのでしょうか。

ご教示いただけると幸いです。
よろしくお願い致します。

行動規範の内容に同意します

回答1件

ベストアンサー

OAuth 2.0 の仕様としては RFC 6749 に標準化されており、 refresh token による access token の更新処理については 6. Refreshing an Access Token の章に記載があります。

ここを見る限り、 有効期限が切れていない access token (1) が引き続き有効なのは OAuth 2.0 の仕様 であり、 更新に使用された refresh token (2) が再利用できるのはサービスの実装に依存 するものと考えられます。

有効期限が切れていない access token (1) について

こちらは単純に、上記の 6 章に敢えて「access token の更新が行われた場合、過去に発行した access token を無効化する」ような 処理の要求が一切存在しない ため、OAuth 2.0 の仕様と考えられます。

1.4. Access Token にて "Tokens represent specific scopes and durations of access" とされていることもあり、 一度発行された access token は特定の scope と期限に対応するものであり、何らかの理由で無効化されない限りは期限中引き続き有効 と考えるべきでしょう。

尚、 access token が無効化される理由としては、それを取得するのに使用された authorization code が 2 回以上使われた形跡がある場合が存在するようです。

更新に使用された refresh token (2) について

こちらは上記の 6 章にて、次のように記載されています。

The authorization server MAY revoke the old refresh token after issuing
a new refresh token to the client.

つまり、 authorization server が新しい refresh token を発行した後、使用済みの refresh token を無効化 「してもよい (MAY)」 のであって、必須ではありませんから、これは authorization server がどう実装するかに依存するという事です。

一方で、次のようにも記載されています。

The authorization server MAY issue a new refresh token, in which case the
client MUST discard the old refresh token and replace it with the new refresh token.

つまり、新しい refresh token を受け取った client は古い refresh token を破棄 「しなければならない (MUST)」 わけで、古い refresh token の扱いについては authorization server ではなく client 側の責任になっていることが分かります。

このような仕様となっている理由については分かりませんが、恐らく、次のような事情によるものではないでしょうか。

新しい refresh token を受け取れたことを最終的に確認できるのは client 側なので、そうでない場合に retry させる余地を残しておきたい
ただし、 10 Security Consideretions の 10.4. Refresh Tokens で言及されているように、 client の認証ができない場合は refresh token の悪用を防ぐ対策を講じる必要があり、その方法として例示されているような「一度使用された refresh token は (記憶しておきつつも) 無効化し、漏洩を検出する」手段があるため、その実装の余地を残しておきたい

投稿2018/12/04 09:25