OAuth 2.0 for First-Party Applications

1.1. Usage and Applicability

This specification MUST only be used by first-party applications, which is when the authorization server and application are controlled by the same entity and the user understands them both as the same entity.¶

This specification MUST NOT be used by third party applications, and the authorization server SHOULD take measures to prevent use by third party applications. (e.g. only enable this grant for certain client IDs, and take measures to authenticate first-party apps when possible.)¶

Using this specification in scenarios other than those described will lead to unintended security and privacy problems for users and service providers.¶

This specification is designed to be used by first-party native applications, which includes both mobile and desktop applications.¶

If you provide multiple apps and expect users to use multiple apps on the same device, there may be better ways of sharing a user's login between the apps other than each app implementing this specification or using an SDK that implements this specification. For example, [OpenID.Native-SSO] provides a mechanism for one app to obtain new tokens by exchanging tokens from another app, without any user interaction. See Section 9.7 for more details.¶

1.2. Limitations of this specification

The scope of this specification is limited to first-party applications. Please review the entirety of Section 9, and when more than one first-party application is supported, Section 9.7.¶

While this draft provides the framework for a native OAuth experience, each implementation will need to define the specific behavior that it expects from OAuth clients interacting with the authorization server. While this lack of clearly defining the details would typically lead to less interoperability, it is acceptable in this case since we intend this specification to be deployed in a tightly coupled environment since it is only applicable to first-party applications.¶

1.3. User Experience Considerations

It is important to consider the user experience implications of different authentication challenges as well as the device with which the user is attempting to authorize.¶

For example, requesting a user to enter a password on a limited-input device (e.g. TV) creates a lot of user friction while also exposing the user's password to anyone else in the room. On the other hand, using a challenge method that involves, for example, a fingerprint reader on the TV remote allowing for a FIDO2 passkey authentication would be a good experience.¶

The Authorization Server SHOULD consider the user's device when presenting authentication challenges and developers SHOULD consider whether the device implementing this specification can provide a good experience for the user. If the combination of user device and authentication challenge methods creates a lot of friction or security risk, consider using a specification like OAuth 2.0 Device Authorization Grant [RFC8628]. If selecting OAuth 2.0 Device Authorization Grant [RFC8628] which uses a cross-device authorization mechanism, please incorporate the security best practices identified in Cross-Device Flows: Security Best Current Practice [I-D.ietf-oauth-cross-device-security].¶

2.1. Terminology

This specification uses the terms "Access Token", "Authorization Code", "Authorization Endpoint", "Authorization Server" (AS), "Client", "Client Authentication", "Client Identifier", "Client Secret", "Grant Type", "Protected Resource", "Redirection URI", "Refresh Token", "Resource Owner", "Resource Server" (RS) and "Token Endpoint" defined by [RFC6749].¶

TODO: Replace RFC6749 references with OAuth 2.1¶

3.1. Initial Authorization Request

                                                +-------------------+
                                                |   Authorization   |
                          (B)Authorization      |      Server       |
             +----------+    Challenge Request  |+-----------------+|
(A)Client+---|  First-  |---------------------->||  Authorization  ||
   Starts|   |  Party   |                       ||   Challenge     ||
   Flow  +-->|  Client  |<----------------------||    Endpoint     ||
             |          | (C)Authorization      ||                 ||
             |          |    Error Response     ||                 ||
             |          |         :             ||                 ||
             |          |         :             ||                 ||
             |          | (D)Authorization      ||                 ||
             |          |    Challenge Request  ||                 ||
             |          |---------------------->||                 ||
             |          |                       ||                 ||
             |          |<----------------------||                 ||
             |          | (E) Authorization     |+-----------------+|
             |          |     Code Response     |                   |
             |          |                       |                   |
             |          |                       |                   |
             |          |                       |                   |
             |          | (F) Token             |                   |
             |          |     Request           |+-----------------+|
             |          |---------------------->||      Token      ||
             |          |                       ||     Endpoint    ||
             |          |<----------------------||                 ||
             |          | (G) Access Token      |+-----------------+|
             |          |                       |                   |
             +----------+                       +-------------------+

Figure: First-Party Client Authorization Code Request¶

• (A) The first-party client starts the flow, by presenting the user with a "sign in" button, or collecting information from the user, such as their email address or username.¶

• (B) The client initiates the authorization request by making a POST request to the Authorization Challenge Endpoint, optionally with information collected from the user (e.g. email or username)¶

• (C) The authorization server determines whether the information provided to the Authorization Challenge Endpoint is sufficient to grant authorization, and either responds with an authorization code or responds with an error. In this example, it determines that additional information is needed and responds with an error. The error may contain additional information to guide the Client on what information to collect next. This pattern of collecting information, submitting it to the Authorization Challenge Endpoint and then receiving an error or authorization code may repeat several times.¶

• (D) The client gathers additional information (e.g. signed passkey challenge, or one-time code from email) and makes a POST request to the Authorization Challenge Endpoint.¶

• (E) The Authorization Challenge Endpoint returns an authorization code.¶

• (F) The client sends the authorization code received in step (E) to obtain a token from the Token Endpoint.¶

• (G) The Authorization Server returns an Access Token from the Token Endpoint.¶

3.2. Refresh Token Request

When the client uses a refresh token to obtain a new access token, the authorization server MAY respond with an error to indicate that re-authorization of the user is required.¶

3.3. Resource Request

When making a resource request to a resource server, the resource server MAY respond with an error according to OAuth 2.0 Step-Up Authentication Challenge Protocol [RFC9470], indicating that re-authorization of the user is required.¶

4.1. Authorization Challenge Endpoint

The authorization challenge endpoint is a new endpoint defined by this specification which the first-party application uses to obtain an authorization code.¶

The authorization challenge endpoint is an HTTP API at the authorization server that accepts HTTP POST requests with parameters in the HTTP request message body using the application/x-www-form-urlencoded format. This format has a character encoding of UTF-8, as described in Appendix B of [RFC6749]. The authorization challenge endpoint URL MUST use the "https" scheme.¶

If the authorization server requires client authentication for this client on the Token Endpoint, then the authorization server MUST also require client authentication for this client on the Authorization Challenge Endpoint. See Section 9.4 for more details.¶

Authorization servers supporting this specification SHOULD include the URL of their authorization challenge endpoint in their authorization server metadata document [RFC8414] using the authorization_challenge_endpoint parameter as defined in Section 8.¶

The endpoint accepts the authorization request parameters defined in [RFC6749] for the authorization endpoint as well as all applicable extensions defined for the authorization endpoint. Some examples of such extensions include Proof Key for Code Exchange (PKCE) [RFC7636], Resource Indicators [RFC8707], and OpenID Connect [OpenID]. It is important to note that some extension parameters have meaning in a web context but don't have meaning in a native mechanism (e.g. response_mode=query). It is out of scope as to what the AS does in the case that an extension defines a parameter that has no meaning in this use case.¶

The client initiates the authorization flow with or without information collected from the user (e.g. a signed passkey challenge or MFA code).¶

The authorization challenge endpoint response is either an authorization code or an error code, and may also contain an auth_session which the client uses on subsequent requests.¶

Further communication between the client and authorization server MAY happen at the Authorization Challenge Endpoint or any other proprietary endpoints at the authorization server.¶

4.2. Token endpoint

The token endpoint is used by the client to obtain an access token by presenting its authorization grant or refresh token, as described in Section 3.2 of OAuth 2.0 [RFC6749].¶

This specification extends the token endpoint response to allow the authorization server to indicate that further authentication of the user is required.¶

5.1. Authorization Challenge Request

The client makes a request to the authorization challenge endpoint by adding the following parameters, as well as parameters from any extensions, using the application/x-www-form-urlencoded format with a character encoding of UTF-8 in the HTTP request body:¶

"client_id":

REQUIRED if the client is not authenticating with the authorization server and if no auth_session is included.¶

"scope":

OPTIONAL. The OAuth scope defined in [RFC6749].¶

"auth_session":

OPTIONAL. If the client has previously obtained an auth session, described in Section 5.3.1.¶

"code_challenge":

OPTIONAL. The code challenge as defined by [RFC7636]. See Section 5.2.2.1 for details.¶

"code_challenge_method":

OPTIONAL. The code challenge method as defined by [RFC7636]. See Section 5.2.2.1 for details.¶

Specific implementations as well as extensions to this specification MAY define additional parameters to be used at this endpoint.¶

For example, the client makes the following request to initiate a flow given the user's phone number, line breaks shown for illustration purposes only:¶

POST /authorize-challenge HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded

login_hint=%2B1-310-123-4567&scope=profile
&client_id=bb16c14c73415

5.2. Authorization Challenge Response

The authorization server determines whether the information provided up to this point is sufficient to issue an authorization code, and if so responds with an authorization code. If the information is not sufficient for issuing an authorization code, then the authorization server MUST respond with an error response.¶

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store

{
  "authorization_code": "uY29tL2F1dGhlbnRpY"
}

5.3. Intermediate Requests

If the authorization server returns an insufficient_authorization error as described above, this is an indication that there is further information the client should request from the user, and continue to make requests to the authorization server until the authorization request is fulfilled and an authorization code returned.¶

These intermediate requests are out of scope of this specification, and are expected to be defined by the authorization server. The format of these requests is not required to conform to the format of the initial authorization challenge requests (e.g. the request format may be application/json rather than application/x-www-form-urlencoded).¶

These intermediate requests MAY also be sent to proprietary endpoints at the authorization server rather than the Authorization Challenge Endpoint.¶

6.1. Token Endpoint Successful Response

This specification extends the OAuth 2.0 [RFC6749] token response defined in Section 5.1 with the additional parameter auth_session, defined in Section 5.3.1.¶

An example successful token response is below:¶

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store

{
  "access_token": "2YotnFZFEjr1zCsicMWpAA",
  "token_type": "Bearer",
  "expires_in": 3600,
  "refresh_token": "tGzv3JOkF0XG5Qx2TlKWIA",
  "auth_session": "uY29tL2F1dGhlbnRpY"
}

The response MAY include an auth_session parameter which the client is expected to include on any subsequent requests to the authorization challenge endpoint, as described in Section 5.3.1. The auth_session parameter MAY also be included even if the authorization code was obtained through a traditional OAuth authorization code flow rather than the flow defined by this specification.¶

Including the auth_session parameter in the token response enables flows such as step-up authentication [RFC9470], so that the authorization server can restore the context of a previous session and prompt only for the needed step-up factors. See Appendix A.7 for an example application.¶

6.2. Token Endpoint Error Response

Upon any request to the token endpoint, including a request with a valid refresh token, the authorization server can respond with an authorization challenge instead of a successful access token response.¶

An authorization challenge error response is a particular type of error response as defined in Section 5.2 of OAuth 2.0 [RFC6749] where the error code is set to the following value:¶

"error": "insufficient_authorization":

The presented authorization is insufficient, and the authorization server is requesting the client take additional steps to complete the authorization.¶

Additionally, the response MAY contain an auth_session parameter which the client is expected to include on a subsequent request to the authorization challenge endpoint.¶

"auth_session":

OPTIONAL. The optional auth session value allows the authorization server to associate subsequent requests by this client with an ongoing authorization request sequence. The client MUST include the auth_session in follow-up requests to the challenge endpoint if it receives one along with the error response.¶

For example:¶

HTTP/1.1 403 Forbidden
Content-Type: application/json
Cache-Control: no-store

{
  "error": "insufficient_authorization",
  "auth_session": "uY29tL2F1dGhlbnRpY"
}

9.1. First-Party Applications

First-party applications are applications that are controlled by the same entity as the authorization server used by the application, and the user understands them both as the same entity.¶

For first-party applications, it is important that the user recognizes the application and authorization server as belonging to the same brand. For example, a bank publishing their own mobile application.¶

Because this specification enables a client application to interact directly with the end user, and the application handles sending any information collected from the user to the authorization server, it is expected to be used only for first-party applications when the authorization server also has a high degree of trust of the client.¶

This specification is not prescriptive on how the Authorization Server establishes its trust in the first-partyness of the application. For mobile platforms, most support some mechanism for application attestation that can be used to identify the entity that created/signed/uploaded the app to the app store. App attestation can be combined with other mechanisms like Dynamic Client Registration [RFC7591] to enable strong client authentication in addition to client verification (first-partyness). The exact steps required are out of scope for this specification. Note that applications running inside a browser (e.g. Single Page Apps) context it is much more difficult to verify the first-partyness of the client. Please see Section 9.8 for additional details.¶

9.2. Phishing

There are two ways using this specification increases the risk of phishing.¶

1. Malicious application: With this specification, the client interacts directly with the end user, collecting information provided by the user and sending it to the authorization server. If an attacker impersonates the client and successfully tricks a user into using it, they may not realize they are giving their credentials to the malicious application.¶

2. User education: In a traditional OAuth deployment using the redirect-based authorization code flow, the user will only ever enter their credentials at the authorization server, and it is straightforward to explain to avoid entering credentials in other "fake" websites. By introducing a new place the user is expected to enter their credentials using this specification, it is more complicated to teach users how to recognize other fake login prompts that might be attempting to steal their credentials.¶

Because of these risks, the authorization server MAY decide to require that the user go through a redirect-based flow at any stage of the process based on its own risk assessment.¶

9.3. Credential Stuffing Attacks

The authorization challenge endpoint is capable of directly receiving user credentials and returning authorization codes. This exposes a new vector to perform credential stuffing attacks, if additional measures are not taken to ensure the authenticity of the application.¶

An authorization server may already have a combination of built-in or 3rd party security tools in place to monitor and reduce this risk in browser-based authentication flows. Implementors SHOULD consider similar security measures to reduce this risk in the authorization challenge endpoint. Additionally, the attestation APIs SHOULD be used when possible to assert a level of confidence to the authorization server that the request is originating from an application owned by the same party.¶

9.4. Client Authentication

Typically, mobile and desktop applications are considered "public clients" in OAuth, since they cannot be shipped with a statically configured set of client credentials [RFC8252]. Because of this, client impersonation should be a concern of anyone deploying this pattern. Without client authentication, a malicious user or attacker can mimick the requests the application makes to the authorization server, pretending to be the legitimate client.¶

Implementers SHOULD consider additional measures to limit the risk of client impersonation, such as using attestation APIs available from the operating system.¶

9.5. Sender-Constrained Tokens

Tokens issued in response to an authorization challenge request SHOULD be sender constrained to mitigate the risk of token theft and replay.¶

Proof-of-Possession techniques constrain tokens by binding them to a cryptographic key. Whenever the token is presented, it MUST be accompanied by a proof that the client presenting the token also controls the cryptographic key bound to the token. If a proof-of-possession sender constrained token is presented without valid proof of possession of the cryptographic key, it MUST be rejected.¶

9.6. Auth Session

9.7. Multiple Applications

When multiple first-party applications are supported by the AS, then it is important to consider a number of additional risks. These risks fall into two main categories: Experience Risk and Technical Risk which are described below.¶

9.8. Single Page Applications

Single Page Applications (SPA) run in a scripting language inside the context of a browser instance. This environment poses several unique challenges compared to native applications, in particular:¶

• Significant attack vectors due to the possibility of Cross-Site Scripting (XSS) attacks¶

• Fewer options to securely attest to the first-partyness of a browser based application¶

See [I-D.ietf-oauth-browser-based-apps] for a detailed discussion of the risks of XSS attacks in browsers.¶

Additionally, the nature of a Single-Page App means the user is already in a browser context, so the user experience cost of doing a full page redirect or a popup window for the traditional OAuth Authorization Code Flow is much less than the cost of doing so in a native application. The complexity and risk of implementing this specification in a browser likely does not outweigh the user experience benefits that would be gained in that context.¶

For these reasons, it is NOT RECOMMENDED to use this specification in browser-based applications.¶

10.1. OAuth Parameters Registration

IANA has (TBD) registered the following values in the IANA "OAuth Parameters" registry of [IANA.oauth-parameters] established by [RFC6749].¶

Parameter name: auth_session¶

Parameter usage location: token response¶

Change Controller: IETF¶

Specification Document: Section 5.4 of this specification¶

10.2. OAuth Server Metadata Registration

IANA has (TBD) registered the following values in the IANA "OAuth Authorization Server Metadata" registry of [IANA.oauth-parameters] established by [RFC8414].¶

Metadata Name: authorization_challenge_endpoint¶

Metadata Description: URL of the authorization server's authorization challenge endpoint.¶

Change Controller: IESG¶

Specification Document: Section 4.1 of [[ this specification ]]¶

11.1. Normative References

[I-D.ietf-oauth-cross-device-security]

Kasselman, P., Fett, D., and F. Skokan, "Cross-Device Flows: Security Best Current Practice", Work in Progress, Internet-Draft, draft-ietf-oauth-cross-device-security-08, 8 July 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-cross-device-security-08>.

[IANA.JWT]

"*** BROKEN REFERENCE ***".

[IANA.oauth-parameters]

IANA, "OAuth Parameters", <https://www.iana.org/assignments/oauth-parameters>.

[OpenID]

Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, "OpenID Connect Core 1.0", November 2014, <https://openid.net/specs/openid-connect-core-1_0.html>.

[OpenID.Native-SSO]

Fletcher, G., "OpenID Connect Native SSO for Mobile Apps", November 2022, <https://openid.net/specs/openid-connect-native-sso-1_0.html>.

[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>.

[RFC7159]

Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, <https://www.rfc-editor.org/rfc/rfc7159>.

[RFC7515]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, <https://www.rfc-editor.org/rfc/rfc7515>.

[RFC7519]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, <https://www.rfc-editor.org/rfc/rfc7519>.

[RFC7591]

Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", RFC 7591, DOI 10.17487/RFC7591, July 2015, <https://www.rfc-editor.org/rfc/rfc7591>.

[RFC7636]

Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key for Code Exchange by OAuth Public Clients", RFC 7636, DOI 10.17487/RFC7636, September 2015, <https://www.rfc-editor.org/rfc/rfc7636>.

[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>.

[RFC8259]

Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/rfc/rfc8259>.

[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>.

[RFC8628]

Denniss, W., Bradley, J., Jones, M., and H. Tschofenig, "OAuth 2.0 Device Authorization Grant", RFC 8628, DOI 10.17487/RFC8628, August 2019, <https://www.rfc-editor.org/rfc/rfc8628>.

[RFC8707]

Campbell, B., Bradley, J., and H. Tschofenig, "Resource Indicators for OAuth 2.0", RFC 8707, DOI 10.17487/RFC8707, February 2020, <https://www.rfc-editor.org/rfc/rfc8707>.

[RFC9126]

Lodderstedt, T., Campbell, B., Sakimura, N., Tonge, D., and F. Skokan, "OAuth 2.0 Pushed Authorization Requests", RFC 9126, DOI 10.17487/RFC9126, September 2021, <https://www.rfc-editor.org/rfc/rfc9126>.

[RFC9449]

Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449, September 2023, <https://www.rfc-editor.org/rfc/rfc9449>.

[RFC9470]

Bertocci, V. and B. Campbell, "OAuth 2.0 Step Up Authentication Challenge Protocol", RFC 9470, DOI 10.17487/RFC9470, September 2023, <https://www.rfc-editor.org/rfc/rfc9470>.

[SHS]

Technology, N. I. of S. and., ""Secure Hash Standard (SHS)", FIPS PUB 180-4, DOI 10.6028/NIST.FIPS.180-4", August 2015, <http://dx.doi.org/10.6028/NIST.FIPS.180-4>.

[USASCII]

Institute, A. N. S., "Coded Character Set -- 7-bit American Standard Code for Information Interchange, ANSI X3.4", 1986.

11.2. Informative References

[I-D.ietf-oauth-browser-based-apps]

Parecki, A., Waite, D., and P. De Ryck, "OAuth 2.0 for Browser-Based Applications", Work in Progress, Internet-Draft, draft-ietf-oauth-browser-based-apps-18, 1 May 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps-18>.

[RFC6750]

Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, DOI 10.17487/RFC6750, October 2012, <https://www.rfc-editor.org/rfc/rfc6750>.

[RFC8252]

Denniss, W. and J. Bradley, "OAuth 2.0 for Native Apps", BCP 212, RFC 8252, DOI 10.17487/RFC8252, October 2017, <https://www.rfc-editor.org/rfc/rfc8252>.

A.1. Passkey

A user may log in with a passkey (without a password).¶

1. The Client collects the username from the user.¶

2. The Client sends an Authorization Challenge Request (Section 5.1) to the Authorization Challenge Endpoint (Section 4.1) including the username.¶

3. The Authorization Server verifies the username and returns a challenge¶

4. The Client signs the challenge using the platform authenticator, which results in the user being prompted for verification with biometrics or a PIN.¶

5. The Client sends the signed challenge, username, and credential ID to the Authorization Challenge Endpoint (Section 4.1).¶

6. The Authorization Server verifies the signed challenge and returns an Authorization Code.¶

7. The Client requests an Access Token and Refresh Token by issuing a Token Request (Section 6) to the Token Endpoint.¶

8. The Authorization Server verifies the Authorization Code and issues the requested tokens.¶

A.2. Redirect to Authorization Server

A user may be redirected to the Authorization Server to perfrom an account reset.¶

1. The Client collects username from the user.¶

2. The Client sends an Authorization Challenge Request (Section 5.1) to the Authorization Challenge Endpoint (Section 4.1) including the username.¶

3. The Authorization Server verifies the username and determines that the account is locked and returns a Redirect error response.¶

4. The Client parses the redirect message, opens a browser and redirects the user to the Authorization Server performing an OAuth 2.0 flow with PKCE.¶

5. The user resets their account by performing a multi-step authentication flow with the Authorization Server.¶

6. The Authorization Server issues an Authorization Code in a redirect back to the client, which then exchanges it for an access and refresh token.¶

A.3. Passwordless One-Time Password (OTP)

In a passwordless One-Time Password (OTP) scheme, the user is in possession of a one-time password generator. This generator may be a hardware device, or implemented as an app on a mobile phone. The user provides a user identifier and one-time password, which is verified by the Authorization Server before it issues an Authorization Code, which can be exchanged for an Access and Refresh Token.¶

1. The Client collects username and OTP from user.¶

2. The Client sends an Authorization Challenge Request (Section 5.1) to the Authorization Challenge Endpoint (Section 4.1) including the username and OTP.¶

3. The Authorization Server verifies the username and OTP and returns an Authorization Code.¶

4. The Client requests an Access Token and Refresh Token by issuing a Token Request (Section 6) to the Token Endpoint.¶

5. The Authorization Server verifies the Authorization Code and issues the requested tokens.¶

A.4. E-Mail Confirmation Code

A user may be required to provide an e-mail confirmation code as part of an authentication ceremony to prove they control an e-mail address. The user provides an e-mail address and is then required to enter a verification code sent to the e-mail address. If the correct verification code is returned to the Authorization Server, it issues Access and Refresh Tokens.¶

1. The Client collects an e-mail address from the user.¶

2. The Client sends the e-mail address in an Authorization Challenge Request (Section 5.1) to the Authorization Challenge Endpoint (Section 4.1).¶

3. The Authorization Server sends a verification code to the e-mail address and returns an Error Response (Section 5.2.2) including "error": "insufficient_authorization", "auth_session" and a custom property indicating that an e-mail verification code must be entered.¶

4. The Client presents a user experience guiding the user to copy the e-mail verification code to the Client. Once the e-mail verification code is entered, the Client sends an Authorization Challenge Request to the Authorization Challenge Endpoint, including the e-mail verification code as well as the auth_session parameter returned in the previous Error Response.¶

5. The Authorization Server uses the auth_session to maintain the session and verifies the e-mail verification code before issuing an Authorization Code to the Client.¶

6. The Client sends the Authorization Code in a Token Request (Section 6) to the Token Endpoint.¶

7. The Authorization Server verifies the Authorization Code and issues the Access Token and Refresh Token.¶

An alternative version of this verification involves the user clicking a link in an email rather than manually entering a verification code. This is typically done for email verification flows rather than inline in a login flow. The protocol-level details remain the same for the alternative flow despite the different user experience. All steps except step 4 above remain the same, but the client presents an alternative user experience for step 4 described below:¶

• The Client presents a message to the user instructing them to click the link sent to their email address. The user clicks the link in the email, which contains the verification code in the URL. The URL launches the app providing the verification code to the Client. The Client sends the verification code and auth_session to the Authorization Challenge Endpoint.¶

A.5. Mobile Confirmation Code

A user may be required to provide a confirmation code as part of an authentication ceremony to prove they control a mobile phone number. The user provides a phone number and is then required to enter a confirmation code sent to the phone. If the correct confirmation code is returned to the Authorization Server, it issues Access and Refresh Tokens.¶

1. The Client collects a mobile phone number from the user.¶

2. The Client sends the phone number in an Authorization Challenge Request (Section 5.1) to the Authorization Challenge Endpoint (Section 4.1).¶

3. The Authorization Server sends a confirmation code to the phone number and returns an Error Response (Section 5.2.2) including "error": "insufficient_authorization", "auth_session" and a custom property indicating that a confirmation code must be entered.¶

4. The Client presents a user experience guiding the user to enter the confirmation code. Once the code is entered, the Client sends an Authorization Challenge Request to the Authorization Challenge Endpoint, including the confirmation code as well as the auth_session parameter returned in the previous Error Response.¶

5. The Authorization Server uses the auth_session to maintain the session context and verifies the code before issuing an Authorization Code to the Client.¶

6. The Client sends the Authorization Code in a Token Request (Section 6) to the Token Endpoint.¶

7. The Authorization Server verifies the Authorization Code and issues the Access Token and Refresh Token.¶

A.6. Re-authenticating to an app a week later using OTP

A client may be in possession of an Access and Refresh Token as the result of a previous succesful user authentication. The user returns to the app a week later and accesses the app. The Client presents the Access Token, but receives an error indicating the Access Token is no longer valid. The Client presents a Refresh Token to the Authorization Server to obtain a new Access Token. If the Authorization Server requires user interaction for reasons based on its own policies, it rejects the Refresh Token and the Client re-starts the user authentication flow to obtain new Access and Refresh Tokens.¶

1. The Client has a short-lived access token and long-lived refresh token following a previous completion of an Authorization Grant Flow which included user authentication.¶

2. A week later, the user launches the app and tries to access a protected resource at the Resource Server.¶

3. The Resource Server responds with an error code indicating an invalid access token since it has expired.¶

4. The Client presents the refresh token to the Authorization Server to obtain a new access token (section 6 [RFC6749])¶

5. The Authorization Server responds with an error code indicating that an OTP from the user is required, as well as an auth_session.¶

6. The Client prompts the user to enter an OTP.¶

7. The Client sends the OTP and auth_session in an Authorization Challenge Request (Section 5.1) to the Authorization Challenge Endpoint (Section 4.1).¶

8. The Authorization Server verifies the auth_session and OTP, and returns an Authorization Code.¶

9. The Client sends the Authorization Code in a Token Request (Section 6) to the Token Endpoint.¶

10. The Authorization Server verifies the Authorization Code and issues the requested tokens.¶

11. The Client presents the new Access Token to the Resource Server in order to access the protected resource.¶

A.7. Step-up Authentication using Confirmation SMS

A Client previously obtained an Access and Refresh Token after the user authenticated with an OTP. When the user attempts to access a protected resource, the Resource Server determines that it needs an additional level of authentication and triggers a step-up authentication, indicating the desired level of authentication using acr_values and max_age as defined in the Step-up Authentication specification. The Client initiates an authorization request with the Authorization Server indicating the acr_values and max_age parameters. The Authorization Server responds with error messages promptng for additional authentication until the acr_values and max_age values are satisfied before issuing fresh Access and Refresh Tokens.¶

1. The Client has a short-lived access token and long-lived refresh token following the completion of an Authorization Code Grant Flow which included user authentication.¶

2. When the Client presents the Access token to the Resource Server, the Resource Server determines that the acr claim in the Access Token is insufficient given the resource the user wants to access and responds with an insufficient_user_authentication error code, along with the desired acr_values and desired max_age.¶

3. The Client sends an Authorization Challenge Request (Section 5.1) to the Authorization Challenge Endpoint (Section 4.1) including the auth_session, acr_values and max_age parameters.¶

4. The Authorization Server verifies the auth_session and determines which authentication methods must be satisfied based on the acr_values, and responds with an Error Response (Section 5.2.2) including "error": "insufficient_authorization" and a custom property indicating that an OTP must be entered.¶

5. The Client prompts the user for an OTP, which the user obtains and enters.¶

6. The Client sends an Authorization Challenge Request to the Authorization Challenge Endpoint including the auth_session and OTP.¶

7. The Authorization Server verifies the OTP and returns an Authorization Code.¶

8. The Client sends the Authorization Code in a Token Request (Section 6) to the Token Endpoint.¶

9. The Authorization Server verifies the Authorization Code and issues an Access Token with the updated acr value along with the Refresh Token.¶

10. The Client presents the Access Token to the Resources Server, which verifies that the acr value meets its requirements before granting access to the protected resource.¶

A.8. Registration

This example describes how to use the mechanisms defined in this draft to create a complete user registration flow starting with an email address. In this example, it is the Authorization Server's policy to allow these challenges to be sent to email and phone number that were previously unrecognized, and creating the user account on the fly.¶

1. The Client collects a username from the user.¶

2. The Client sends an Authorization Challenge Request (Section 5.1) to the Authorization Challenge Endpoint (Section 4.1) including the username.¶

3. The Authorization Server returns an Error Response (Section 5.2.2) including "error": "insufficient_authorization", "auth_session", and a custom property indicating that an e-mail address must be collected.¶

4. The Client collects an e-mail address from the user.¶

5. The Client sends the e-mail address as part of a second Authorization Challenge Request to the Authorization Challenge Endpoint, along with the auth_session parameter.¶

6. The Authorization Server sends a verification code to the e-mail address and returns an Error Response including "error": "insufficient_authorization", "auth_session" and a custom property indicating that an e-mail verification code must be entered.¶

7. The Client presents a user experience guiding the user to copy the e-mail verification code to the Client. Once the e-mail verification code is entered, the Client sends an Authorization Challenge Request to the Authorization Challenge Endpoint, including the e-mail verification code as well as the auth_session parameter returned in the previous Error Response.¶

8. The Authorization Server uses the auth_session to maintain the session context, and verifies the e-mail verification code. It determines that it also needs a phone number for account recovery purposes and returns an Error Response including "error": "insufficient_authorization", "auth_session" and a custom property indicating that a phone number must be collected.¶

9. The Client collects a mobile phone number from the user.¶

10. The Client sends the phone number in an Authorization Challenge Request to the Authorization Challenge Endpoint, along with the auth_session.¶

11. The Authorization Server uses the auth_session parameter to link the previous requests. It sends a confirmation code to the phone number and returns an Error Response including "error": "insufficient_authorization", "auth_session" and a custom property indicating that a SMS confirmation code must be entered.¶

12. The Client presents a user experience guiding the user to enter the SMS confirmation code. Once the SMS verification code is entered, the Client sends an Authorization Challenge Request to the Authorization Challenge Endpoint, including the confirmation code as well as the auth_session parameter returned in the previous Error Response.¶

13. The Authorization Server uses the auth_session to maintain the session context, and verifies the SMS verification code before issuing an Authorization Code to the Client.¶

14. The Client sends the Authorization Code in a Token Request (Section 6) to the Token Endpoint.¶

15. The Authorization Server verifies the Authorization Code and issues the requested tokens.¶

B.1. Authorization Challenge Request Parameters

In addition to the request parameters defined in Section 5.1, the authorization server defines the additional parameters below.¶

"username":

REQUIRED for the initial Authorization Challenge Request.¶

"otp":

The OTP collected from the user. REQUIRED when re-trying an Authorization Challenge Request in response to the otp_required error defined below.¶

B.2. Authorization Challenge Response Parameters

In addition to the response parameters defined in Section 5.2, the authorization server defines the additional value for the error response below.¶

"otp_required":

The client should collect an OTP from the user and send the OTP in a second request to the Authorization Challenge Endpoint. The HTTP response code to use with this error value is 401 Unauthorized.¶

B.3. Example Sequence

The client prompts the user to enter their username, and sends the username in an initial Authorization Challenge Request.¶

POST /authorize-challenge HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded

username=alice
&scope=photos
&client_id=bb16c14c73415

The Authorization Server sends an error response indicating that an OTP is required.¶

HTTP/1.1 401 Unauthorized
Content-Type: application/json
Cache-Control: no-store

{
  "error": "otp_required",
  "auth_session": "ce6772f5e07bc8361572f"
}

The client prompts the user for an OTP, and sends a new Authorization Challenge Request.¶

POST /authorize-challenge HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded

auth_session=ce6772f5e07bc8361572f
&otp=555121

The Authorization Server validates the auth_session to find the expected user, then validates the OTP for that user, and responds with an authorization code.¶

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store

{
  "authorization_code": "uY29tL2F1dGhlbnRpY"
}

The client sends the authorization code to the token endpoint.¶

POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&client_id=bb16c14c73415
&code=uY29tL2F1dGhlbnRpY

The Authorization Server responds with an access token and refresh token.¶

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store

{
  "token_type": "Bearer",
  "expires_in": 3600,
  "access_token": "d41c0692f1187fd9b326c63d",
  "refresh_token": "e090366ac1c448b8aed84cbc07"
}