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 client app receives an access_token directly, without the need for an authorization_code. This happens because the client app, 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 for are returned, for the same reason (for an alternative refer to Silent authentication for SPAs).

Once the user authenticates, the client app receives the access_token in the hash fragment of the URI. The client app 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 Client, 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 a 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 Client, 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

 How to implement the Implicit Grant
 How to protect your SPA against replay attacks
 Silent authentication for SPAs
 How to configure an API in Auth0
 Why you should always use access tokens to secure an API
 Single Page App Quickstarts
 ID Token
 Access Token
 Client Authentication for Client-side Web Apps
 Authentication API: GET /authorize
 The OAuth 2.0 protocol
 The OpenID Connect protocol
 Tokens used by Auth0
 RFC 6749: The OAuth 2.0 Authorization Framework