Authorization Code Flow with Proof Key for Code Exchange (PKCE)
Overview
Key Concepts
Learn about the OAuth 2.0 grant type, Authorization Code Flow with Proof Key for Code Exchange (PKCE).
Use this grant type for applications that cannot store a client secret, such as native or single-page apps.
Review different implementation methods with Auth0 SDKs.
When public clients (e.g., native and single-page applications) request access tokens, some additional security concerns are posed that are not mitigated by the Authorization Code Flow alone. This is because:
Native apps
Cannot securely store a Client Secret. Decompiling the app will reveal the Client Secret, which is bound to the app and is the same for all users and devices.
May make use of a custom URL scheme to capture redirects (e.g., MyApp://) potentially allowing malicious applications to receive an Authorization Code from your Authorization Server.
Single-page apps
Cannot securely store a Client Secret because their entire source is available to the browser.
Given these situations, OAuth 2.0 provides a version of the Authorization Code Flow which makes use of a Proof Key for Code Exchange (PKCE) (defined in OAuth 2.0 RFC 7636).
The PKCE-enhanced Authorization Code Flow introduces a secret created by the calling application that can be verified by the authorization server; this secret is called the Code Verifier. Additionally, the calling app creates a transform value of the Code Verifier called the Code Challenge and sends this value over HTTPS to retrieve an Authorization Code. This way, a malicious attacker can only intercept the Authorization Code, and they cannot exchange it for a token without the Code Verifier.
How it works
Because the PKCE-enhanced Authorization Code Flow builds upon the standard Authorization Code Flow, the steps are very similar.
The user clicks Login within the application.
Auth0's SDK creates a cryptographically-random
code_verifierand from this generates acode_challenge.Auth0's SDK redirects the user to the Auth0 Authorization Server (
/authorizeendpoint) along with thecode_challenge.Your Auth0 Authorization Server redirects the user to the login and authorization prompt.
The user authenticates using one of the configured login options and may see a consent page listing the permissions Auth0 will give to the application.
Your Auth0 Authorization Server stores the
code_challengeand redirects the user back to the application with an authorizationcode, which is good for one use.Auth0's SDK sends this
codeand thecode_verifier(created in step 2) to the Auth0 Authorization Server(/oauth/tokenendpoint).Your Auth0 Authorization Server verifies the
code_challengeandcode_verifier.Your Auth0 Authorization Server responds with an ID token and access token (and optionally, a refresh token).
Your application can use the access token to call an API to access information about the user.
The API responds with requested data.
If you have Refresh Token Rotation enabled, a new Refresh Token is generated with each request and issued along with the Access Token. When a Refresh Token is exchanged, the previous Refresh Token is invalidated but information about the relationship is retained by the authorization server.
How to implement it
The easiest way to implement the Authorization Code Flow with PKCE is to follow our Native Quickstarts or follow our Single-Page Quickstarts.
Depending on your application type, you can also use our mobile or single-page app SDKs:
Mobile
Single-page
Recent advancements in user privacy controls in browsers adversely impact the user experience by preventing access to third-party cookies; therefore, browser-based flows must use Refresh Token Rotation, which provides a secure method for using refresh tokens in SPAs while providing end-users with seamless access to resources without the disruption in UX caused by browser privacy technology like ITP.
You can follow our tutorials to use our API endpoints to Add Login Using the Authorization Code Flow with PKCE or Call Your API Using the Authorization Code Flow with PKCE.