In order to access an API from a client-side app (typically a Single Page Application or a Mobile Application), you need to implement the OAuth 2.0 Implicit Grant. In this document we will see how this flow works.
The Implicit Grant (defined in RFC 6749, section 4.1) is similar to the Authorization Code Grant, but the main difference is that the application receives an access_token directly, without the need for an
client_secret (which is required in the Authorization Code Grant). Also, in the Implicit Grant, no Refresh Tokens are returned for the same reason (for an alternative refer to Silent authentication for SPAs).
Once the user authenticates, the application receives the
access_token in the hash fragment of the URI. The application can now use this
access_token to call the API on behalf of the user.
The app initiates the flow and redirects the browser to Auth0 (specifically to the /authorize endpoint), so the user can authenticate.
Auth0 authenticates the user. The first time the user goes through this flow a consent page will be shown where the permissions, that will be given to the Application, are listed (for example: post messages, list contacts, and so forth).
The app can use the
access_tokento call the API on behalf of the user.
How to implement the flow
For details on how to implement this using Auth0, refer to Execute an Implicit Grant.
Rules will run for the Implicit grant. If you wish to execute special logic unique to the Implicit grant, you can look at the
context.protocol property in your rule. If the value is
oidc-implicit-profile, then the rule is running during the Implicit grant.
For details on how to implement this, refer to How to implement the Implicit Grant: Customize the Tokens.
If you need to authenticate your users without a login page (for example, when the user is already logged in via SSO scenario) or get a new
access_token (thus simulate refreshing an expired token), you can use Silent Authentication.
For details on how to implement this, refer to Silent Authentication.