OAuth 2.0 Refresh Token and Authorization Expiration

Web Authorization Protocol                                     N. Watson
Internet-Draft                                               Google, LLC
Intended status: Informational                               6 July 2026
Expires: 7 January 2027

draft-ietf-oauth-refresh-token-expiration-03

Abstract

この仕様は OAuth 2.0 [RFC6749] を拡張し、Refresh Token の有効期限およびユーザーの認可の有効期限を指定するための新しい token endpoint レスポンスパラメーターを追加する。

About This Document

この注記は、RFC として公開する前に削除される。

このドラフトの最新版は、以下で確認できる。

https://drafts.oauth.net/rt-expiration/draft-ietf-oauth-refresh-token-expiration.html

この文書のステータス情報は、以下で確認できる。

https://datatracker.ietf.org/doc/draft-ietf-oauth-refresh-token-expiration/

この文書に関する議論は、Web Authorization Protocol Working Group のメーリングリスト（mailto:oauth@ietf.org）で行われており、以下でアーカイブされている。

https://mailarchive.ietf.org/arch/browse/oauth/

購読は以下から行える。

https://www.ietf.org/mailman/listinfo/oauth/

このドラフトのソースおよび Issue Tracker は以下で確認できる。

https://github.com/oauth-wg/rt-expiration

Status of This Memo

この Internet-Draft は、BCP 78 および BCP 79 の規定に完全に準拠して提出されている。

Internet-Draft は Internet Engineering Task Force（IETF）の作業文書である。他のグループも Internet-Draft として作業文書を配布する場合があることに注意されたい。現在の Internet-Draft の一覧は以下にある。

https://datatracker.ietf.org/drafts/current/

Internet-Draft は最大6か月間有効なドラフト文書であり、いつでも他の文書によって更新、置換、または廃止される可能性がある。Internet-Draft を参考資料として使用したり、「作業中の文書」以外のものとして引用したりすることは適切ではない。

この Internet-Draft は 2027年1月7日に失効する。

Copyright Notice

本文書には、本文書の公開日時点で有効な BCP 78 および IETF Trust の「IETF Documents に関する法的規定」が適用される。

https://trustee.ietf.org/license-info

これらの文書には、本文書に関する権利および制限事項が記載されているため、注意深く確認されたい。本文書から抽出された Code Components には、Trust Legal Provisions の Section 4.e に記載されている Revised BSD License の本文を含めなければならず、Revised BSD License に記載されているとおり、保証なしで提供される。

1. はじめに

RFC6749 は OAuth 2.0 プロトコルを定義しており、その一部として、client が Refresh Token を受け取り、それを繰り返し交換して追加の Access Token を取得できる仕組みがある。OAuth 2.0 には Refresh Token の有効期限、または有効期限が存在しないことに関する規範的な記述はなく、Refresh Token は「通常は長期間有効」であるとの記述があるだけである。

OAuth 2.0 の公開以降、セキュリティおよびプライバシーを取り巻く状況の変化に対応して、多くの Authorization Server が、主に次の2つの理由から、より有効期間の短い Refresh Token を発行するようになっている。

Authorization Server またはユーザーが、付与されるアクセスは無期限のアクセスを許可するには機密性が高すぎると判断する場合がある（例：メールや健康データ）。

Authorization Server が、Refresh Token を token endpoint で交換せずに保持できる最大期間を強制する。

client は、有効期限のある Refresh Token に対して特別な処理を実装したい場合がある。たとえば、ユーザーが有効期限付きのアクセスを許可した場合、client はサービスの中断を避けるため、特定の日付より前にアクセスを再認可する必要があることをユーザーに通知できる。

2. 要件を表す表記と規約

本文書における "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"NOT RECOMMENDED"、"MAY"、"OPTIONAL" というキーワードは、ここに示すようにすべて大文字で表記されている場合に限り、BCP 14 [RFC2119] [RFC8174] の記述に従って解釈されるものとする。

3. 用語

この仕様では [RFC6749] で定義された用語を使用する。本文書では、以下の用語を使用する。

Resource Owner および user
保護されたリソースへのアクセスを許可できる主体を指す用語として、相互に置き換えて使用される場合がある。

Client、application、および Relying Party (RP)
Resource Owner の代理として、その認可の下で保護されたリソースへのリクエストを行うアプリケーションを指す用語として、相互に置き換えて使用される場合がある。

Authorization
[RFC6749] Section 4.1.1 に記載されている、Resource Owner の代理として client が保護されたリソースへアクセスすることを Resource Owner が許可すること。

Access Token
[RFC6749] Section 1.4 で言及されている、Resource Owner の代理として client が保護されたリソースへアクセスするために使用する資格情報。Access Token は認可の証明を表す。

Refresh Token
[RFC6749] Section 1.5 で言及されている、ユーザーへの操作を要求せずに client が新しい Access Token を取得するために使用する資格情報。Refresh Token は認可を付与するものでも、認可を更新するものでもない。既存の認可の範囲内で新しい Access Token を取得するための仕組みを提供するだけである。

4. 概念

Refresh Token の有効期限に影響を与える仕組みは2つある。

4.1. 認可の有効期限

[RFC6749] Section 4.1.1 で言及されているように、アプリケーションがユーザーのデータへアクセスすることを認可する際、特にデータの機密性が高い場合や、そのアプリケーションをどの程度の期間使い続けるか分からない場合、ユーザーは認可に時間制限を設けることを選択できる。Authorization Server 自体が認可の有効期間に必須の制限を課す場合もある。

4.2. Refresh Token のタイムアウト

Authorization Server は、client が Refresh Token を交換せずに保持できる最大期間を定義したい場合がある。有効期限のある資格情報によって得られるセキュリティ上の利点に加え、これは、非常に古い有効な資格情報が世の中に残っていないことを Authorization Server が保証するための便利な仕組みにもなる。そうした古い資格情報が存在すると、Refresh Token の鍵ローテーションのような作業が複雑になる可能性がある。

5. Refresh Token の有効期限

Refresh Token は、ユーザーの認可が期限切れになる時点より後まで有効であってはならない（MUST NOT）。Authorization Server が Refresh Token の交換間隔にも最大期間を適用している場合は、より早く期限切れとなってもよい（MAY）。

ユーザーが認可を更新した場合、既存の Refresh Token の有効期間がユーザーの認可の有効期限によって短縮されていたのであれば、Authorization Server は既存の Refresh Token の有効期限を更新すべきである（SHOULD）。（これは特に、「ユーザーエクスペリエンスに関する考慮事項」（Section 9）で説明しているように、認可が帯域外で更新された場合に当てはまる。）Authorization Server は、既存の Refresh Token の有効期限を更新する方法が存在しない場合であっても、期限切れの Refresh Token をいかなる目的でも受け入れてはならない（MUST NOT）。

Access Token は、ユーザーの認可が期限切れになる時点より後まで有効であってはならない（MUST NOT）。ユーザーが認可を更新した場合、可能であれば Authorization Server は既存の Access Token の有効期限を更新してもよい（MAY）。Resource Server は、Authorization Server に既存の Access Token の有効期限を更新する方法が存在しない場合であっても、期限切れの Access Token をいかなる目的でも受け入れてはならない（MUST NOT）。

6. token endpoint のレスポンス

この仕様では、新しいレスポンスパラメーターを2つ導入する。

6.1. 成功レスポンス

refresh_token_timeout

client が Refresh Token を交換せずに保持できる時間（秒単位）。たとえば値 604800 は、レスポンスが生成された時点から1週間後に Refresh Token が期限切れになることを示す。この値は authorization_expires_in の値を超えてはならない（SHALL NOT）。

authorization_expires_in

発行された、または提示された Refresh Token に含まれる scope に対するユーザーの認可の有効期間（秒単位）。たとえば値 2629800 は、レスポンスが生成された時点から1か月後に認可が期限切れになることを示す。この値は refresh_token_timeout の値を超えてもよい（MAY）。

Authorization Server は、これらのパラメーターのうち一方だけを返してもよい（MAY）。

authorization_expires_in を伴わずに refresh_token_timeout を返す場合、ユーザーの認可は無期限であるが、Refresh Token の有効性を維持するには指定されたタイムアウト期間内に使用しなければならないことを示す。

refresh_token_timeout を伴わずに authorization_expires_in を返す場合、認可には固定された有効期間がある一方、Refresh Token には最大アイドル時間がなく、認可が帯域外で延長された場合には有効なままとなる可能性があることを示す。

有限である場合、token endpoint のレスポンスに refresh_token フィールドが含まれるたびに、Authorization Server はこれらの値を返さなければならない（MUST）。レスポンスに refresh_token フィールドが含まれていない場合でも、Authorization Server はこれらの値を返してもよく（MAY）、その場合、値は提示された Refresh Token に対応する。これは、たとえば以下のケースで有用となり得る。

refresh_token_timeout の場合、Authorization Server が既存の Refresh Token の有効期間をその場で更新している可能性がある。

authorization_expires_in の場合、ユーザーの認可の有効期間が帯域外で変更されている可能性がある。

いずれの場合も、client が各レスポンスでこれらの値を受け取れることは便利である。

6.1.1. authorization_expires_in と scope の関係

authorization_expires_in は Refresh Token の使用時に token endpoint から返されるが、これは個々のトークンではなく、scope に対するユーザーの認可（または RAR [RFC9396] による、より細粒度のアクセス）に対応する。Authorization Server は、同じ scope に対する複数の Refresh Token について、一貫した有効期間となるようにすべきである（SHOULD）。

認可の有効期間を scope に関連付けるということは、あるアクセスは特定の期間だけ有効であり、別のアクセスは異なる期間だけ有効であるという状況があり得ることを意味する。たとえば、ユーザーが openid scope には無期限のアクセスを許可し、calendar scope には短期間のアクセスを許可することがあり得る。

このような場合、Authorization Server は、Refresh Token によって付与されるアクセスのうち、最も短い有効期間を返すことが推奨される（RECOMMENDED）。ただし、これには client が必要以上に早くユーザーへ再認可を求めるリスクもある。前述の例では、短期間の calendar scope に対応する authorization_expires_in の値を受け取ったために、client が openid scope の再認可までユーザーに求める可能性がある。

client が異なる有効期間を持ち得る複数の scope を要求している場合、ユーザーにいつ、どのように再認可を求めるかを決定するには、最終的には client 自身がトレードオフを判断する必要がある。この仕様の目的は、その判断に必要な情報をより多く提供することにすぎない。

6.1.2. 無期限

値が省略されている場合、資格情報または認可の有効期間に固定された上限がないことを示す。

Authorization Server が Authorization Server Metadata で Refresh Token の有効期間に対応していることを宣言していない場合、レスポンスフィールドの省略は、無期限に有効であることを示している可能性も、この仕様に対応していないだけである可能性もある。

しかし、無期限の有効期限と、有効期限に関する情報が存在しない場合は、client からは同じように扱われるべきである。つまり、client は、ユーザーによる明示的な失効など、有効期限以外の理由による Refresh Token の無効化を常に処理できなければならない。

client は、あるレスポンスでレスポンスフィールドが省略されたからといって、後続のレスポンスでも同じフィールドが省略されると仮定してはならない（MUST NOT）。

レスポンス値を省略する代わりに、Authorization Server は、たとえば10年を表す 315569520 のような、任意の大きな値を返すことを選択してもよい。これにより、無期限の値への対応状況に関する曖昧さを避けつつ、実質的に同様の効果を得られる。

client は、すべての大きな値を文字どおりの値として扱わなければならず（MUST）、どの値が無期限を意味すると見なせるかについて、いかなる仮定もしてはならない（MUST NOT）。

6.2. エラーレスポンス

既存の invalid_grant エラーコードは、すでにトークンの有効期限切れを明示的に対象としており、十分であると考えられる。このエラーコードを受け取った場合、client は新しい認可 grant のフローを開始すべきである（SHOULD）。

6.3. 例

Authorization Server が Refresh Token を少なくとも7日に1回交換することを要求しており、ユーザーがアプリケーションに対して10日間のアクセスを認可したとする。最初の Authorization Code grant（Day 0）では、以下のレスポンス値となる。

refresh_token_timeout: 604800  // 7日
authorization_expires_in: 864000  // 10日

Day 2 の Refresh Token Grant では、以下のレスポンス値となる。

refresh_token_timeout: 604800  // 7日
authorization_expires_in: 691200  // 8日

Day 7 の Refresh Token Grant では、以下のレスポンス値となる。

refresh_token_timeout: 259200  // 3日
authorization_expires_in: 259200  // 3日

一方、client が最初の Refresh Token を8日間保持した場合（つまり refresh_token_timeout は超過しているが、authorization_expires_in は超過していない場合）、Refresh Token Grant は失敗する。

error: invalid_grant
error_description: "expired refresh token"

エラー説明のテキストは規範的なものではなく、説明のためだけに示していることに注意されたい。

7. Token Introspection の更新

Token Introspection [RFC7662] は、主として受け取った Access Token に関する情報を取得しようとする Resource Server を対象としているが、この仕様では Refresh Token の introspection も許可している。

Refresh Token の introspection に対応する Authorization Server は、「token endpoint のレスポンス」（Section 6）で定義されているものと同じ意味を持つ refresh_token_timeout および authorization_expires_in パラメーターに endpoint で対応すべきである（SHOULD）。これらのパラメーターは、提示されたトークンが Refresh Token である場合にのみ返すべきである（SHOULD）。

Token Introspection で Refresh Token を使用しても、refresh_token_timeout の期間をリセットしてはならない（MUST NOT）。

8. Authorization Server Metadata の更新

有効期限付き Refresh Token への対応は、OAuth 2.0 Authorization Server Metadata [RFC8414] において、以下のメタデータを使用して宣言すべきである（SHOULD）。

refresh_token_expiration_types_supported

OPTIONAL。対応している有効期限の種類を示す JSON 配列。指定可能な値は "authorization" および "token_timeout" である。

Authorization Server が無期限の有効性を示すために有効期限のレスポンスフィールドを省略する場合、この仕様を認識していることを client に示すため、メタデータで refresh_token_expiration_types_supported を宣言しなければならない（MUST）。

9. ユーザーエクスペリエンスに関する考慮事項

client はトークンがいつ期限切れになっても適切に処理できなければならないが、意図しないサービス中断が発生すると、ユーザーエクスペリエンスが損なわれる可能性がある。

このようなユーザーエクスペリエンスの低下は、ユーザーのカレンダーや受信トレイへのアクセスに依存するタスク管理アプリや旅行管理アプリなど、Backend で動作する client のユーザーが最も強く感じる可能性がある。

アプリケーションが自身のアクセスの有効期限が近づいていることを認識した場合、ユーザーが次に「処理の中にいる」タイミングで、再認可を事前に求めることができる（たとえば [OpenID] の prompt=consent のようなパラメーターを使用する）。あるいは、付与されたアクセスの有効期限が近づいていることを、帯域外でユーザーに伝えることもできる。

Authorization Server がユーザーに提供できるもう1つの選択肢として、ユーザー自身が自発的に grant の有効期間を延長できる管理画面が考えられる。これにより、client の Refresh Token の有効期間がその場で更新される。client は、次回の Refresh Token Grant リクエストで、延長された有効期限を認識することになる。

10. セキュリティに関する考慮事項

Authorization Server が Refresh Token を検証するときに両方のタイムスタンプを確認するのであれば、Refresh Token の有効期限をユーザーの認可の有効期限より後に設定することは技術的には可能である。

しかし、これは複雑なユーザー認可モデルを持つシステムにおいて、潜在的に危険なバグの原因となる。Refresh Token をユーザーの認可が期限切れとなる時点より後まで有効にしないことを要求することで、ユーザーの認可期間を超えて誤って client にデータへのアクセスを許可してしまうバグのリスクを減らせる。

毎回の refresh でトークンローテーションを実装する Authorization Server [RFC9700] Section 4.14 は、Refresh Token をローテーションせずに保持できる最大期間を強制したい場合がある。この仕様では、その期間をドキュメントに依存するのではなく、API の一部として伝達できる。

client は、異なる scope ごとの有効期間を分離するため、異なるアクセス権を持つ複数の Refresh Token を保持したい場合がある。たとえば、金融データへアクセスするための短期間のトークンと、基本的なユーザー情報へアクセスするための長期間のトークンを分けることが考えられる。

この方法には、トークン管理の複雑さと、ユーザーが複数のトークンを認可する際の負担増加の両面でトレードオフが存在する。

11. プライバシーに関する考慮事項

ユーザーが自身の認可に時間制限を設けられるようにすることは、プライバシーの向上につながる。

これは通常の OAuth 実装でもすでに実現可能だったが、ユーザーのサービスが中断される可能性が、この機能の実装を妨げていた可能性がある。

この仕様は、この懸念を軽減するための標準化された方法を提供するものであり、時間制限付き認可の採用拡大につながるはずである。

12. IANA に関する考慮事項

12.1. OAuth パラメーターの登録

この仕様は、IANA OAuth Parameters registry に以下の OAuth パラメーター定義を登録する。

12.1.1. Registry の内容

Name: refresh_token_timeout
- Parameter Usage Location: token response
- Change Controller: IETF
- Reference: 本文書

Name: authorization_expires_in
- Parameter Usage Location: token response
- Change Controller: IETF
- Reference: 本文書

12.2. OAuth Authorization Server Metadata の登録

この仕様は、IANA OAuth Authorization Server Metadata registry に以下の Authorization Server Metadata 定義を登録する。

12.2.1. Registry の内容

Metadata Name: refresh_token_expiration_types_supported
- Metadata Description: Authorization Server が対応する Refresh Token の有効期限の種類
- Change Controller: IETF
- Reference: 本文書

12.3. 変更履歴

このセクションは公開前に削除する。

2026年5月8日:
- Vanshaj のレビューを反映:
  - 明確な有効期間が有限になる場合の後方互換性に関する記述を追加。
  - refresh_token_expiration_types_supported の "credential" という値を "token_timeout" に改名。
  - 例を簡略化。
  - Refresh Token の有効期限セクションからユーザーエクスペリエンスに関する考慮事項への参照を追加。

2026年2月27日:
- George による Issue 4、5、6 に対応し、有効期限が異なる複数のトークンまたは scope を管理する際のトレードオフ、およびユーザーによる帯域外での再認可について議論を追加。
- メーリングリスト上の Dan の提案に基づき、表現の変更と明確化を実施。

13. 参考文献

13.1. 規範的参考文献

[RFC2119] Bradner, S., 「RFC において要件レベルを示すために使用するキーワード」, BCP 14, RFC 2119, DOI 10.17487/RFC2119, 1997年3月.

[RFC6749] Hardt, D., Ed., 「OAuth 2.0 Authorization Framework」, RFC 6749, DOI 10.17487/RFC6749, 2012年10月.

[RFC7662] Richer, J., Ed., 「OAuth 2.0 Token Introspection」, RFC 7662, DOI 10.17487/RFC7662, 2015年10月.

[RFC8174] Leiba, B., 「RFC 2119 のキーワードにおける大文字と小文字の曖昧性」, BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2017年5月.

[RFC8414] Jones, M., Sakimura, N., and J. Bradley, 「OAuth 2.0 Authorization Server Metadata」, RFC 8414, DOI 10.17487/RFC8414, 2018年6月.

[RFC9700] Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett, 「OAuth 2.0 Security の Best Current Practice」, BCP 240, RFC 9700, DOI 10.17487/RFC9700, 2025年1月.

13.2. 参考情報

[OpenID] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, 「OpenID Connect Core 1.0」, 2014年11月.

[RFC9396] Lodderstedt, T., Richer, J., and B. Campbell, 「OAuth 2.0 Rich Authorization Requests」, RFC 9396, DOI 10.17487/RFC9396, 2023年5月.

Acknowledgments

IETF ドラフトのプロセスを進めるにあたり、継続的なフィードバックと、著者を導くうえで非常に貴重な支援を提供してくれた Aaron Parecki に特別な感謝を表する。

また著者は、リポジトリおよびメーリングリスト上でレビューと技術的な提案を提供してくれた Andrii Deinega、George Fletcher、Dan Moore、Vanshaj Singhania にも感謝する。

著者の連絡先

Nicholas Watson
Google, LLC
Email: nwatson@google.com