Skip to content

OAuth 2.0 Refresh Token and Authorization Expiration

Web Authorization Protocol                                     N. Watson
Internet-Draft                                               Google, LLC
Intended status: Informational                          19 December 2025
Expires: 22 June 2026

draft-ietf-oauth-refresh-token-expiration-00

Abstract

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

About This Document

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

本ドラフトの最新版は以下で参照できる。

  • 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-Drafts は Internet Engineering Task Force (IETF) の作業文書である。他のグループも Internet-Drafts として作業文書を配布する場合があることに注意。現行の Internet-Drafts の一覧は以下にある。

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

Internet-Drafts は最大 6 か月間有効なドラフト文書であり、いつでも更新されたり、他の文書に置き換えられたり、廃止されたりする可能性がある。Internet-Drafts を参照資料として用いたり、「作業中 (work in progress)」以外の形で引用したりすることは不適切である。

この Internet-Draft は 22 June 2026 に期限切れとなる。

Copyright (c) 2025 IETF Trust および文書著者として示された者。無断転載を禁ず。

本文書は、公開日に有効な IETF Trust の「IETF 文書に関する法的規定」(https://trustee.ietf.org/license-info) および BCP 78 の適用を受ける。これらの文書には、本書に関する権利および制限が記載されているため、注意深く確認すること。

本書から抽出された Code Components には、Trust Legal Provisions の 4.e 節で述べられている Revised BSD License の文言を含めなければならず、また Revised BSD License に記載のとおり無保証で提供される。

Table of Contents

1. Introduction

RFC6749 は OAuth 2.0 プロトコルを定義しており、その一部として、client が refresh token を受け取り、それを繰り返し access token と交換できる能力がある。OAuth 2.0 には refresh token の有効期限（あるいは期限がないこと）に関する規範的な文言はなく、「通常は長期間有効である」と述べるだけである。

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

  • Authorization Server またはユーザーが、付与するアクセスが無期限のアクセスを許すには機微すぎると判断する場合（例: メールや健康データ）。
  • Authorization Server が、token endpoint で交換されないまま refresh token を保持できる最大期間を強制する場合。

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

2. Requirements Notation and Conventions

本文書中のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "OPTIONAL" は、ここに示すとおりすべて大文字で現れる場合に限り、BCP 14 [RFC2119] [RFC8174] に記載のとおり解釈される。

3. Terminology

"Resource owner" と "user" は、保護されたリソースへのアクセスを許可できる主体を指すものとして、互換的に用いてよい。

"Client", "application", "relying party" は、resource owner の代理として、かつその認可を得て、保護されたリソースへのリクエストを行う application を指すものとして、互換的に用いてよい。

4. Concepts

refresh token の失効（有効期限）に影響を与える仕組みは 2 つある。

4.1. Authorization expiration

[RFC6749] の Sec 4.1.1 で参照されるとおり、application が自身のデータへアクセスするための認可を付与する際、ユーザーはその認可に期限を設けることを選択できる。特に、データが機微である場合や、その application をどれくらい使い続けるか確信がない場合にそうすることがある。Authorization Server 自身も、認可期間に対して必須の上限を課す場合がある。

4.2. Refresh token timeout

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

5. Refresh token expiration

refresh token は、ユーザーの認可が期限切れとなるよりも後に期限切れになってはならない（MUST NOT）。Authorization Server が refresh token の交換の間隔に最大期間を強制する場合には、refresh token はそれより早く期限切れになってよい（MAY）。

ユーザーが認可を更新した場合、Authorization Server は、ユーザーの認可期限によって寿命が短縮されていた既存の refresh token について、その有効期限を更新すべきである（SHOULD）。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 response

本仕様は 2 つの新しい応答パラメータを導入する。

6.1. Successful response

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 は token endpoint の応答に refresh_token フィールドが含まれるときは常に、これらの値を返さなければならない（MUST）。

Authorization Server は、応答に refresh_token フィールドが含まれない場合でも、これらの値を返してよい（MAY）。その場合、値は提示された refresh token に対応する。これは、たとえば次のようなケースで有用である。

  • refresh_token_timeout について、Authorization Server が既存の refresh token の寿命をその場で更新した可能性がある。
  • authorization_expires_in について、ユーザーの認可の存続期間が帯域外で変更された可能性がある。
  • いずれのケースでも、client が各応答でこれらの値を受け取れるのは便利である。

6.1.1. Relationship of authorization_expires_in to scopes

authorization_expires_in は refresh token が用いられたときに token endpoint から返されるが、それは個々の token ではなく、ユーザーの scope（または RAR [RFC9396] による、より細粒度のアクセス）に対する認可に対応する。Authorization Server は、同一の scope に対する複数の refresh token について、一貫した存続期間を確保すべきである（SHOULD）。

認可の存続期間を scope に紐付けることで、あるアクセスは 1 つの期間だけ有効で、別のアクセスは異なる期間だけ有効、という形を取り得る。たとえば、ユーザーは openid scope に対しては無期限のアクセスを付与し、calendar scope に対しては短期間のアクセスを付与できる。

6.1.2. Infinite Expiration

値が省略されている場合、それは資格情報または認可の存続期間に固定の上限がないことを示す。Authorization Server が Authorization Server Metadata において refresh token の存続期間のサポートを宣言していない場合、省略された応答フィールドは、無期限の有効性を意味することもあれば、単に本仕様をサポートしていないことを意味する場合もある。

しかし、無期限の失効と、失効に関する情報がないことは、client によって同じように扱われるべきである。すなわち、client は常に、有効期限以外の理由（たとえばユーザーによる明示的な取り消し）による refresh token の無効化を取り扱わなければならない。

応答値を省略する代わりに、Authorization Server は、たとえば 10 年を表す 315569520 のような、大きな任意の値を返すことを選択してもよい。これにより、無期限値のサポートに関する曖昧さを避けつつ、実務上は類似の効果を得られる。

client は、すべての大きな値をリテラルとして扱わなければならず（MUST）、どれが無期限と見なされ得るかについて推測してはならない（MUST NOT）。

6.2. Error response

既存の invalid_grant エラーコードは、token の期限切れをすでに明示的に包含しており、十分であるはずだ。client はこのエラーコードを受け取ったら、新しい認可付与フローを開始すべきである（SHOULD）。

6.3. Example

Authorization Server が「refresh token は少なくとも 7 日に 1 回は交換されなければならない」というルールを強制しており、かつユーザーが application に対して 30 日間のアクセスの認可を付与したとする。初回の交換により、次の応答値が返される。

refresh_token_timeout: 604800  // 7 days
authorization_expires_in: 2592000  // 30 days

初回認可から 7 日後に交換すると、次の応答値が返される。

refresh_token_timeout: 604800  // 7 days
authorization_expires_in: 1987200  // 23 days

初回認可から 28 日後に交換すると、次の応答値が返される。

refresh_token_timeout: 172800  // 2 days
authorization_expires_in: 172800  // 2 days

7. Update to Authorization Server Metadata

期限付き refresh token のサポートは、OAuth 2.0 Authorization Server Metadata [RFC8414] において、次の metadata を用いて宣言すべきである（SHOULD）。

refresh_token_expiration_types_supported

  • OPTIONAL
  • サポートされる有効期限タイプの JSON 配列
  • 取り得る値は "authorization" と "credential"

Authorization Server が無期限の有効性を示すために有効期限の応答フィールドを省略する場合、client に対して本仕様を認識していることを示すために、metadata に refresh_token_expiration_types_supported を宣言しなければならない（MUST）。

8. User Experience Considerations

client は token がいつでも期限切れになり得ることを円滑に取り扱えなければならないが、意図しないサービスの中断があるとユーザー体験が損なわれる可能性がある。この体験の劣化は、バックグラウンドで動作する client、たとえばユーザーのカレンダーや受信箱へのアクセスに依存するタスク管理アプリや旅行管理アプリのユーザーで特に顕著に現れるだろう。

application が自身のアクセスの期限が近いことを認識した場合、次にユーザーが「関与している」タイミングで、再認可を促すことができる。たとえば [OpenID] の prompt=consent のようなパラメータを使う方法がある。あるいは、付与されたアクセスが期限切れになることを帯域外でユーザーに伝えることもできる。

9. Security Considerations

Authorization Server が refresh token を検証する際に両方のタイムスタンプを確認するのであれば、refresh token の有効期限をユーザーの認可の有効期限より長くすることも可能である。しかしこれは、ユーザー認可モデルが複雑なシステムにおいて、バグの潜在的に危険な原因となり得る。

refresh token はユーザーの認可が期限切れとなるよりも後に期限切れになってはならないと要件化することで、バグによってユーザーの認可期間を超えて client にデータアクセスを誤って与えてしまうリスクが減る。

refresh のたびに token rotation を実装する Authorization Server（[OAuth 2.1 Sec 4.3.1]）は、refresh token がローテーションされないまま保持できる最大期間を強制したい場合がある。本仕様は、その期間をドキュメントに頼るのではなく、API の一部として伝達できるようにする。

10. Privacy Considerations

ユーザーが自身の認可に期限を設けられるようにすることは、プライバシーの改善である。これは通常の OAuth 実装でもすでに可能だったが、ユーザーにとってサービス中断の可能性があるため、この機能の実装が敬遠されていた可能性がある。本仕様はその懸念を軽減するための標準化された方法を提供し、期限付き認可のより広い採用につながるはずである。

11. IANA Considerations

11.1. OAuth Parameters Registration

本仕様は、IANA OAuth Parameters レジストリに以下の OAuth パラメータ定義を登録する。

11.1.1. Registry Contents

  • Name: refresh_token_timeout
    • Parameter Usage Location: token response
    • Change Controller: IETF
    • Reference: This document
  • Name: authorization_expires_in
    • Parameter Usage Location: token response
    • Change Controller: IETF
    • Reference: This document

11.2. OAuth Authorization Server Metadata Registration

本仕様は、IANA OAuth Authorization Server Metadata レジストリに以下の Authorization Server Metadata 定義を登録する。

11.2.1. Registry Contents

  • Metadata Name: refresh_token_expiration_types_supported
    • Metadata Description: Authorization Server がどの種類の refresh token の有効期限をサポートしているか
    • Change Controller: IETF
    • Reference: This document

12. References

12.1. Normative References

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, https://www.rfc-editor.org/rfc/rfc2119
  • [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, https://www.rfc-editor.org/rfc/rfc6749
  • [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, https://www.rfc-editor.org/rfc/rfc8174
  • [RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018, https://www.rfc-editor.org/rfc/rfc8414

12.2. Informative References

  • [OpenID] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, "OpenID Connect Core 1.0", November 2014, openid.net/specs/openid-connect-core-1_0.html
  • [RFC9396] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 Rich Authorization Requests", RFC 9396, DOI 10.17487/RFC9396, May 2023, https://www.rfc-editor.org/rfc/rfc9396

Acknowledgments

TODO 謝辞を書く。

Author's Address

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