Add Login Using the Authorization Code Flow with PKCE

Learn how to add login to your native, mobile, or single-page application using the Authorization Code Flow with Proof Key for Code Exchange (PKCE).

You can add login to your 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 how to call your API from a native, mobile, or single-page app, read Call Your API Using Authorization Code Flow with PKCE.

To implement the Authorization Code Flow with Proof Key for Code Exchange (PKCE), you can use the following resources:

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

Following successful login, your application will have access to the user’s ID token and access token. The ID token will contain basic user profile information, and the access token can be used to call the Auth0 /userinfo endpoint or your own protected APIs. To learn more about ID tokens, read ID Tokens. To learn more about access tokens, read Access Tokens.

Prerequisites

Register your app with Auth0. To learn more, read Register Native Applications or Register Single-Page Web Applications.

• Select an Application Type of Native or Single-Page App, depending on your application type.
• Add an Allowed Callback URL of YOUR_CALLBACK_URL. 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 your application’s Grant Types include Authorization Code. To learn more, read Update Grant Types.

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.

To learn more about the algorithm to create the code_verifier, read section 4.1 Client Creates a Code Verifier of the OAuth Proof Key for Code Exchange spec.

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

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

To learn more about how the code_challenge is derived from the code_verifier, read section 4.2 Client Creates the Code Challenge of the OAuth Proof Key for Code Exchange spec.

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

Request the user’s authorization and redirect back to your app with an authorization_code.

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 authorization flow, and this step may include one or more of the following processes:

* Authenticating the user; * Redirecting the user to an Identity Provider 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.

Authorization URL example

Parameters

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	Specifies the scopes for which you want to request authorization, which dictate which claims (or user attributes) you want returned. These must be separated by a space. To get an ID Token in the response, you need to specify a scope of at least openid. If you want to return the user’s full profile, you can request openid profile. You can request any of the standard OpenID Connect (OIDC) scopes about users, such as email, or custom claims conforming to a namespaced format. Include offline_access to get a Refresh Token (make sure that the Allow Offline Access field is enabled in the Application Settings).
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.
connection	(optional) Forces the user to sign in with a specific connection. For example, you can pass a value of github to send the user directly to GitHub to log in with their GitHub account. When not specified, the user sees the Auth0 Lock screen with all configured connections. You can see a list of your configured connections on the Connections tab of your application.
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 adding login to your app might look like:

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

Exchange your authorization_code and code_verifier for 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.

POST to token URL example

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 access token or ID token 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.

Use cases

Basic authentication request

This example shows the most basic request you can make when authorizing the user in step 1. It displays the Auth0 login screen and allows the user to sign in with any of your configured connections:

Now, when you request tokens, your ID Token will contain the most basic claims. When you decode the ID Token, it will look similar to:

{
  "iss": "https://auth0pnp.auth0.com/",
  "sub": "auth0|581...",
  "aud": "xvt9...",
  "exp": 1478112929,
  "iat": 1478076929
}

Request user’s name and profile picture

In addition to the usual user authentication, this example shows how to request additional user details, such as name and picture.

To request the user’s name and picture, you need to add the appropriate scopes when authorizing the user:

Now, when you request tokens, your ID token will contain the requested name and picture claims. When you decode the ID token, it will look similar to:

{
  "name": "auth0user@...",
  "picture": "https://example.com/profile-pic.png",
  "iss": "https://auth0user.auth0.com/",
  "sub": "auth0|581...",
  "aud": "xvt...",
  "exp": 1478113129,
  "iat": 1478077129
}

Request user log in with GitHub

In addition to the usual user authentication, this example shows how to send users directly to a social identity provider, such as GitHub. For this example to work, you need to go to Auth0 Dashboard > Authentication > Social and configure the appropriate connection. Get the connection name from the Settings tab.

To send users directly to the GitHub login screen, you need to pass the connection parameter and set its value to the connection name (in this case, github) when authorizing the user:

Now, when you request tokens, your ID token will contain a sub claim with the user’s unique ID returned from GitHub. When you decode the ID token, it will look similar to:

{
  "name": "John Smith",
  "picture": "https://avatars.example.com",
  "email": "jsmith@...",
  "email_verified": true,
  "iss": "https://auth0user.auth0.com/",
  "sub": "github|100...",
  "aud": "xvt...",
  "exp": 1478114742,
  "iat": 1478078742
}

Learn more

• OAuth 2.0 Authorization Framework
• OpenID Connect Protocol
• Tokens