Skip to content

Internet Engineering Task Force (IETF) V. Bertocci\ Request for Comments: 9470 Auth0/Okta\ Category: Standards Track B. Campbell\ ISSN: 2070-1721 Ping Identity\ September 2023

OAuth 2.0 Step Up Authentication Challenge Protocol

Abstract

Resource Server が、リクエストの特性に応じて異なる認証強度や認証の新しさ（直近性）を要求することは珍しくありません。本書は、Resource Server がクライアントに対し、現在のリクエストに付随して提示された Access Token に紐づく認証イベントが自らの認証要件を満たしていないこと、そしてそれを満たす方法を通知するために利用できるメカニズムを導入します。さらに本書は、Authorization Server による authorization request の処理時に、特定の認証強度または認証の新しさ（直近性）を達成するようクライアントが要求できるメカニズムも規定します。

Status of This Memo

本書は Internet Standards Track 文書です。

本書は Internet Engineering Task Force (IETF) の成果物です。IETF コミュニティの合意を反映しています。公開レビューを受け、Internet Engineering Steering Group (IESG) により公開承認されています。Internet Standards に関する追加情報は RFC 7841 の Section 2 にあります。

本書の最新状況、正誤表（errata）、およびフィードバック提供方法に関する情報は、以下から入手できます:\ https://www.rfc-editor.org/info/rfc9470.

Copyright (c) 2023 IETF Trust および文書著者として特定された者。All rights reserved.

本書は、公開日時点で有効な 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 に記載のとおり無保証で提供されます。

Table of Contents

1. Introduction

シンプルな API 認可シナリオでは、Authorization Server は、要求された scope、resource、クライアントの識別情報、ならびにプロビジョニング時点で既知のその他の特性などの要素に基づいて、特定のリクエストを処理するためにどの認証手法を用いるかを決定します。このアプローチは多くの状況で有効ですが、いくつかの重要な状況では不十分です。たとえば、eCommerce API が、購入する品目が一定の閾値を超えるかどうか（その判定は API 自身が動的に見積もり、かつそのロジックが Authorization Server には不透明である）に応じて、異なる認証強度を要求するケースを考えてください。また、API は API リクエストに対する自身のリスク評価に基づき、より直近のユーザー認証が必要だと判断することもあります。

本書は、RFC6750 で定義されたエラーコードの集合を、新しい値 insufficient_user_authentication により拡張します。これは Resource Server がクライアントに対し、リクエストとともに提示された Access Token に紐づく認証イベントが、当該 Resource Server の認証要件を満たしていないことを通知するために利用できます。さらに本書は、RFC6750 で定義された Bearer 認証スキームの challenge に対して、acr_values および max_age パラメータを導入します。Resource Server はこれらのパラメータを用いて、必要な認証強度や認証の新しさ（直近性）をクライアントに明示的に伝えることができます。

クライアントはその情報を用いて、保護されたリソースが示した認証要件を指定する authorization request を Authorization Server に対して行えます。これは OIDC で定義されている acr_values または max_age の authorization request パラメータを含めることで実現されます。

これらの拡張により、Resource Server、クライアント、Authorization Server の最小限の作業で、相互運用可能な step up authentication を実装できるようになります。

1.1. Conventions and Terminology

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

本仕様は、「The OAuth 2.0 Authorization Framework」(RFC6749) で定義された用語 "access token", "authorization server", "authorization endpoint", "authorization request", "client", "protected resource", "resource server" を使用します。

2. Protocol Overview

以下は、本仕様に従って実装された典型的な step up authentication シナリオのエンドツーエンドの流れです。このシナリオでは、以下に説明するシーケンスが始まる前に、クライアントはすでに保護されたリソース向けの Access Token を取得しているものとします。

+----------+                                          +--------------+
|          |                                          |              |
|          |-----------(1) request ------------------>|              |
|          |                                          |              |
|          |<---------(2) challenge ------------------|   Resource   |
|          |                                          |    Server    |
|  Client  |                                          |              |
|          |-----------(5) request ------------------>|              |
|          |                                          |              |
|          |<-----(6) protected resource -------------|              |
|          |                                          +--------------+
|          |
|          |
|          |  +-------+                              +---------------+
|          |->|       |                              |               |
|          |  |       |--(3) authorization request-->|               |
|          |  | User  |                              |               |
|          |  | Agent |<-----------[...]------------>| Authorization |
|          |  |       |                              |     Server    |
|          |<-|       |                              |               |
|          |  +-------+                              |               |
|          |                                         |               |
|          |<-------- (4) access token --------------|               |
|          |                                         |               |
+----------+                                         +---------------+

Figure 1: Abstract Protocol Flow

  1. クライアントは Access Token を提示して protected resource を要求します。
  2. Resource Server は、提示された Access Token が取得された状況では認証強度および/または認証の新しさ（直近性）が不十分であると判断します。そのためリクエストを拒否し、Resource Server がリクエストを認可するために満たされるべき認証要件（acr_values と max_age の組み合わせで表現）を記述した challenge を返します。
  3. クライアントは user agent を Authorization Server に誘導し、前段で Resource Server が示した acr_values および/または max_age を含む authorization request を送ります。
  4. 選択した grant で要求される一連の処理が実行されます。これには、authorization request の acr_values および/または max_age の値に従ってユーザーを認証するための必要なステップが含まれます。その後、Authorization Server は新しい Access Token をクライアントに返します。新しい Access Token には、認証イベントに関する情報が含まれるか、参照されます。
  5. クライアントはステップ 1 のリクエストを繰り返し、今回取得した Access Token を提示します。
  6. Resource Server は、新しい Access Token の取得時に行われたユーザー認証が要件に適合していることを確認し、要求された protected resource の表現を返します。

ステップ 2 と 6 で言及される検証操作は、Resource Server が Access Token が取得されたプロセス中に発生した認証を評価する手段を持つことを意味します。本書の文脈では、Resource Server による、要求された resource に対する token を取得するために用いられた特定の認証手法の評価を「authentication level」と呼びます。本書は、Access Token が JWT (RFC9068) の場合、または introspection (RFC7662) により検証される場合に、Resource Server がこの authentication level を評価する方法を説明します。Authorization Server と protected resource の合意により、Access Token がどの authentication level で取得されたかを判断する他の方法もあり得ますが、それらは本仕様の範囲外です。token の authentication level が与えられたとき、Resource Server はそれが要求された resource のセキュリティ基準を満たすかどうかを判断します。

本仕様における用語「authentication level」と「step up」は比喩です。これらの比喩は、相互運用可能な形で表現された認証手法の絶対的な階層が存在することを示唆するものではありません。level という概念は、Resource Server が受け入れたい認証手法を限定したい場合がある、という事実から生じます。Resource Server が受け入れたくない特定の認証手法（すなわちある authentication level）に由来する token を提示されたとき（つまり受け入れ閾値／level 未満であるとき）、Resource Server は現在の authentication level から受け入れ可能なものへ step up（すなわち再交渉）しようとします。「step up」の比喩は、元の authentication level から Resource Server が受け入れられる level への移行を表現するためのものです。

新しい Access Token が、より高い authentication level を持つことにより古い token を置き換えるケースは一般的ですが、一般の場合に必ずそうなるとは限らない点に留意することが重要です。たとえば、ある特定のリクエストについて Resource Server がより高い authentication level とより短い有効期間を要求し、その結果、ワンオフの呼び出しには適した token が得られるものの、頻繁な prompt を招く場合があります。こうした場合、その token を定常的な操作に再利用すると、ユーザー体験が最適ではなくなります。このようなシナリオでは、クライアントは、より低い authentication level に紐づく古い token と、新しい token の両方を保持し、各 API 呼び出しごとに適切な token を選択する方が望ましいでしょう。これはクライアントにとって新しい要件ではありません。インクリメンタルな consent や最小権限（least-privilege）の原則により、異なる scope や権限レベルに紐づく Access Token を管理するために同様のヒューリスティクスが必要になるからです。本書は特定の token キャッシュ戦略を推奨しません。選択は各シナリオの特性に依存し、コア OAuth のケースと同様に application-dependent です。また、OAuth 2.0 (RFC6749) は、クライアントが Access Token を opaque として扱うことを前提としていることを思い出してください。token の形式はクライアントにとって読めない場合があり、いつでも読めない形式に変わり得ます。したがって、どのような token キャッシュ戦略の過程においても、クライアントは、Access Token の内容を検査して、紐づく認証情報やその他の詳細を判断しようとしてはなりません（より詳細な議論については RFC9068 の Section 6 を参照してください）。

3. Authentication Requirements Challenge

本仕様は、Bearer 認証スキームの challenge の error パラメータ（RFC6750 由来）および、同じ error パラメータを用いる RFC9449 に見られるような他の OAuth 認証スキームのために、新しいエラーコード値を導入します:

  • insufficient_user_authentication: リクエストとともに提示された Access Token に紐づく認証イベントが、protected resource の認証要件を満たしていない。

注: Resource Server が現在のリクエストが protected resource の認証要件を満たしていないと判断するロジック、およびそれに付随する機能（要件の表現、配備、公開など）は、本書の範囲外です。

さらに本仕様は、これらの OAuth 認証スキームが、認証要件をクライアントへ伝えるために用いる WWW-Authenticate auth-param 値として、以下を定義します。

  • acr_values: 優先順に authentication context class reference 値を並べた、スペース区切りの文字列。protected resource は、Access Token に紐づく認証イベントがこれらの値のいずれかであることを要求します。OIDC の Section 1.2 で定義されるとおり、authentication context は、認証がどのように行われるか（例: どの認証手法、または満たすべき保証レベル）に関する情報を伝えます。
  • max_age: Access Token に紐づく最後の active authentication event から経過した許容時間（秒）を示します。active authentication event とは、認証 prompt に応答してユーザーが Authorization Server と対話することを伴う認証イベントを指します。auth-param 値は token または quoted-string として伝えられ得ますが（RFC9110 の Section 11.2 参照）、非負の整数を表さなければならない点に注意してください。

Figure 2 は、WWW-Authenticate ヘッダを用いた Bearer 認証スキームの challenge 例です。そこでは次を使用しています:

  • insufficient_user_authentication エラーコード値により、提示された Access Token では protected resource へのアクセスに不十分であることをクライアントに知らせる。
  • acr_values パラメータにより、期待される authentication level が myACR により識別される authentication context class reference に対応することをクライアントに知らせる。

本仕様は、上記 auth-params を insufficient_user_authentication エラーコードとともに使用することのみを定義しますが、将来の仕様やプロファイルが、他のエラーコードとともにそれらの使用を定義することを妨げるものではありません。

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer error="insufficient_user_authentication",
  error_description="A different authentication level is required",
  acr_values="myACR"

Figure 2: Authentication Requirements Challenge Indicating acr_values

Figure 3 の例は、提示された Access Token に紐づく最後の active authentication event が古すぎるため、より直近の認証が必要であることをクライアントに知らせる challenge を示します。

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer error="insufficient_user_authentication",
  error_description="More recent authentication is required",
  max_age="5"

Figure 3: Authentication Requirements Challenge Indicating max_age

Resource Server が認証の直近性と authentication level の両方に関する要件を表現する必要がある場合、auth-params の max_age と acr_values は同じ challenge に同時に含まれてもかまいません。さらに Resource Server が、リクエストされた resource に必要な scope も不足していると判断した場合、RFC6750 の Section 3.1 に記載のとおり、protected resource へアクセスするために必要な値を持つ scope 属性を含めてもかまいません（MAY）。

4. Authorization Request

Resource Server から insufficient_user_authentication エラーコードを伴う challenge を受け取ったクライアントは、WWW-Authenticate ヘッダから acr_values および max_age を解析し、存在する場合は、それらを用いて authorization request を構築することが推奨されます。このリクエストは、対応する要件に適合する新しい Access Token を取得するために、user agent を介して Authorization Server の authorization endpoint に送られます。acr_values と max_age の authorization request パラメータは、いずれも OIDC の Section 3.1.2.1. で定義された OPTIONAL パラメータです。本書は、それらのパラメータ処理に関して OIDC で定義された Authorization Server の挙動に変更を導入しません。したがって OpenID Connect を実装する任意の Authorization Server は、ほとんど、またはまったく変更せずにここで説明されるフローに参加できます。詳細は Section 5 を参照してください。

以下の例の authorization request URI は、Figure 2 の challenge を受け取った後に使用され得るもので、クライアントが myACR で識別される authentication context class reference に従って認証が行われることを望む旨を Authorization Server に示します。

https://as.example.net/authorize?client_id=s6BhdRkqt3
&response_type=code&scope=purchase&acr_values=myACR

Figure 4: Authorization Request Indicating acr_values

Figure 3 の challenge の後、クライアントは user agent を次の例の authorization request URI に誘導するかもしれません。ここで max_age パラメータは、ユーザー認証イベントが 5 秒以内に発生している必要があることを Authorization Server に示します。

https://as.example.net/authorize?client_id=s6BhdRkqt3
&response_type=code&scope=purchase&max_age=5

Figure 5: Authorization Request Indicating max_age

5. Authorization Response

OIDC の Section 5.5.1.1 は、acr_values パラメータを含むリクエストを受け取った Authorization Server は、要求された authentication context class reference を満たす方法でユーザーを認証し、結果の ID Token の acr claim に対応する値を含めてもよい（MAY）ことを定めています。同じ section はまた、望ましい authentication level を満たせない場合、Authorization Server は、（もしあれば）現在のセッションの authentication level を反映する値を acr claim に含めるべき（SHOULD）ことも定めています。さらに OIDC の Section 3.1.2.1 は、リクエストに max_age パラメータが含まれる場合、Authorization Server は発行する ID Token に auth_time claim を含めなければならない（MUST）と述べています。本仕様に準拠する Authorization Server は、acr_values と max_age パラメータの存在に反応して、Access Token に acr と auth_time を含めます（詳細は Section 6 を参照）。OIDC は、acr_values により要求された場合に ID Token へ acr を含める扱いを Authorization Server に委ねていますが、本仕様の Access Token に関しては、Authorization Server は、要求された acr 値をリクエスト成功に必要なものとして扱うことを検討すべき（SHOULD）です。すなわち、認証処理が要件を成功裏に満たした場合に限り、要求された acr 値が Access Token に含まれます。そうでない場合、authorization request は失敗し、OIDCUAR で定義された unmet_authentication_requirements エラーを返します。この推奨挙動は、Authorization Server が Resource Server によりすでに要件未達と判定された token を返し続け、クライアントがループに陥ることを防ぐのに役立ちます。

6. Authentication Information Conveyed via Access Token

Access Token が protected resource の要件を満たすかどうかを評価するために、Resource Server は、その Access Token がどの認証イベントによって取得されたかに関する情報へアクセスする手段を必要とします。本仕様は、よく使われる 2 つの Access Token 検証方法と組み合わせて、その情報をどのように伝えるかの指針を提供します:

  • RFC9068 に記述される方法（Access Token が JWT 形式でエンコードされ、検証ルール群により検証される）
  • RFC7662 に記述される方法（token を introspection endpoint に送って検証・デコードする）

Authorization Server と Resource Server は他のエンコード・検証方法を選択してもかまいません（MAY）が、それらは本書の範囲外です。

6.1. JWT Access Tokens

Access Token が JWT (RFC7519) として表現される場合、auth_time と acr の claims（RFC9068 の Section 2.2.1 に従う）が、Access Token を取得する過程で authentication server が行ったユーザー認証イベントの時刻と文脈を伝えるために使用されます。これら 2 つのパラメータの値はユーザー認証時点で確定し、Access Token の更新（renewals）があっても変化しない点を念頭に置くと有用です。詳細は RFC9068 の Section 2.2.1 を参照してください。以下は、そのような JWT Access Token をデコードした内容の概念例です。

Header:

{ "typ": "at+JWT", "alg": "ES256", "kid": "LTacESbw" }

Claims:

{
  "iss": "https://as.example.net",
  "sub": "someone@example.net",
  "aud": "https://rs.example.com",
  "exp": 1646343000,
  "iat": 1646340200,
  "jti": "e1j3V_bKic8-LAEB_lccD0G",
  "client_id": "s6BhdRkqt3",
  "scope": "purchase",
  "auth_time": 1646340198,
  "acr": "myACR"
}

Figure 6: Decoded JWT Access Token

6.2. OAuth 2.0 Token Introspection

「OAuth 2.0 Token Introspection」(RFC7662) は、protected resource が Authorization Server に対して Access Token の active 状態を問い合わせ、token に関するメタ情報を得るための方法を定義します。以下の 2 つのトップレベルの introspection response メンバーが、Access Token を取得する過程で authentication server が行ったユーザー認証イベントに関する情報を伝えるために定義されています。

  • acr: 実行されたユーザー認証イベントによって満たされた authentication context class を識別する authentication context class reference 値を指定する文字列。
  • auth_time: ユーザー認証が行われた時刻。認証イベントの日時までの秒数（1970-01-01T00:00:00Z UTC からの秒数）を表す JSON の数値。

以下の例は、Access Token がどのユーザー認証イベントによって取得されたかに関する情報を含む introspection response を示します。

HTTP/1.1 200 OK
Content-Type: application/json

{
  "active": true,
  "client_id": "s6BhdRkqt3",
  "scope": "purchase",
  "sub": "someone@example.net",
  "aud": "https://rs.example.com",
  "iss": "https://as.example.net",
  "exp": 1639528912,
  "iat": 1618354090,
  "auth_time": 1646340198,
  "acr": "myACR"
}

Figure 7: Introspection Response

7. Authorization Server Metadata

Authorization Server は、RFC8414 で定義されるメタデータ文書に、OIDCDISC の Section 3 で定義される値 acr_values_supported を含めることで、本仕様への対応を広告できます。Authorization Server のメタデータ文書に acr_values_supported が存在することは、Authorization Server が受信する authorization request の acr_values と max_age パラメータを理解し、それらを尊重することを示します。

8. Deployment Considerations

本仕様は、Resource Server からクライアントへの要件伝達を容易にし、それにより円滑な step up authentication 体験を可能にします。しかし、個々のデプロイメントで実現可能なユーザー体験は、各 Resource Server と Authorization Server の組が定めるポリシーの関数であることを理解することが重要です。これらのポリシーに制約を課すことは本仕様の範囲外です。したがって、Resource Server と Authorization Server が、ユーザーが遵守不可能な要件、または望ましくないユーザー体験の結果につながる要件を課すことも完全にあり得ます。ここで説明した認証要件伝播の方法により提示される Authorization Server の認証 prompt は、複数のデバイスを使用する、特定のセキュリティ要件に準拠したデバイスへアクセスできる、などの特定のアクションをユーザーに求める場合があります。こうした追加要件（要件そのものの識別子を示すのではなく、要件にどう準拠するかに関係するもの）は、本仕様の範囲外です。

9. Security Considerations

本仕様は、以前に定義された OAuth メカニズムに追加を行います。各仕様のセキュリティ上の考慮事項が適用されます:

  • OAuth 2.0 (RFC6749)
  • JWT Access Token (RFC9068)
  • Bearer WWW-Authenticate (RFC6750)
  • token introspection (RFC7662)
  • Authorization Server metadata (RFC8414)

本書は、OAuth を認証プロトコルとして位置付けるために使用してはなりません（MUST NOT）。本仕様の目的においては、Authorization Server とユーザーがどのように認証して Access Token を取得したかは重要な情報です。というのも、Resource Server はその認証操作がどのように行われたかに基づいてアクセス許可を決定し得るからです。とはいえ本仕様は、認証がどのように行われるかのメカニズムを定義しようとはせず、詳細は別の認証レイヤに委ねています。OAuth ファミリの他の仕様と同様に、本書は、セッションがどのように確立・維持されるか、そのレイヤを実装するためにどのプロトコル（例: OpenID Connect (OIDC)）が用いられるか等の詳細には踏み込みません。

Resource Server が採用するポリシーによっては、Section 3 で導入された acr_values パラメータが、認証済みユーザー、resource 自体、Authorization Server、その他コンテキスト固有のデータに関する情報を、攻撃者が標的の知識を得るために利用し得る形で意図せず開示する可能性があります。たとえば、Resource Server が、一部のユーザーには高い保証レベルに対応する acr 値を要求し、他のユーザーには要求しない場合、高権限ユーザーの可能性がある対象を特定し、スピアフィッシング攻撃の標的にすることができます。実装者は、challenge で何を、どの状況で開示するかを慎重に判断すべきです。

challenge を返すべきかどうかを決定するために、受信した Access Token を検査するロジックは、JWT 検証、introspection、その他の方法に基づく通常の token 検証ロジックの前でも後でも実行できます。Resource Server は、クライアントが有効な token を提示したことを検証せずに challenge を返してもかまいません（MAY）。しかしこのアプローチは、この Resource Server のための token を取得できることを証明していない主体へ、Authorization Token に求められる特性を漏えいさせます。

本仕様は Resource Server がユーザー操作をトリガーするメカニズムを提供するため、悪意ある Resource Server がこの機能を悪用する可能性があることを、Authorization Server とクライアントは考慮することが重要です。

10. IANA Considerations

10.1. OAuth Extensions Error Registration

本仕様は、RFC6749 により確立された「OAuth Extensions Error Registry」(IANA.OAuth.Params) に、以下のエラー値を登録します。

  • Name: insufficient_user_authentication
  • Usage Location: resource access error response
  • Protocol Extension: OAuth 2.0 Step Up Authentication Challenge Protocol
  • Change controller: IETF
  • Specification document(s): RFC 9470 の Section 3

10.2. OAuth Token Introspection Response Registration

本仕様は、RFC7662 により確立された「OAuth Token Introspection Response」レジストリ (IANA.OAuth.Params) に、以下の値を登録します。

Authentication Context Class Reference:

  • Name: acr
  • Description: Authentication Context Class Reference
  • Change Controller: IETF
  • Specification Document(s): RFC 9470 の Section 6.2

Authentication Time:

  • Name: auth_time
  • Description: Time when the user authentication occurred
  • Change Controller: IETF
  • Specification Document(s): RFC 9470 の Section 6.2

11. References

11.1. Normative References

11.2. Informative References

Acknowledgements

Academy、家庭で視聴している皆さん、シャンプー製造業者などに感謝したいと思います。

本仕様は OAuth Working Group において、議長の Rifaat Shekh-Yusef と Hannes Tschofenig の下で、Security Area Directors として Paul Wouters と Roman Danyliw が務める形で策定されました。さらに、次の方々がアイデア、フィードバック、修正、文言の提案により本仕様の形成に貢献しました: Caleb Baker, Ivan Kanakarakis, Pieter Kasselman, Aaron Parecki, Denis Pinkas, Dima Postnikov, Filip Skokan。

本書の初期ドラフト版を生み出す動機や概念に関する初期の議論の一部は、2021 年の OAuth Security Workshop で行われました。著者らは、協働とコミュニティの意見収集に適したイベントを主催してくれたワークショップ運営者（Guido Schmitz, Steinar Noem, Daniel Fett）に感謝します。

Authors' Addresses

Vittorio Bertocci\ Auth0/Okta\ Email: vittorio@auth0.com

Brian Campbell\ Ping Identity\ Email: bcampbell@pingidentity.com