Docs

Execute an Authorization Code Grant Flow with PKCE

This tutorial will help you implement the Authorization Code (PKCE) grant. If you are looking for some theory on the flow refer to Authorization Code Flow with Proof Key for Code Exchange (PKCE).

The Authorization Code with PKCE is the OAuth 2.0 grant that native apps use in order to access an API. In this document we will work through the steps needed in order to implement this: create a code verifier and a code challenge, get the user's authorization, get a token and access the API using the token.

Before beginning this tutorial, please:

1. Create a Code Verifier

First, you need to generate and store a code_verifier.

2. Create a Code Challenge

Using the code_verifier, generate a code_challenge that will be sent in the authorization request.

3. Get the User's Authorization

To begin an Authorization Code Grant flow, your native application should first send the user to the authorization URL including the code_challenge and the method used to generate it.

Where:

  • audience: The unique identifier of the API the native app wants to access. Use the Identifier value on the Settings tab for the API you created as part of the prerequisites for this tutorial.

  • scope: The scopes that you want to request authorization for. These must be separated by a space. You can request any of the standard OpenID Connect (OIDC) scopes about users, such as profile and email, custom claims that must conform to a namespaced format, or any scopes supported by the target API (for example, read:contacts). Include offline_access to get a Refresh Token (make sure that the Allow Offline Access field is enabled in the API Settings). The custom scopes must conform to a namespaced format. For more information on this, refer to the Namespacing Custom Claims panel.

  • response_type: Denotes the kind of credential that Auth0 will return (code vs token). For this flow, the value must be code.

  • client_id: Your application's Client ID. You can find this value at your Application's Settings.

  • redirect_uri: The URL to which Auth0 will redirect the browser after authorization has been granted by the user. The Authorization Code will be available in the code URL parameter. This URL must be specified as a valid callback URL under your Application's Settings.

  • code_challenge: Generated challenge from the code_verifier.

  • code_challenge_method: Method used to generate the challenge.

PKCE methods

The PKCE spec defines two methods, S256 and plain, the former is used in this example and is the only one supported by Auth0 since the latter is discouraged.

For example:

4. Exchange the Authorization Code for an Access Token

Now that you have an Authorization Code, you must exchange it for an Access Token that can be used to call your API. Using the Authorization Code (code) from the previous step, you will need to POST to the Token URL sending also the code_verifier:




Where:

  • grant_type: This must be authorization_code.
  • client_id: Your application's Client ID.
  • code_verifier: Cryptographically random key that was used to generate the code_challenge passed to /authorize.
  • code: The Authorization Code received from the initial authorize call.
  • redirect_uri: The URL must match exactly the redirect_uri passed to /authorize.

The response contains access_token, refresh_token, id_token, and token_type values, for example:

Note that refresh_token will only be present in the response if you included the offline_access scope AND enabled Allow Offline Access for your API in the Dashboard. For more information about Refresh Tokens and how to use them, see our documentation.

The Authorization Code flow with PKCE can only be used for Applications whose type is Native in the Dashboard.

5. Call the API

Once you have the Access Token, you can use it to make calls to the API, by passing it as a Bearer Token in the Authorization header of the HTTP request:




6. Verify the Token

Once your API receives a request with a Bearer Access Token, the first thing to do is to validate the token. This consists of a series of steps, and if any of these fails then the request must be rejected.

For details on the validations that should be performed refer to Verify Access Tokens.

Optional: Customize the Tokens

You can use Rules to change the returned scopes of the Access Token and/or add claims to it (and the ID Token) with a script like this:

Namespacing Custom Claims

Auth0 returns profile information in a structured claim format as defined by the OpenID Connect (OIDC) specification. This means that in order to add custom claims to ID Tokens or Access Tokens, they must conform to a namespaced format to avoid possible collisions with standard OIDC claims. For example, if you choose the namespace https://foo.com/ and you want to add a custom claim named myclaim, you would name the claim https://foo.com/myclaim, instead of myclaim. You can add namespaced claims using Rules.

If you wish to execute special logic unique to the Authorization Code (PKCE) grant, you can look at the context.protocol property in your rule. If the value is oidc-basic-profile, then the rule is running during the Authorization Code (PKCE) grant.

Sample application

For an example implementation see the Mobile + API architecture scenario.

This is a series of tutorials that describe a scenario for a fictitious company. The company wants to implement a mobile app that the employees can use to send their timesheets to the company's Timesheets API using OAuth 2.0. The tutorials are accompanied by a sample that you can access in GitHub.

Keep reading