Call Your API Using the Authorization Code Flow with PKCE

This tutorial helps you call your own API from a native, mobile, or single-page app using the Authorization Code Flow with PKCE. To learn how the flow works and why you should use it, read Authorization Code Flow with Proof Key for Code Exchange (PKCE). To learn to add login to your native, mobile, or single-page app, read Add Login Using Authorization Code Flow with PKCE.

Auth0 makes it easy for your app to implement the Authorization Code Flow with Proof Key for Code Exchange (PKCE) using:

Auth0 Mobile SDKs and Auth0 Single-Page App SDK: The easiest way to implement the flow, which will do most of the heavy-lifting for you. Our Mobile Quickstarts and Single-Page App Quickstarts will walk you through the process.
Authentication API: If you prefer to build your own solution, keep reading to learn how to call our API directly.

Prerequisites

Before beginning this tutorial:

Register the Application with Auth0.
- Select an Application Type of Native or Single-Page App, depending on your application type.
- Add an Allowed Callback URL of {yourCallbackUrl}. Your callback URL format will vary depending on your application type and platform. For details about the format for your application type and platform, see our Native/Mobile Quickstarts and Single-Page App Quickstarts.
- Make sure the Application’s Grant Types include Authorization Code. To learn how, read Update Grant Types.
- If you want your Application to be able to use Refresh Tokens, make sure the Application’s Grant Types include Refresh Token. To learn how, read Update Grant Types. To learn more about Refresh Tokens, read Refresh Tokens.
Register your API with Auth0
- If you want your API to receive Refresh Tokens to allow it to obtain new tokens when the previous ones expire, enable Allow Offline Access.

Steps

Create code verifier: Generate a code_verifier that will be sent to Auth0 to request tokens.
Create code challenge: Generate a code_challenge from the code_verifier that will be sent to Auth0 to request an authorization_code.
Authorize user: Request the user’s authorization and redirect back to your app with an authorization_code.
Request tokens: Exchange your authorization_code and code_verifier for tokens.
Call API: Use the retrieved Access Token to call your API.
Refresh tokens: Use a Refresh Token to request new tokens when the existing ones expire.

Optional: Explore sample use cases.

Create code verifier

Create a code_verifier, which is a cryptographically-random, Base64-encoded key that will eventually be sent to Auth0 to request tokens.

Javascript sample

// Dependency: Node.js crypto module
// https://nodejs.org/api/crypto.html#crypto_crypto
function base64URLEncode(str) {
    return str.toString('base64')
        .replace(/\+/g, '-')
        .replace(/\//g, '_')
        .replace(/=/g, '');
}
var verifier = base64URLEncode(crypto.randomBytes(32));

Java sample

// Dependency: Apache Commons Codec
// https://commons.apache.org/proper/commons-codec/
// Import the Base64 class.
// import org.apache.commons.codec.binary.Base64;
SecureRandom sr = new SecureRandom();
byte[] code = new byte[32];
sr.nextBytes(code);
String verifier = Base64.getUrlEncoder().withoutPadding().encodeToString(code);

Android sample

// See https://developer.android.com/reference/android/util/Base64
// Import the Base64 class
// import android.util.Base64;
SecureRandom sr = new SecureRandom();
byte[] code = new byte[32];
sr.nextBytes(code);
String verifier = Base64.encodeToString(code, Base64.URL_SAFE | Base64.NO_WRAP | Base64.NO_PADDING);

Swift 5 sample

var buffer = [UInt8](repeating: 0, count: 32)
_ = SecRandomCopyBytes(kSecRandomDefault, buffer.count, &buffer)
let verifier = Data(buffer).base64EncodedString()
    .replacingOccurrences(of: "+", with: "-")
    .replacingOccurrences(of: "/", with: "_")
    .replacingOccurrences(of: "=", with: "")

Objective-C sample

NSMutableData *data = [NSMutableData dataWithLength:32];
int result __attribute__((unused)) = SecRandomCopyBytes(kSecRandomDefault, 32, data.mutableBytes);
NSString *verifier = [[[[data base64EncodedStringWithOptions:0]
                        stringByReplacingOccurrencesOfString:@"+" withString:@"-"]
                        stringByReplacingOccurrencesOfString:@"/" withString:@"_"]
                        stringByTrimmingCharactersInSet:[NSCharacterSet characterSetWithCharactersInString:@"="]];

Create code challenge

Generate a code_challenge from the code_verifier that will be sent to Auth0 to request an authorization_code.

Javascript sample

// Dependency: Node.js crypto module
// https://nodejs.org/api/crypto.html#crypto_crypto
function sha256(buffer) {
    return crypto.createHash('sha256').update(buffer).digest();
}
var challenge = base64URLEncode(sha256(verifier));

Java sample

// Dependency: Apache Commons Codec
// https://commons.apache.org/proper/commons-codec/
// Import the Base64 class.
// import org.apache.commons.codec.binary.Base64;
byte[] bytes = verifier.getBytes("US-ASCII");
MessageDigest md = MessageDigest.getInstance("SHA-256");
md.update(bytes, 0, bytes.length);
byte[] digest = md.digest();
String challenge = Base64.encodeBase64URLSafeString(digest);

Swift 5 sample

import CommonCrypto

// ...

guard let data = verifier.data(using: .utf8) else { return nil }
var buffer = [UInt8](repeating: 0, count: Int(CC_SHA256_DIGEST_LENGTH))
_ = data.withUnsafeBytes {
    CC_SHA256($0.baseAddress, CC_LONG(data.count), &buffer)
}
let hash = Data(buffer)
let challenge = hash.base64EncodedString()
    .replacingOccurrences(of: "+", with: "-")
    .replacingOccurrences(of: "/", with: "_")
    .replacingOccurrences(of: "=", with: "")

Objective-C sample

// Dependency: Apple Common Crypto library
// http://opensource.apple.com//source/CommonCrypto
u_int8_t buffer[CC_SHA256_DIGEST_LENGTH * sizeof(u_int8_t)];
memset(buffer, 0x0, CC_SHA256_DIGEST_LENGTH);
NSData *data = [verifier dataUsingEncoding:NSUTF8StringEncoding];
CC_SHA256([data bytes], (CC_LONG)[data length], buffer);
NSData *hash = [NSData dataWithBytes:buffer length:CC_SHA256_DIGEST_LENGTH];
NSString *challenge = [[[[hash base64EncodedStringWithOptions:0]
                         stringByReplacingOccurrencesOfString:@"+" withString:@"-"]
                         stringByReplacingOccurrencesOfString:@"/" withString:@"_"]
                         stringByTrimmingCharactersInSet:[NSCharacterSet characterSetWithCharactersInString:@"="]];

Authorize user

Once you’ve created the code_verifier and the code_challenge, you must get the user’s authorization. This is technically the beginning of the , and this step may include one or more of the following processes: * Authenticating the user; * Redirecting the user to an to handle authentication; * Checking for active Single Sign-on (SSO) sessions; * Obtaining user consent for the requested permission level, unless consent has been previously given. To authorize the user, your app must send the user to the authorization URL, including the code_challenge you generated in the previous step and the method you used to generate the code_challenge.

Example authorization URL

https://{yourDomain}/authorize?
    response_type=code&
    code_challenge={codeChallenge}&
    code_challenge_method=S256&
    client_id={yourClientId}&
    redirect_uri={yourCallbackUrl}&
    scope=SCOPE&
    audience={apiAudience}&
    state={state}

Parameters

Note that for authorizing a user when calling a custom API, you:

must include an parameter
can include additional scopes supported by the target API

Parameter Name	Description
`response_type`	Denotes the kind of credential that Auth0 will return (`code` or `token`). For this flow, the value must be `code`.
`code_challenge`	Generated challenge from the `code_verifier`.
`code_challenge_method`	Method used to generate the challenge (e.g., S256). 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.
`client_id`	Your application’s Client ID. You can find this value in your Application 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. You must specify this URL as a valid callback URL in your Application Settings. Warning: Per the OAuth 2.0 Specification, Auth0 removes everything after the hash and does not honor any fragments.
`scope`	The scopes for which you want to request authorization. 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 conforming to a namespaced format, or any scopes supported by the target API (e.g., `read:contacts`). Include `offline_access` to get a (make sure that the Allow Offline Access field is enabled in the Application Settings).
`audience`	The unique identifier of the API your mobile 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.
`state`	(recommended) An opaque arbitrary alphanumeric string your app adds to the initial request that Auth0 includes when redirecting back to your application. To see how to use this value to prevent cross-site request forgery (CSRF) attacks, see Mitigate CSRF Attacks With State Parameters.
`organization`	(optional) ID of the organization to use when authenticating a user. When not provided, if your application is configured to Display Organization Prompt, the user will be able to enter the organization name when authenticating.
`invitation`	(optional) Ticket ID of the organization invitation. When inviting a member to an Organization, your application should handle invitation acceptance by forwarding the `invitation` and `organization` key-value pairs when the user accepts the invitation.

As an example, your HTML snippet for your authorization URL when calling an API might look like:

<a href="https://{yourDomain}/authorize?
  response_type=code&
  client_id={yourClientId}&
  code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM&
  code_challenge_method=S256&
  redirect_uri={yourCallbackUrl}&
  scope=appointments%20contacts&
  audience=appointments:api&
  state=xyzABC123">
  Sign In
</a>

Response

If all goes well, you’ll receive an HTTP 302 response. The authorization code is included at the end of the URL:

HTTP/1.1 302 Found
Location: {yourCallbackUrl}?code={authorizationCode}&state=xyzABC123

Request tokens

Now that you have an Authorization Code, you must exchange it for tokens. Using the extracted Authorization Code (code) from the previous step, you will need to POST to the token URL sending along the code_verifier.

Example POST to token URL

curl --request POST \
  --url 'https://{yourDomain}/oauth/token' \
  --header 'content-type: application/x-www-form-urlencoded' \
  --data grant_type=authorization_code \
  --data 'client_id={yourClientId}' \
  --data 'code_verifier={yourGeneratedCodeVerifier}' \
  --data 'code={yourAuthorizationCode}' \
  --data 'redirect_uri={https://yourApp/callback}'

Parameters

Parameter Name	Description
`grant_type`	Set this to “authorization_code”.
`code_verifier`	The cryptographically-random key that was generated in the first step of this tutorial.
`code`	The `authorization_code` retrieved in the previous step of this tutorial.
`client_id`	Your application’s Client ID. You can find this value in your Application Settings.
`redirect_uri`	The valid callback URL set in your Application settings. This must exactly match the `redirect_uri` passed to the authorization URL in the previous step of this tutorial. Note that this must be URL encoded.

Response

If all goes well, you’ll receive an HTTP 200 response with a payload containing access_token, refresh_token, id_token, and token_type values:

{
  "access_token":"eyJz93a...k4laUWw",
  "refresh_token":"GEbRxBN...edjnXbL",
  "id_token":"eyJ0XAi...4faeEoQ",
  "token_type":"Bearer",
  "expires_in":86400
}

Validate your tokens before saving them. To learn how, read Validate ID Tokens and Validate Access Tokens.

ID tokens contain user information that must be decoded and extracted. Access tokens are used to call the Auth0 Authentication API’s /userinfo endpoint or another API. If you are calling your own API, the first thing your API will need to do is verify the Access token. Refresh tokens are used to obtain a new or after the previous one has expired. The 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.

Refresh tokens must be stored securely since they allow a user to remain authenticated essentially forever.

Call API

To call your API from a native/mobile application, the application must pass the retrieved Access Token as a Bearer token in the Authorization header of your HTTP request.

curl --request GET \
  --url https://myapi.com/api \
  --header 'authorization: Bearer {accessToken}' \
  --header 'content-type: application/json'

Refresh tokens

You have already received a refresh token if you’ve been following this tutorial and completed the following:

configured your API to allow offline access
included the offline_access scope when you initiated the authentication request through the authorize endpoint.

You can use the to get a new access token. Usually, a user will need a new access token only after the previous one expires or when gaining access to a new resource for the first time. It’s bad practice to call the endpoint to get a new access token every time you call an API, and Auth0 maintains rate limits that will throttle the amount of requests to the endpoint that can be executed using the same token from the same IP. To refresh your token, make a POST request to the /oauth/token endpoint in the Authentication API, using grant_type=refresh_token.

Example POST to token URL

curl --request POST \
  --url 'https://{yourDomain}/oauth/token' \
  --header 'content-type: application/x-www-form-urlencoded' \
  --data grant_type=refresh_token \
  --data 'client_id={yourClientId}' \
  --data 'refresh_token={yourRefreshToken}'

Parameters

Parameter Name	Description
`grant_type`	Set this to `refresh_token`.
`client_id`	Your application’s Client ID. You can find this value in your Application Settings.
`refresh_token`	The refresh token to use.
`scope`	(optional) A space-delimited list of requested scope permissions. If not sent, the original scopes will be used; otherwise you can request a reduced set of scopes. Note that this must be URL encoded.

Response

If all goes well, you’ll receive an HTTP 200 response with a payload containing a new access_token, its lifetime in seconds (expires_in), granted scope values, and token_type. If the scope of the initial token included openid, then the response will also include a new id_token:

{
  "access_token": "eyJ...MoQ",
  "expires_in": 86400,
  "scope": "openid offline_access",
  "id_token": "eyJ...0NE",
  "token_type": "Bearer"
}

Validate your tokens before saving them. To learn how, read Validate ID Tokens and Validate Access Tokens.

Sample use cases

Customize tokens

You can use Actions to change the returned scopes of Access Tokens and/or add claims to Access and ID Tokens. (To learn more about Actions, read Auth0 Actions. ) To do so, add the following Action, which will run after the user authenticates:

exports.onExecutePostLogin = async (event, api) => {
  // Add custom claims to Access Token and ID Token
  api.accessToken.setCustomClaim('https://foo/bar', 'value');
  api.idToken.setCustomClaim('https://fiz/baz', 'some other value');

  // Modify the scope of the Access Token
  api.accessToken.addScope('foo');
  api.accessToken.addScope('bar');
};

Scopes will be available in the token after the Action has run.

Auth0 returns profile information in a structured claim format as defined by the OpenID Connect (OIDC) specification. This means that custom claims added to ID tokens or access tokens must conform to guidelines and restrictions to avoid possible collisions.

View Sample Application: Mobile App + API

For a sample implementation, see the Mobile + API architecture scenario. This series of tutorials is accompanied by a code sample that you can access in GitHub.

Auth0 Onboarding

Learn the Basics

Configure Auth0

Plan and Design

Auth0 AI

Call Your API Using the Authorization Code Flow with PKCE

Prerequisites

Steps

Create code verifier

Javascript sample

Java sample

Android sample

Swift 5 sample

Objective-C sample

Create code challenge

Javascript sample

Java sample

Swift 5 sample

Objective-C sample

Authorize user

Example authorization URL

Parameters

Response

Request tokens

Example POST to token URL

Parameters

Response

Call API

Refresh tokens

Example POST to token URL

Parameters

Response

Sample use cases

Customize tokens

View Sample Application: Mobile App + API

Learn more

Auth0 Onboarding

Learn the Basics

Configure Auth0

Plan and Design

Auth0 AI

​Prerequisites

​Steps

​Create code verifier

​Javascript sample

​Java sample

​Android sample

​Swift 5 sample

​Objective-C sample

​Create code challenge

​Javascript sample

​Java sample

​Swift 5 sample

​Objective-C sample

​Authorize user

​Example authorization URL

Parameters

​Response

​Request tokens

​Example POST to token URL

Parameters

​Response

​Call API

​Refresh tokens

​Example POST to token URL

Parameters

​Response

​Sample use cases

​Customize tokens

​View Sample Application: Mobile App + API

​Learn more

Prerequisites

Steps

Create code verifier

Javascript sample

Java sample

Android sample

Swift 5 sample

Objective-C sample

Create code challenge

Javascript sample

Java sample

Swift 5 sample

Objective-C sample

Authorize user

Example authorization URL

Response

Request tokens

Example POST to token URL

Response

Call API

Refresh tokens

Example POST to token URL

Response

Sample use cases

Customize tokens

View Sample Application: Mobile App + API

Learn more