Configure Silent Authentication

The OpenID Connect protocol supports a prompt=none parameter on the authentication request that allows applications to indicate that the authorization server must not display any user interaction (such as authentication, consent, or MFA). Auth0 will either return the requested response back to the application, or return an error if the user is not already authenticated or if some type of consent or prompt is required before proceeding.

Use of the Implicit Flow in SPAs presents security challenges requiring explicit mitigation strategies. You can use the Authorization Code Flow with PKCE in conjunction with Silent Authentication to renew sessions in SPAs.

To initiate a silent authentication request, add the prompt=none parameter when you redirect a user to the /authorize endpoint of Auth0's authentication API. (The individual parameters on the authentication request will vary depending on the specific needs of your app.)

For example:

GET https://{yourDomain}/authorize
    ?response_type=id_token token&
    client_id=...&
    redirect_uri=...&
    state=...&
    scope=openid...&
    nonce=...&
    audience=...&
    response_mode=...&
    prompt=none

The prompt=none parameter causes Auth0 to immediately send a result to the specified redirect_uri (callback URL) using the specified response_mode with one of two possible responses: success or error.

If the user was already logged in to Auth0 and no other interactive prompts are required, Auth0 will respond exactly as if the user had authenticated manually through the login page.

For example, when using the Implicit Flow, (response_type=id_token token, used for single-page applications), Auth0 will respond with the requested tokens:

GET {https://yourApp/callback}
    #id_token=...&
    access_token=...&
    state=...&
    expires_in=...

This response is indistinguishable from a login performed directly without the prompt=none parameter.

If the user was not logged in via Single Sign-on (SSO) or their SSO session had expired, Auth0 will redirect to the specified redirect_uri (callback URL) with an error:

GET https://your_callback_url/
    #error=ERROR_CODE&
    error_description=ERROR_DESCRIPTION&
    state=...

The possible values for ERROR_CODE are defined by the OpenID Connect specification:

If any of these errors are returned, the user must be redirected to the Auth0 login page without the prompt=none parameter to authenticate.

You can make a silent authentication request to get new tokens as long as the user still has a valid session at Auth0. The checkSession method from auth0.js uses a silent token request in combination with response_mode=web_message for SPAs so that the request happens in a hidden iframe. With SPAs, Auth0.js handles the result processing (either the token or the error code) and passes the information through a callback function provided by the application. This results in no UX disruption (no page refresh or lost state).

Access Tokens are opaque to applications. This means that applications are unable to inspect the contents of Access Tokens to determine their expiration date.

There are two options to determine when an Access Token expires:

• Read the expires_in response parameter returned by Auth0.

• Ignore expiration dates altogether. Instead, renew the Access Token if your API rejects a request from the application (such as with a 401).

In the case of the Implicit Flow, the expires_in parameter is returned by Auth0 as a hash parameter following a successful authentication. In the Authorization Code Flow with PKCE, it is returned to the backend server when performing the authorization code exchange.

The expires_in parameter indicates how many seconds the Access Token will be valid for, and can be used to anticipate expiration of the Access Token.

You may receive the timeout error response which indicates that timeout during executing web_message communication has occurred. This error is typically associated with fallback to cross-origin authentication. To resolve, make sure to add all of the URLs from which you want to perform silent authentication in the Allowed Web Origins field for your Application using the Auth0 Dashboard.

In some multi-application scenarios, where Single Logout is desired (a user logging out of one application needs to be logged out of other applications), an application can be set up to periodically poll Auth0 using checkSession() to see if a session exists. If the session does not exist, you can then log the user out of the application. The same polling method can be used to implement silent authentication for a Single Sign-on (SSO) scenario.

The poll interval between checks to checkSession() should be at least 15 minutes between calls to avoid any issues in the future with rate limiting of this call.

In some scenarios, you may want to avoid prompting the user for Multi-factor Authentication (MFA) each time they log in from the same browser. To do this, set up a rule so that MFA occurs only once per session. This is useful when performing silent authentication (prompt=none) to renew short-lived Access Tokens in a SPA during the duration of a user's session without having to rely on setting allowRememberBrowser to true.

function (user, context, callback) {
  let authMethods = [];
  if (context.authentication && Array.isArray(context.authentication.methods)) {
    authMethods = context.authentication.methods;
  }

  const completedMfa = !!authMethods.find((method) => method.name === 'mfa');

  if (completedMfa) {
    return callback(null, user, context);
  }

  context.multifactor = {
    provider: 'any',
    allowRememberBrowser: false
  };

  callback(null, user, context);
}

To learn more, see Change Authentication Request Frequency.

• Refresh Token Rotation
• Configure Refresh Token Rotation
• Troubleshoot Invalid Token Errors
• Check API Calls
• Troubleshoot Multi-Factor Authentication Issues