質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.42%
OAuth

OAuth(Open Authorization)は、APIを通して保護されたリソース(サードパーティのアプリケーション)へアクセスする為のオープンプロトコルです。

OAuth 2.0

OAuth 2.0(Open Authorization 2.0)は、APIを通して保護されたリソース(サードパーティのアプリケーション)へアクセスする為のオープンプロトコルです。

Q&A

解決済

1回答

3582閲覧

OAuth2.0: refresh_tokenでaccess_tokenを再発行した時の挙動について

chunt

総合スコア13

OAuth

OAuth(Open Authorization)は、APIを通して保護されたリソース(サードパーティのアプリケーション)へアクセスする為のオープンプロトコルです。

OAuth 2.0

OAuth 2.0(Open Authorization 2.0)は、APIを通して保護されたリソース(サードパーティのアプリケーション)へアクセスする為のオープンプロトコルです。

0グッド

0クリップ

投稿2018/12/01 05:42

編集2018/12/01 06:02

背景

あるサービスが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の仕様なのでしょうか。
それとも、サービス固有なものなのでしょうか。

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

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答1

0

ベストアンサー

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

argparse

総合スコア1017

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.42%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問