Authorize the User

Once you've created the code_verifier and the code_challenge, you'll need to 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 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



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

As an example, your HTML snippet for your authorization URL when adding login to your app might look like:

<a href="https://YOUR_DOMAIN/authorize?
  Sign In


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