There are two main participants involved in a single sign-on (SSO) scenario: an Authorization Server (Auth0), and multiple applications.
For privacy reasons, applications cannot query Auth0 directly to determine if a user has logged in via SSO. This means that users must be redirected to Auth0 for SSO authentication.
However, redirecting users away from your application is usually considered disruptive and should be avoided, from a UX perspective. Silent authentication lets you perform an authentication flow where Auth0 will only reply with redirects, and never with a login page.
Initiate a Silent Authentication request
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.
GET https://YOUR_AUTH0_DOMAIN/authorize ?response_type=code& client_id=...& redirect_uri=...& state=...& scope=openid...& prompt=none
prompt=none parameter will cause Auth0 to immediately redirect to the specified
redirect_uri (callback URL) with two possible responses:
- A successful authentication response if the user was already logged in via SSO
- An error response if the user is not logged in via SSO and therefore cannot be silently authenticated
Successful authentication response
If the user was already logged in via SSO, Auth0 will respond exactly as if the user had authenticated manually through the SSO login page.
For example, when using the Authorization Code Grant (
response_type=code, used for regular web applications), Auth0 will respond with an authorization code that can be exchanged for an ID Token and optionally an Access Token:
GET https://YOUR_APP/callback ?code=...& state=...& expires_in=...
Note that this response is indistinguishable from a login performed directly without the
If the user was not logged in via 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:
login_required: The user was not logged in at Auth0, so silent authentication is not possible
consent_required: The user was logged in at Auth0, but needs to give consent to authorize the application
interaction_required: The user was logged in at Auth0 and has authorized the application, but needs to be redirected elsewhere before authentication can be completed; for example, when using a redirect rule.
If any of these errors are returned, the user must be redirected to the Auth0 login page without the
prompt=none parameter to authenticate.
Renew expired tokens
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_inresponse parameter returned by Auth0
- Ignore expiration dates altogether. Instead, try to renew the Access Token if your API rejects a request from the application (such as with a 401).
In the case of the Implicit Grant, the
expires_in parameter is returned by Auth0 as a hash parameter following a successful authentication. For the Authorization Code Grant, it is returned to the backend server when performing the authorization code exchange.
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.
When the Access Token has expired, silent authentication can be used to retrieve a new one without user interaction, assuming the user's SSO session has not expired.
In the case of single-page applications, the
checkSession method from auth0.js can be used to perform silent authentication within a hidden iframe, which results in no UX disruption at all.
How to implement
Implementation of token renewal will depend on the type of application and framework being used. Sample implementations for some of the common platforms can be found below: