/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.
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.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 Proof Key for Code Exchange spec.
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.
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 , 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
.
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 (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. |
HTTP 302
response. The authorization code is included at the end of the URL:
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
.
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. |
access_token
, refresh_token
, id_token
, and token_type
values:
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.
connection
parameter and set its value to the connection name (in this case, github
) when authorizing the user:
sub
claim with the user’s unique ID returned from GitHub. When you decode the ID token, it will look similar to: