Call APIs from Client-side Web Apps

Heads up! As part of our efforts to improve security and standards-based interoperability, we have implemented several new features in our authentication flows and made changes to existing ones. For an overview of these changes, and details on how you adopt them, refer to Introducing OIDC Conformant Authentication.

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.

If you need a refresher on the OAuth 2.0 protocol, you can go through our OAuth 2.0 article.


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 authorization_code. This happens because the application, which is typically a JavaScript app running within a browser, is less trusted than a web app running on the server, hence cannot be trusted with the 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.

Implicit Grant

  1. The app initiates the flow and redirects the browser to Auth0 (specifically to the /authorize endpoint), so the user can authenticate.

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

  3. Auth0 redirects the user to the app with an Access Token (and optionally an ID Token) in the hash fragment of the URI. The app can now extract the tokens from the hash fragment. In a Single Page Application (SPA) this would be done using Javascript and in a Mobile Application this is typically handled by interacting with a Web View.

  4. The app can use the Access Token to call the API on behalf of the user.

In OAuth 2.0 terms, the web app is the Application, the end user the Resource Owner, the API the Resource Server, the browser the User Agent, and Auth0 the Authorization Server.

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.

Silent Authentication

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.

Keep reading