The OIDC-conformant authentication pipeline supports defining (such as APIs) as entities separate from applications. This lets you decouple APIs from the applications that consume them, and also lets you define third-party applications that allow external parties to securely access protected resources behind your API. If a user authenticates through a third-party application and the application requests authorization to access the user’s information or perform some action at an API on their behalf, the user will see a consent dialog. For example, this request: 
GET /authorize?
client_id=some_third_party_client
&redirect_uri=https://fabrikam.com/contoso_social
&response_type=token id_token
&__scope=openid profile email read:posts write:posts__
&__audience=https://social.contoso.com__
&nonce=...
&state=...
Will result in this user consent dialog:
Authorization - User consent and applications - consent-dialog
If the user allows the application’s request, this creates a user grant, which represents the user’s consent to this combination of application, resource server, and requested scopes. The application then receives a successful authentication response from Auth0 as usual. Once consent has been given, the user won’t see the consent dialog during subsequent logins until consent is revoked explicitly.

​
Scope descriptions

By default, the consent page will use the scopes’ names to prompt for the user’s consent. As shown below, you should define scopes using the action:resource_name format.
Authorization - User consent and applications - Consent scopes
The consent page groups scopes for the same resource and displays all actions for that resource in a single line. For example, the configuration above would result in Posts: read and write your posts. If you would like to display the Description field instead, you can do so by setting the tenant’s use_scope_descriptions_for_consent to true. This will affect consent prompts for all of the APIs on that tenant. To set the use_scope_descriptions_for_consent flag, you will need to make the appropriate call to the API: 
curl --request PATCH \
--url 'https://{yourDomain}/api/v2/tenants/settings' \
--header 'authorization: Bearer API2_ACCESS_TOKEN' \
--header 'cache-control: no-cache' \
--header 'content-type: application/json' \
--data '{ "flags": { "use_scope_descriptions_for_consent": true } }'

​
Handle rejected permissions

If a user decides to reject consent to the application, they will be redirected to the redirect_uri specified in the request with an access_denied error: 
HTTP/1.1 302 Found
Location: https://fabrikam.com/contoso_social#
    error=access_denied
    &state=...
First-party applications can skip the consent dialog, but only if the API they are trying to access on behalf of the user has the Allow Skipping User Consent option enabled. To navigate to the Allow Skipping User Consent toggle, select Applications > APIs > (select the api) > Settings > Access Settings. Note that this option only allows verifiable first-party applications to skip consent at the moment. As localhost is never a verifiable first-party (because any malicious application may run on localhost for a user), Auth0 will always display the consent dialog for applications running on localhost regardless of whether they are marked as first-party applications. During development, you can work around this by modifying your /etc/hosts file to add an entry such as the following: 127.0.0.1 myapp.example Similarly, you cannot skip consent (even for first-party applications) if localhost is used in the application’s redirect_uri parameter and is present in any of the application’s Allowed Callback URLs (found in Dashboard > Applications > Settings). Since third-party applications are assumed to be untrusted, they are not able to skip consent dialogs. If a user has provided consent but you would like to revoke it:
  1. Go to Auth0 Dashboard > User Management > Users, and click the user for whom you would like to revoke consent.
  2. Click the Authorized Applications tab,
  3. Click Revoke next to the appropriate application.

​
Password-based flows

When using the Resource Owner Password Flow, no consent dialog is involved because the user directly provides their password to the application, which is equivalent to granting the application full access to the user’s account. When redirecting to the /authorize endpoint, including the prompt=consent parameter will force users to provide consent, even if they have an existing user grant for the application and requested scopes.

​
Learn more