rfc9470.original   rfc9470.txt 
Web Authorization Protocol V. Bertocci Internet Engineering Task Force (IETF) V. Bertocci
Internet-Draft Auth0/Okta Request for Comments: 9470 Auth0/Okta
Intended status: Standards Track B. Campbell Category: Standards Track B. Campbell
Expires: 28 December 2023 Ping Identity ISSN: 2070-1721 Ping Identity
26 June 2023 August 2023
OAuth 2.0 Step-up Authentication Challenge Protocol OAuth 2.0 Step Up Authentication Challenge Protocol
draft-ietf-oauth-step-up-authn-challenge-17
Abstract Abstract
It is not uncommon for resource servers to require different It is not uncommon for resource servers to require different
authentication strengths or recentness according to the authentication strengths or recentness according to the
characteristics of a request. This document introduces a mechanism characteristics of a request. This document introduces a mechanism
for a resource server to signal to a client that the authentication that resource servers can use to signal to a client that the
event associated with the access token of the current request does authentication event associated with the access token of the current
not meet its authentication requirements and specify how to meet request does not meet its authentication requirements and, further,
them. This document also codifies a mechanism for a client to how to meet them. This document also codifies a mechanism for a
request that an authorization server achieve a specific client to request that an authorization server achieve a specific
authentication strength or recentness when processing an authentication strength or recentness when processing an
authorization request. authorization request.
Discussion Venues
This note is to be removed before publishing as an RFC.
Discussion of this document takes place on the Web Authorization
Protocol Working Group mailing list (oauth@ietf.org), which is
archived at https://mailarchive.ietf.org/arch/browse/oauth/.
Source for this draft can be found at https://github.com/oauth-wg/
oauth-step-up-authn-challenge.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is a product of the Internet Engineering Task Force
Task Force (IETF). Note that other groups may also distribute (IETF). It represents the consensus of the IETF community. It has
working documents as Internet-Drafts. The list of current Internet- received public review and has been approved for publication by the
Drafts is at https://datatracker.ietf.org/drafts/current/. Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Internet-Drafts are draft documents valid for a maximum of six months Information about the current status of this document, any errata,
and may be updated, replaced, or obsoleted by other documents at any and how to provide feedback on it may be obtained at
time. It is inappropriate to use Internet-Drafts as reference https://www.rfc-editor.org/info/rfc9470.
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 28 December 2023.
Copyright Notice Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
1.1. Conventions and Terminology . . . . . . . . . . . . . . . 3 1.1. Conventions and Terminology
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 2. Protocol Overview
3. Authentication Requirements Challenge . . . . . . . . . . . . 6 3. Authentication Requirements Challenge
4. Authorization Request . . . . . . . . . . . . . . . . . . . . 8 4. Authorization Request
5. Authorization Response . . . . . . . . . . . . . . . . . . . 8 5. Authorization Response
6. Authentication Information Conveyed via Access Token . . . . 9 6. Authentication Information Conveyed via Access Token
6.1. JWT Access Tokens . . . . . . . . . . . . . . . . . . . . 9 6.1. JWT Access Tokens
6.2. OAuth 2.0 Token Introspection . . . . . . . . . . . . . . 10 6.2. OAuth 2.0 Token Introspection
7. Authorization Server Metadata . . . . . . . . . . . . . . . . 11 7. Authorization Server Metadata
8. Deployment Considerations . . . . . . . . . . . . . . . . . . 11 8. Deployment Considerations
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. Security Considerations
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 10. IANA Considerations
10.1. OAuth Extensions Error Registration . . . . . . . . . . 13 10.1. OAuth Extensions Error Registration
10.2. OAuth Token Introspection Response Registration . . . . 13 10.2. OAuth Token Introspection Response Registration
11. Normative References . . . . . . . . . . . . . . . . . . . . 13 11. References
12. Informative References . . . . . . . . . . . . . . . . . . . 14 11.1. Normative References
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15 11.2. Informative References
Appendix B. Document History . . . . . . . . . . . . . . . . . . 15 Acknowledgements
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses
1. Introduction 1. Introduction
In simple API authorization scenarios, an authorization server will In simple API authorization scenarios, an authorization server will
determine what authentication technique to use to handle a given determine what authentication technique to use to handle a given
request on the basis of aspects such as the scopes requested, the request on the basis of aspects such as the scopes requested, the
resource, the identity of the client and other characteristics known resource, the identity of the client, and other characteristics known
at provisioning time. Although the approach is viable in many at provisioning time. Although that approach is viable in many
situations, it falls short in several important circumstances. situations, it falls short in several important circumstances.
Consider, for instance, an eCommerce API requiring different Consider, for instance, an eCommerce API requiring different
authentication strengths depending on whether the item being authentication strengths depending on whether the item being
purchased exceeds a certain threshold, dynamically estimated by the purchased exceeds a certain threshold, dynamically estimated by the
API itself using a logic that is opaque to the authorization server. API itself using a logic that is opaque to the authorization server.
An API might also determine that a more recent user authentication is An API might also determine that a more recent user authentication is
required based on its own risk evaluation of the API request. required based on its own risk evaluation of the API request.
This document extends the error codes collection defined by [RFC6750] This document extends the collection of error codes defined by
with a new value, insufficient_user_authentication, which can be used [RFC6750] with a new value, insufficient_user_authentication, which
by resource servers to signal to the client that the authentication can be used by resource servers to signal to the client that the
event associated with the access token presented with the request authentication event associated with the access token presented with
does not meet the authentication requirements of the resource server. the request does not meet the authentication requirements of the
This document also introduces acr_values and max_age parameters for resource server. This document also introduces acr_values and
the Bearer authentication scheme challenge defined by [RFC6750], max_age parameters for the Bearer authentication scheme challenge
which the resource server can use to explicitly communicate to the defined by [RFC6750]. The resource server can use these parameters
client the required authentication strength or recentness. to explicitly communicate to the client the required authentication
strength or recentness.
The client can use that information to reach back to the The client can use that information to reach back to the
authorization server with an authorization request specifying the authorization server with an authorization request that specifies the
authentication requirements indicated by protected resource, by authentication requirements indicated by the protected resource.
including the acr_values or max_age authorization request parameters This is accomplished by including the acr_values or max_age
as defined in [OIDC]. authorization request parameters as defined in [OIDC].
Those extensions will make it possible to implement interoperable Those extensions will make it possible to implement interoperable
step up authentication with minimal work from resource servers, step up authentication with minimal work from resource servers,
clients and authorization servers. clients, and authorization servers.
1.1. Conventions and Terminology 1.1. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
This specification uses the terms "access token", "authorization This specification uses the terms "access token", "authorization
server", "authorization endpoint", "authorization request", "client", server", "authorization endpoint", "authorization request", "client",
"protected resource", and "resource server" defined by The OAuth 2.0 "protected resource", and "resource server" defined by "The OAuth 2.0
Authorization Framework [RFC6749]. Authorization Framework" [RFC6749].
2. Protocol Overview 2. Protocol Overview
The following is an end-to-end sequence of a typical step-up The following is an end-to-end sequence of a typical step up
authentication scenario implemented according to this specification. authentication scenario implemented according to this specification.
The scenario assumes that, before the sequence described below takes The scenario assumes that, before the sequence described below takes
place, the client already obtained an access token for the protected place, the client already obtained an access token for the protected
resource. resource.
+----------+ +--------------+ +----------+ +--------------+
| | | | | | | |
| |-----------(1) request ------------------>| | | |-----------(1) request ------------------>| |
| | | | | | | |
| |<---------(2) challenge ------------------| Resource | | |<---------(2) challenge ------------------| Resource |
skipping to change at page 4, line 31 skipping to change at line 158
| | | User | | | | | | User | | |
| | | Agent |<-----------[...]------------>| Authorization | | | | Agent |<-----------[...]------------>| Authorization |
| | | | | Server | | | | | | Server |
| |<-| | | | | |<-| | | |
| | +-------+ | | | | +-------+ | |
| | | | | | | |
| |<-------- (4) access token --------------| | | |<-------- (4) access token --------------| |
| | | | | | | |
+----------+ +---------------+ +----------+ +---------------+
Figure 1: Abstract protocol flow Figure 1: Abstract Protocol Flow
1. The client requests a protected resource, presenting an access 1. The client requests a protected resource, presenting an access
token. token.
2. The resource server determines that the circumstances in which 2. The resource server determines that the circumstances in which
the presented access token was obtained offer insufficient the presented access token was obtained offer insufficient
authentication strength and/or recentness, hence it denies the authentication strength and/or recentness; hence, it denies the
request and returns a challenge describing (using a combination request and returns a challenge describing (using a combination
of acr_values and max_age) what authentication requirements must of acr_values and max_age) what authentication requirements must
be met for the resource server to authorize a request. be met for the resource server to authorize a request.
3. The client directs the user agent to the authorization server 3. The client directs the user agent to the authorization server
with an authorization request that includes the acr_values and/or with an authorization request that includes the acr_values and/or
max_age indicated by the resource server in the previous step. max_age indicated by the resource server in the previous step.
4. After whatever sequence required by the grant of choice plays 4. Whatever sequence required by the grant of choice plays out; this
out, which will include the necessary steps to authenticate the will include the necessary steps to authenticate the user in
user in accordance with the acr_values and/or max_age values of accordance with the acr_values and/or max_age values of the
the authorization request, the authorization server returns a new authorization request. Then, the authorization server returns a
access token to the client. The access token contains or new access token to the client. The new access token contains or
references information about the authentication event. references information about the authentication event.
5. The client repeats the request from step 1, presenting the newly 5. The client repeats the request from step 1, presenting the newly
obtained access token. obtained access token.
6. The resource server finds that the user authentication performed 6. The resource server finds that the user authentication performed
during the acquisition of the new access token complies with its during the acquisition of the new access token complies with its
requirements, and returns the representation of the requested requirements and returns the representation of the requested
protected resource. protected resource.
The validation operations mentioned in step 2 and 6 imply that the The validation operations mentioned in steps 2 and 6 imply that the
resource server has a way of evaluating the authentication that resource server has a way of evaluating the authentication that
occurred during the process by which the access token was obtained. occurred during the process by which the access token was obtained.
In the context of this document, the assessment by the resource In the context of this document, the assessment by the resource
server of the specific authentication method used to obtain a token server of the specific authentication method used to obtain a token
for the requested resource is called an "authentication level." This for the requested resource is called an "authentication level". This
document will describe how the resource server can perform this document will describe how the resource server can perform this
assessment of an "authentication level" when the access token is a assessment of an authentication level when the access token is a JSON
JWT Access token [RFC9068] or is validated via introspection Web Token (JWT) [RFC9068] or is validated via introspection
[RFC7662]. Other methods of determining the authentication level by [RFC7662]. Other methods of determining the authentication level by
which the access token was obtained are possible, per agreement by which the access token was obtained are possible, per agreement by
the authorization server and the protected resource, but are beyond the authorization server and the protected resource, but they are
the scope of this specification. Given an authentication level of a beyond the scope of this specification. Given an authentication
token, the resource server determines whether it meets the security level of a token, the resource server determines whether it meets the
criteria for the requested resource. security criteria for the requested resource.
"Authentication level" and "step-up" are metaphors in this The terms "authentication level" and "step up" are metaphors in this
specification. These metaphors do not suggest that there is an specification. These metaphors do not suggest that there is an
absolute hierarchy of authentication methods expressed in absolute hierarchy of authentication methods expressed in
interoperable fashion. The notion of a level emerges from the fact interoperable fashion. The notion of a level emerges from the fact
that the resource server may only want to accept certain that the resource server may only want to accept certain
authentication methods. When presented with a token derived from a authentication methods. When presented with a token derived from a
particular authentication method (i.e., a given authentication level) particular authentication method (i.e., a given authentication level)
that it does not want to accept (i.e., below the threshold or level that it does not want to accept (i.e., below the threshold or level
it will accept), the resource server seeks to "step-up" (i.e., it will accept), the resource server seeks to step up (i.e.,
renegotiate) from the current authentication level to one that it may renegotiate) from the current authentication level to one that it may
accept. The "step-up" metaphor is intended to convey a shift from accept. The "step up" metaphor is intended to convey a shift from
the original authentication level to one that is acceptable to the the original authentication level to one that is acceptable to the
resource server. resource server.
Although the case in which the new access token supersedes old tokens Although the case in which the new access token supersedes old tokens
by virtue of a higher authentication level is common, in line with by virtue of a higher authentication level is common, in line with
the intuition the term "step-up authentication" suggests, it is the connotation of the term "step up authentication", it is important
important to keep in mind that this might not necessarily hold true to keep in mind that this might not necessarily hold true in the
in the general case. For example: a resource server might require general case. For example, for a particular request, a resource
for a particular request a higher authentication level and a shorter server might require a higher authentication level and a shorter
validity, resulting in a token suitable for one-off calls but leading validity, resulting in a token suitable for one-off calls but leading
to frequent prompts, hence a suboptimal user experience, if reused to frequent prompts: hence, offering a suboptimal user experience if
for routine operations. In those scenarios, the client would be the token is reused for routine operations. In such a scenario, the
better served by keeping both the old tokens, associated with a lower client would be better served by keeping both the old tokens, which
authentication level, and the new one - selecting the appropriate are associated with a lower authentication level, and the new one:
token for each API call. This is not a new requirement for clients, selecting the appropriate token for each API call. This is not a new
as incremental consent and least privilege principles will require requirement for clients, as incremental consent and least-privilege
similar heuristics for managing access tokens associated to different principles will require similar heuristics for managing access tokens
scopes and permission levels. This document does not recommend any associated with different scopes and permission levels. This
specific token caching strategy, as that will be dependent on the document does not recommend any specific token-caching strategy: that
characteristics of every particular scenario and remains application- choice will be dependent on the characteristics of every particular
dependent as in the core OAuth cases. Also recall that OAuth 2.0 scenario and remains application-dependent as in the core OAuth
[RFC6749] assumes access tokens are treated as opaque by clients. cases. Also recall that OAuth 2.0 [RFC6749] assumes access tokens
The token format might be unreadable to the client or might change at are treated as opaque by clients. The token format might be
any time to become unreadable. So, during the course of any token unreadable to the client or might change at any time to become
caching strategy, a client must not attempt to inspect the content of unreadable. So, during the course of any token-caching strategy, a
the access token to determine the associated authentication client must not attempt to inspect the content of the access token to
information or other details (see Section 6 of [RFC9068] for a more determine the associated authentication information or other details
detailed discussion). (see Section 6 of [RFC9068] for a more detailed discussion).
3. Authentication Requirements Challenge 3. Authentication Requirements Challenge
This specification introduces a new error code value for the error This specification introduces a new error code value for the
parameter of the challenge of the Bearer authentication scheme from challenge of the Bearer authentication scheme's error parameter (from
[RFC6750] and other OAuth authentication schemes, such as [RFC6750]) and other OAuth authentication schemes, such as those seen
[I-D.ietf-oauth-dpop], which use the same error parameter: in [RFC9449], which use the same error parameter:
insufficient_user_authentication The authentication event associated insufficient_user_authentication: The authentication event
with the access token presented with the request does not meet the associated with the access token presented with the request does
authentication requirements of the protected resource. not meet the authentication requirements of the protected
resource.
Note: the logic through which the resource server determines that the Note: the logic through which the resource server determines that the
current request does not meet the authentication requirements of the current request does not meet the authentication requirements of the
protected resource, and associated functionality (such as expressing, protected resource, and associated functionality (such as expressing,
deploying and publishing such requirements) is out of scope for this deploying and publishing such requirements), is out of scope for this
document. document.
Furthermore, this specification defines the following WWW- Furthermore, this specification defines the following WWW-
Authenticate auth-param values for those OAuth authentication schemes Authenticate auth-param values for those OAuth authentication schemes
to convey the authentication requirements back to the client. to convey the authentication requirements back to the client.
acr_values A space-separated string listing the authentication acr_values: A space-separated string listing the authentication
context class reference values, in order of preference, one of context class reference values in order of preference. The
which the protected resource requires for the authentication event protected resource requires one of these values for the
associated with the access token. The authentication context, as authentication event associated with the access token. As defined
defined in section 1.2 of [OIDC] conveys information about how in Section 1.2 of [OIDC], the authentication context conveys
authentication takes place (e.g., what authentication method(s) or information about how authentication takes place (e.g., what
assurance level to meet). authentication method(s) or assurance level to meet).
max_age Indicates the allowable elapsed time in seconds since the max_age: This value indicates the allowable elapsed time in seconds
last active authentication event associated with the access token. since the last active authentication event associated with the
An active authentication event entails a user interacting with the access token. An active authentication event entails a user
authorization server in response to an authentication prompt. interacting with the authorization server in response to an
Note that while the auth-param value can be conveyed as a token or authentication prompt. Note that, while the auth-param value can
quoted-string (see section 11.2 of [RFC9110]), it has to represent be conveyed as a token or quoted-string (see Section 11.2 of
a non-negative integer. [RFC9110]), it has to represent a non-negative integer.
Figure 2 below is an example of a Bearer authentication scheme Figure 2 is an example of a Bearer authentication scheme challenge
challenge with the WWW-Authenticate header using the with the WWW-Authenticate header using:
insufficient_user_authentication error code value to inform the
client that the access token presented is not sufficient to gain * the insufficient_user_authentication error code value to inform
access to the protected resource, and the acr_values parameter to let the client that the access token presented is not sufficient to
the client know that the expected authentication level corresponds to gain access to the protected resource, and
the authentication context class reference identified by myACR.
* the acr_values parameter to let the client know that the expected
authentication level corresponds to the authentication context
class reference identified by myACR.
Note that while this specification only defines usage of the above Note that while this specification only defines usage of the above
auth-params with the insufficient_user_authentication error code, it auth-params with the insufficient_user_authentication error code, it
does not preclude future specifications or profiles from defining does not preclude future specifications or profiles from defining
their usage with other error codes. their usage with other error codes.
HTTP/1.1 401 Unauthorized HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer error="insufficient_user_authentication", WWW-Authenticate: Bearer error="insufficient_user_authentication",
error_description="A different authentication level is required", error_description="A different authentication level is required",
acr_values="myACR" acr_values="myACR"
Figure 2: Authentication Requirements Challenge indicating acr_values Figure 2: Authentication Requirements Challenge Indicating acr_values
The following example in Figure 3 shows a challenge informing the The example in Figure 3 shows a challenge informing the client that
client that last active authentication event associated with the the last active authentication event associated with the presented
presented access token is too old and a more recent authentication is access token is too old and a more recent authentication is needed.
needed.
HTTP/1.1 401 Unauthorized HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer error="insufficient_user_authentication", WWW-Authenticate: Bearer error="insufficient_user_authentication",
error_description="More recent authentication is required", error_description="More recent authentication is required",
max_age="5" max_age="5"
Figure 3: Authentication Requirements Challenge indicating max_age Figure 3: Authentication Requirements Challenge Indicating max_age
The auth-params max_age and acr_values MAY both occur in the same The auth-params max_age and acr_values MAY both occur in the same
challenge if the resource server needs to express requirements both challenge if the resource server needs to express requirements about
about recency and authentication levels. If the resource server both recency and authentication level. If the resource server
determines that the request is also lacking the scopes required by determines that the request is also lacking the scopes required by
the requested resource, it MAY include the scope attribute with the the requested resource, it MAY include the scope attribute with the
scope necessary to access the protected resource, as described in value necessary to access the protected resource, as described in
section 3.1 of [RFC6750]. Section 3.1 of [RFC6750].
4. Authorization Request 4. Authorization Request
A client receiving a challenge from the resource server carrying the A client receiving a challenge from the resource server carrying the
error code insufficient_user_authentication SHOULD parse the WWW- insufficient_user_authentication error code SHOULD parse the WWW-
Authenticate header for acr_values and max_age and use them, if Authenticate header for acr_values and max_age and use them, if
present, in constructing an authorization request, which is then present, in constructing an authorization request. This request is
conveyed to the authorization server's authorization endpoint via the then conveyed to the authorization server's authorization endpoint
user agent in order to obtain a new access token complying with the via the user agent in order to obtain a new access token complying
corresponding requirements. Both acr_values and max_age with the corresponding requirements. The acr_values and max_age
authorization request parameters are OPTIONAL parameters defined in authorization request parameters are both OPTIONAL parameters defined
Section 3.1.2.1. of [OIDC]. This document does not introduce any in Section 3.1.2.1. of [OIDC]. This document does not introduce any
changes in the authorization server behavior defined in [OIDC] for changes in the authorization server behavior defined in [OIDC] for
processing those parameters, hence any authorization server processing those parameters; hence, any authorization server
implementing OpenID Connect will be able to participate in the flow implementing OpenID Connect will be able to participate in the flow
described here with little or no changes. See Section 5 for more described here with little or no changes. See Section 5 for more
details. details.
The example authorization request URI below, which might be used The example authorization request URI below, which might be used
after receiving the challenge in Figure 2, indicates to the after receiving the challenge in Figure 2, indicates to the
authorization server that the client would like the authentication to authorization server that the client would like the authentication to
occur according to the authentication context class reference occur according to the authentication context class reference
identified by myACR. identified by myACR.
https://as.example.net/authorize?client_id=s6BhdRkqt3 https://as.example.net/authorize?client_id=s6BhdRkqt3
&response_type=code&scope=purchase&acr_values=myACR &response_type=code&scope=purchase&acr_values=myACR
Figure 4: Authorization Request indicating acr_values Figure 4: Authorization Request Indicating acr_values
After the challenge in Figure 3, a client might direct the user agent After the challenge in Figure 3, a client might direct the user agent
to the following example authorization request URI where the max_age to the following example authorization request URI where the max_age
parameter indicates to the authorization server that the user parameter indicates to the authorization server that the user-
authentication event needs to have occurred no more than five seconds authentication event needs to have occurred no more than five seconds
prior. prior.
https://as.example.net/authorize?client_id=s6BhdRkqt3 https://as.example.net/authorize?client_id=s6BhdRkqt3
&response_type=code&scope=purchase&max_age=5 &response_type=code&scope=purchase&max_age=5
Figure 5: Authorization Request indicating max_age Figure 5: Authorization Request Indicating max_age
5. Authorization Response 5. Authorization Response
Section 5.5.1.1 of [OIDC] establishes that an authorization server Section 5.5.1.1 of [OIDC] establishes that an authorization server
receiving a request containing the acr_values parameter MAY attempt receiving a request containing the acr_values parameter MAY attempt
to authenticate the user in a manner that satisfies the requested to authenticate the user in a manner that satisfies the requested
Authentication Context Class Reference, and include the corresponding authentication context class reference and include the corresponding
value in the acr claim in the resulting ID Token. The same section value in the acr claim in the resulting ID Token. The same section
also establishes that in case the desired authentication level cannot also establishes that, in case the desired authentication level
be met, the authorization server SHOULD include in the acr claim a cannot be met, the authorization server SHOULD include a value
value reflecting the authentication level of the current session (if reflecting the authentication level of the current session (if any)
any). Furthermore, Section 3.1.2.1 [OIDC] states that if a request in the acr claim. Furthermore, Section 3.1.2.1 [OIDC] states that if
includes the max_age parameter, the authorization server MUST include a request includes the max_age parameter, the authorization server
the auth_time claim in the issued ID Token. An authorization server MUST include the auth_time claim in the issued ID Token. An
complying with this specification will react to the presence of the authorization server complying with this specification will react to
acr_values and max_age parameters by including acr and auth_time in the presence of the acr_values and max_age parameters by including
the access token (see Section 6 for details). Although [OIDC] leaves acr and auth_time in the access token (see Section 6 for details).
the authorization server free to decide how to handle the inclusion Although [OIDC] leaves the authorization server free to decide how to
of acr in the ID Token when requested via acr_values, when it comes handle the inclusion of acr in the ID Token when requested via
to access tokens in this specification, the authorization server acr_values, when it comes to access tokens in this specification, the
SHOULD consider the requested acr value as necessary for successfully authorization server SHOULD consider the requested acr value as
fulfilling the request. That is, the requested acr value is included necessary for successfully fulfilling the request. That is, the
in the access token if the authentication operation successfully met requested acr value is included in the access token if the
its requirements, or that the authorization request fails in all authentication operation successfully met its requirements;
other cases, returning unmet_authentication_requirements as defined otherwise, the authorization request fails and returns an
in [OIDCUAR]. The recommended behavior will help prevent clients unmet_authentication_requirements error as defined in [OIDCUAR]. The
getting stuck in a loop where the authorization server keeps recommended behavior will help prevent clients getting stuck in a
returning tokens that the resource server already identified as not loop where the authorization server keeps returning tokens that the
meeting its requirements hence known to be rejected as well. resource server already identified as not meeting its requirements.
6. Authentication Information Conveyed via Access Token 6. Authentication Information Conveyed via Access Token
To evaluate whether an access token meets the protected resource's To evaluate whether an access token meets the protected resource's
requirements, the resource server needs a way of accessing requirements, the resource server needs a way of accessing
information about the authentication event by which that access token information about the authentication event by which that access token
was obtained. This specification provides guidance on how to convey was obtained. This specification provides guidance on how to convey
that information in conjunction with two common access token that information in conjunction with two common access-token-
validation methods: the one described in [RFC9068], where the access validation methods:
token is encoded in JWT format and verified via a set of validation
rules, and the one described in [RFC7662], where the token is * the one described in [RFC9068], where the access token is encoded
validated and decoded by sending it to an introspection endpoint. in JWT format and verified via a set of validation rules, and
* the one described in [RFC7662], where the token is validated and
decoded by sending it to an introspection endpoint.
Authorization servers and resource servers MAY elect to use other Authorization servers and resource servers MAY elect to use other
encoding and validation methods, however those are out of scope for encoding and validation methods; however, those are out of scope for
this document. this document.
6.1. JWT Access Tokens 6.1. JWT Access Tokens
When access tokens are represented as JSON Web Tokens (JWT) When access tokens are represented as JSON Web Tokens (JWTs)
[RFC7519], the auth_time and acr claims (per Section 2.2.1 of [RFC7519], the auth_time and acr claims (per Section 2.2.1 of
[RFC9068]) are used to convey the time and context of the user [RFC9068]) are used to convey the time and context of the user-
authentication event that the authentication server performed during authentication event that the authentication server performed during
the course of obtaining the access token. It is useful to bear in the course of obtaining the access token. It is useful to bear in
mind that the values of those two parameters are established at user mind that the values of those two parameters are established at user-
authentication time and will not change in the event of access token authentication time and will not change in the event of access token
renewals. See the aforementioned Section 2.2.1 of [RFC9068] for renewals. See the aforementioned Section 2.2.1 of [RFC9068] for
details. The following is a conceptual example showing the decoded details. The following is a conceptual example showing the decoded
content of such a JWT access token. content of such a JWT access token.
Header: Header:
{"typ":"at+JWT","alg":"ES256","kid":"LTacESbw"} {"typ":"at+JWT","alg":"ES256","kid":"LTacESbw"}
Claims: Claims:
skipping to change at page 10, line 24 skipping to change at line 444
"aud": "https://rs.example.com", "aud": "https://rs.example.com",
"exp": 1646343000, "exp": 1646343000,
"iat": 1646340200, "iat": 1646340200,
"jti" : "e1j3V_bKic8-LAEB_lccD0G", "jti" : "e1j3V_bKic8-LAEB_lccD0G",
"client_id": "s6BhdRkqt3", "client_id": "s6BhdRkqt3",
"scope": "purchase", "scope": "purchase",
"auth_time": 1646340198, "auth_time": 1646340198,
"acr": "myACR" "acr": "myACR"
} }
Figure 6 Figure 6: Decoded JWT Access Token
6.2. OAuth 2.0 Token Introspection 6.2. OAuth 2.0 Token Introspection
OAuth 2.0 Token Introspection [RFC7662] defines a method for a "OAuth 2.0 Token Introspection" [RFC7662] defines a method for a
protected resource to query an authorization server about the active protected resource to query an authorization server about the active
state of an access token as well as to determine metainformation state of an access token as well as to determine metainformation
about the token. The following two top-level introspection response about the token. The following two top-level introspection response
members are defined to convey information about the user members are defined to convey information about the user-
authentication event that the authentication server performed during authentication event that the authentication server performed during
the course of obtaining the access token. the course of obtaining the access token.
acr Authentication Context Class Reference. String specifying an acr: String specifying an authentication context class reference
Authentication Context Class Reference value that identifies the value that identifies the authentication context class that was
Authentication Context Class that the user authentication satisfied by the user-authentication event performed.
performed satisfied.
auth_time Time when the user authentication occurred. A JSON auth_time: Time when the user authentication occurred. A JSON
numeric value representing the number of seconds from numeric value representing the number of seconds from
1970-01-01T00:00:00Z UTC until the time of date/time of the 1970-01-01T00:00:00Z UTC until the date/time of the authentication
authentication event. event.
The following example shows an introspection response with The following example shows an introspection response with
information about the user authentication event by which the access information about the user-authentication event by which the access
token was obtained. token was obtained.
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: application/json Content-Type: application/json
{ {
"active": true, "active": true,
"client_id": "s6BhdRkqt3", "client_id": "s6BhdRkqt3",
"scope": "purchase", "scope": "purchase",
"sub": "someone@example.net", "sub": "someone@example.net",
"aud": "https://rs.example.com", "aud": "https://rs.example.com",
"iss": "https://as.example.net", "iss": "https://as.example.net",
"exp": 1639528912, "exp": 1639528912,
"iat": 1618354090, "iat": 1618354090,
"auth_time": 1646340198, "auth_time": 1646340198,
"acr": "myACR" "acr": "myACR"
} }
Figure 7 Figure 7: Introspection Response
7. Authorization Server Metadata 7. Authorization Server Metadata
Authorization Servers can advertise their support of this Authorization servers can advertise their support of this
specification by including in their metadata document (as defined in specification by including in their metadata document, as defined in
[RFC8414]) the value acr_values_supported as defined in section 3 of [RFC8414], the value acr_values_supported, as defined in Section 3 of
[OIDCDISC]. The presence of acr_values_supported in the [OIDCDISC]. The presence of acr_values_supported in the
authorization server metadata document signals that the authorization authorization server metadata document signals that the authorization
server will understand and honor the acr_values and max_age server will understand and honor the acr_values and max_age
parameters in incoming authorization requests. parameters in incoming authorization requests.
8. Deployment Considerations 8. Deployment Considerations
This specification facilitates the communication of requirements from This specification facilitates the communication of requirements from
a resource server to a client, which in turn can enable a smooth a resource server to a client, which, in turn, can enable a smooth
step-up authentication experience. However, it is important to step up authentication experience. However, it is important to
realize that the user experience achievable in every specific realize that the user experience achievable in every specific
deployment is a function of the policies each resource server and deployment is a function of the policies each resource server and
authorization server pairs establish. Imposing constraints on those authorization server pair establishes. Imposing constraints on those
policies is out of scope for this specification, hence it is policies is out of scope for this specification; hence, it is
perfectly possible for resource servers and authorization servers to perfectly possible for resource servers and authorization servers to
impose requirements that are impossible for users to comply with, or impose requirements that are impossible for users to comply with or
leading to an undesirable user experience outcome. The that lead to an undesirable user-experience outcome. The
authentication prompts presented by the authorization server as a authentication prompts presented by the authorization server as a
result of the method of propagating authentication requirements result of the method of propagating authentication requirements
described here might require the user to perform some specific described here might require the user to perform some specific
actions such as using multiple devices, having access to devices actions such as using multiple devices, having access to devices
complying with specific security requirements, and so on. Those complying with specific security requirements, and so on. Those
extra requirements, concerning more about how to comply with a extra requirements, that are more concerned with how to comply with a
particular requirement rather than indicating the identifier of the particular requirement rather than indicating the identifier of the
requirement itself, are out of scope for this specification. requirement itself, are out of scope for this specification.
9. Security Considerations 9. Security Considerations
This specification adds to previously defined OAuth mechanisms. This specification adds to previously defined OAuth mechanisms.
Their respective Security Considerations apply - OAuth 2.0 [RFC6749], Their respective security considerations apply:
JWT access tokens [RFC9068], Bearer WWW-Authentication [RFC6750],
token introspection [RFC7662], and authorization server metadata * OAuth 2.0 [RFC6749],
[RFC8414].
* JWT access tokens [RFC9068],
* Bearer WWW-Authenticate [RFC6750],
* token introspection [RFC7662], and
* authorization server metadata [RFC8414].
This document MUST NOT be used to position OAuth as an authentication This document MUST NOT be used to position OAuth as an authentication
protocol. For the purposes of this specification, the way in which a protocol. For the purposes of this specification, the way in which a
user authenticated with the authorization server to obtain an access user authenticated with the authorization server to obtain an access
token is salient information, as a resource server might decide token is salient information, as a resource server might decide
whether to grant access on the basis of how that authentication whether to grant access on the basis of how that authentication
operation was performed. Nonetheless, this specification does not operation was performed. Nonetheless, this specification does not
attempt to define the mechanics by which authentication takes place, attempt to define the mechanics by which authentication takes place,
relying on a separate authentication layer to take care of the relying on a separate authentication layer to take care of the
details. In line with other specifications of the OAuth family, this details. In line with other specifications of the OAuth family, this
document assumes the existence of a session without going into the document assumes the existence of a session without going into the
details of how it is established or maintained, what protocols are details of how it is established or maintained, what protocols are
used to implement that layer (e.g., OpenID Connect), and so forth. used to implement that layer (e.g., OpenID Connect), and so forth.
Depending on the policies adopted by the resource server, the Depending on the policies adopted by the resource server, the
acr_values parameter introduced in Section 3 might unintentionally acr_values parameter introduced in Section 3 might unintentionally
disclose information about the authenticated user, the resource disclose information about the authenticated user, the resource
itself, the authorization server, and any other context-specific data itself, the authorization server, and any other context-specific data
that an attacker might use to gain knowledge about their target. For that an attacker might use to gain knowledge about their target. For
example, a resource server requesting an acr value corresponding to a example, a resource server requesting an acr value corresponding to a
high level of assurance for some users but not others might identify high level of assurance for some users but not others might identify
possible high privilege users to target with spearhead phishing possible high-privilege users to target with spearhead phishing
attacks. Implementers should use care in determining what to attacks. Implementers should use care in determining what to
disclose in the challenge and in what circumstances. The logic disclose in the challenge and in what circumstances. The logic
examining the incoming access token to determine whether a challenge examining the incoming access token to determine whether or not a
should be returned can execute either before or after the challenge should be returned can be executed either before or after
conventional token validation logic, be it based on JWT token the conventional token-validation logic, be it based on JWT
validation, introspection, or any other method. The resource server validation, introspection, or any other method. The resource server
MAY return a challenge without verifying the client presented a valid MAY return a challenge without verifying the client presented a valid
token. However, this approach will leak the required properties of token. However, this approach will leak the required properties of
an authorization token to an actor who has not proven they can obtain an authorization token to an actor who has not proven they can obtain
a token for this resource server. a token for this resource server.
As this specification provides a mechanism for the resource server to As this specification provides a mechanism for the resource server to
trigger user interaction, it's important for the authorization server trigger user interaction, it's important for the authorization server
and clients to consider that a malicious resource server might abuse and clients to consider that a malicious resource server might abuse
of that feature. that feature.
10. IANA Considerations 10. IANA Considerations
10.1. OAuth Extensions Error Registration
This specification requests registration of the following error value
in the "OAuth Extensions Error" registry [IANA.OAuth.Params]
established by [RFC6749].
* Name: insufficient_user_authentication 10.1. OAuth Extensions Error Registration
* Usage Location: resource access error response This specification registers the following error value in the "OAuth
Extensions Error Registry" [IANA.OAuth.Params] established by
[RFC6749].
* Protocol Extension: OAuth 2.0 Step-up Authentication Challenge Name: insufficient_user_authentication
Usage Location: resource access error response
Protocol Extension: OAuth 2.0 Step Up Authentication Challenge
Protocol Protocol
Change controller: IETF
* Change controller: IETF Specification document(s): Section 3 of RFC 9470
* Specification document(s): Section 3 of [[ this specification ]]
10.2. OAuth Token Introspection Response Registration 10.2. OAuth Token Introspection Response Registration
This specification requests registration of the following values in This specification registers the following values in the "OAuth Token
the "OAuth Token Introspection Response" registry [IANA.OAuth.Params] Introspection Response" registry [IANA.OAuth.Params] established by
established by [RFC7662]. [RFC7662].
Authentication Context Class Reference: Authentication Context Class Reference:
* Name: acr Name: acr
Description: Authentication Context Class Reference
* Description: Authentication Context Class Reference Change Controller: IETF
Specification Document(s): Section 6.2 of RFC 9470
* Change Controller: IETF
* Specification Document(s): Section 6.2 of [[ this specification ]]
Authentication Time: Authentication Time:
* Name: auth_time Name: auth_time
Description: Time when the user authentication occurred
* Description: Time when the user authentication occurred Change Controller: IETF
Specification Document(s): Section 6.2 of RFC 9470
* Change Controller: IETF
* Specification Document(s): Section 6.2 of [[ this specification ]] 11. References
11. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012, RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/info/rfc6749>. <https://www.rfc-editor.org/info/rfc6749>.
[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
Framework: Bearer Token Usage", RFC 6750, Framework: Bearer Token Usage", RFC 6750,
DOI 10.17487/RFC6750, October 2012, DOI 10.17487/RFC6750, October 2012,
<https://www.rfc-editor.org/info/rfc6750>. <https://www.rfc-editor.org/info/rfc6750>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
12. Informative References 11.2. Informative References
[I-D.ietf-oauth-dpop]
Fett, D., Campbell, B., Bradley, J., Lodderstedt, T.,
Jones, M. B., and D. Waite, "OAuth 2.0 Demonstrating
Proof-of-Possession at the Application Layer (DPoP)", Work
in Progress, Internet-Draft, draft-ietf-oauth-dpop-16, 13
April 2023, <https://datatracker.ietf.org/doc/html/draft-
ietf-oauth-dpop-16>.
[IANA.OAuth.Params] [IANA.OAuth.Params]
IANA, "OAuth Parameters", IANA, "OAuth Parameters",
<https://www.iana.org/assignments/oauth-parameters>. <https://www.iana.org/assignments/oauth-parameters>.
[OIDC] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and [OIDC] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and
C. Mortimore, "OpenID Connect Core 1.0 incorporating C. Mortimore, "OpenID Connect Core 1.0 incorporating
errata set 1", 8 November 2014, errata set 1", 8 November 2014,
<https://openid.net/specs/openid-connect-core-1_0.html>. <https://openid.net/specs/openid-connect-core-1_0.html>.
[OIDCDISC] Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID [OIDCDISC] Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID
Connect Core 1.0 incorporating errata set 1", 8 November Connect Discovery 1.0 incorporating errata set 1", 8
2014, <https://openid.net/specs/openid-connect-discovery- November 2014, <https://openid.net/specs/openid-connect-
1_0.html>. discovery-1_0.html>.
[OIDCUAR] Lodderstedt, T., "OpenID Connect Core Error Code [OIDCUAR] Lodderstedt, T., "OpenID Connect Core Error Code
unmet_authentication_requirements", 8 May 2019, unmet_authentication_requirements", 8 May 2019,
<https://openid.net/specs/openid-connect-unmet- <https://openid.net/specs/openid-connect-unmet-
authentication-requirements-1_0.html>. authentication-requirements-1_0.html>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>. <https://www.rfc-editor.org/info/rfc7519>.
skipping to change at page 15, line 27 skipping to change at line 669
[RFC9068] Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0 [RFC9068] Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0
Access Tokens", RFC 9068, DOI 10.17487/RFC9068, October Access Tokens", RFC 9068, DOI 10.17487/RFC9068, October
2021, <https://www.rfc-editor.org/info/rfc9068>. 2021, <https://www.rfc-editor.org/info/rfc9068>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110, Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022, DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>. <https://www.rfc-editor.org/info/rfc9110>.
Appendix A. Acknowledgements [RFC9449] Fett, D., Campbell, B., Bradley, J., Lodderstedt, T.,
Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of
Possession at the Application Layer (DPoP)", RFC 9449,
DOI 10.17487/RFC9449, August 2023,
<https://www.rfc-editor.org/info/rfc9449>.
Acknowledgements
I wanted to thank the Academy, the viewers at home, the shampoo I wanted to thank the Academy, the viewers at home, the shampoo
manufacturers, etc.. manufacturers, etc.
This specification was developed within the OAuth Working Group under This specification was developed within the OAuth Working Group under
the chairpersonship of Rifaat Shekh-Yusef and Hannes Tschofenig with the chairpersonship of Rifaat Shekh-Yusef and Hannes Tschofenig with
Paul Wouters, and Roman Danyliw serving as Security Area Directors. Paul Wouters and Roman Danyliw serving as Security Area Directors.
Additionally, the following individuals contributed ideas, feedback, Additionally, the following individuals contributed ideas, feedback,
corrections, and wording that helped shape this specification: Caleb corrections, and wording that helped shape this specification: Caleb
Baker, Ivan Kanakarakis, Pieter Kasselman, Aaron Parecki, Denis Baker, Ivan Kanakarakis, Pieter Kasselman, Aaron Parecki, Denis
Pinkas, Dima Postnikov, and Filip Skokan. Pinkas, Dima Postnikov, and Filip Skokan.
Some early discussion of the motivations and concepts that Some early discussion of the motivations and concepts that
precipitated the initial version of this document occurred at the precipitated the initial draft version of this document occurred at
2021 OAuth Security Workshop. The authors thank the organizers of the 2021 OAuth Security Workshop. The authors thank the organizers
the workshop (Guido Schmitz, Steinar Noem, and Daniel Fett) for of the workshop (Guido Schmitz, Steinar Noem, and Daniel Fett) for
hosting an event that is conducive to collaboration and community hosting an event that is conducive to collaboration and community
input. input.
Appendix B. Document History
[[ To be removed from the final specification ]]
-17
* Fix mistake in -16 update
-16
* AD suggested editorial updates
-15
* Editorial updates from IESG review/ballot
-14
* Updates from Httpdir telechat review
-13
* Make IETF the Change Controller for all registration requests per
IANA suggestion
* More updates from Genart review
* Updates from Artart review
* Updates from Secdir review
-12
* Updates from Genart Last Call review
-11
* Updates in the Protocol Overview section clarifying the nature of
"authentication levels" and caching strategies, addressing AD
review comments
-10
* Fix two references where the section numbers got lost presumably
due to tooling issues
-09
* Updates addressing AD review comments
-07/-08
* Editorial updates addressing Shepherd Review comments
-06
* Update examples/figures to be clear that the authorization request
is sent by the client via directing the user agent (not directly
from client to AS)
-05
* Forgotten Acknowledgements
* Minor updates to the updates in -04
-04
* Editorial updates/notes from WGLC feedback
-03
* Clarified that acr_values and max_age can co-occur in the
challenge when necessary
* fleshed out deployment and security considerations
* fleshed out IANA considerations
* Attempt to clarify that while acr_values can request more than one
value, only one of them is used and ends up in the token
-02
* Fix typos introduced in -01
* Begin to fill out the Acknowledgements
-01
* Added AS Metadata section with pointer to acr_values_supported
* Mention that it's not necessarily the case that a new 'stepped-up'
token always supersedes older tokens
* Add examples with max_age
-00 (Working Group Draft)
* Initial WG revision (content unchanged from draft-bertocci-oauth-
step-up-authn-challenge-01)
-01 draft-bertocci-oauth-step-up-authn-challenge
* Fixed example
* Clarified/noted that scope can also be in the WWW-Authenticate/401
-00 draft-bertocci-oauth-step-up-authn-challenge
* Initial Individual Draft (with all the authority thereby bestowed
https://datatracker.ietf.org/doc/html/draft-abr-twitter-reply
(https://datatracker.ietf.org/doc/html/draft-abr-twitter-reply)).
Authors' Addresses Authors' Addresses
Vittorio Bertocci Vittorio Bertocci
Auth0/Okta Auth0/Okta
Email: vittorio@auth0.com Email: vittorio@auth0.com
Brian Campbell Brian Campbell
Ping Identity Ping Identity
Email: bcampbell@pingidentity.com Email: bcampbell@pingidentity.com
 End of changes. 87 change blocks. 
394 lines changed or deleted 274 lines changed or added

This html diff was produced by rfcdiff 1.48.