Introduction to Single Sign On with Auth0
Single Sign On (SSO) occurs when a user logs in to one application and is then signed in to other applications automatically, regardless of the platform, technology, or domain the user is using. The user signs in only one time, hence the naming of the feature (Single Sign On).
Google's implementation of login for their products, such as Gmail, YouTube, Google Analytics, and so on, is an example of SSO. Any user that logs in to one of Google's products are automatically logged in to their other products as well.
Single Sign On usually makes use of a Central Service which orchestrates the single sign on between multiple clients (applications). In the example of Google, this central service is Google Accounts.
When a user first logs in, Google Accounts creates a cookie, which persists with the user as they navigate to other Google-owned services. The process flow is as follows:
- The user accesses the first Google product.
- The user receives a Google Accounts-generated cookie.
- The user navigates to another Google product.
- The user is redirected again to Google Accounts.
- Google Accounts sees that the user already has an authentication-related cookie, so it redirects the user to the requested product.
What is single log out?
Single Logout is the process where you terminate the session of each application or service where the user is logged in. To continue with the Google example, if you logout from Gmail, you get logged out also from YouTube, Google Analytics, and so on.
There may be up to three different layers of sessions for a user with SSO.
- A session from an Identity Provider such as Google, Facebook or an enterprise SAML Identity Provider
- A session from Auth0 if the above SSO flag is turned on
- A session maintained by an application
See the Logout URL docs for information on terminating the first two sessions listed above.
An overview of how SSO works with Auth0
In the case of SSO with Auth0, the Central Service is the Auth0 Authorization Server.
Let's look at an example of how the SSO flow looks when using Auth0 and the Lock widget and a user visits your application for the first time:
Your application will redirect the user to the login page where they can log in.
Auth0 will check to see whether there is an existing SSO cookie.
Because this is the first time the user visits this login page, and no SSO cookie is present, they may be presented with username and password fields and also possibly some Social Identity Providers such as LinkedIn, GitHub, etc. (The exact layout of the Lock screen will depend on the Identity Providers you have configured.
Once the user has logged in, Auth0 will set an SSO cookie.
Auth0 will also redirect back to your web application and will return an ID Token containing the identity of the user.
Now let's look at flow when the user returns to your website for a subsequent visit:
- Your application will redirect the user to the login page.
- Auth0 checks to see if there is an existing SSO cookie.
- Auth0 finds the SSO cookie, and if necessary, updates it.
- Auth0 returns an ID Token containing identity information for the user.
Please note that the user is never shown a login screen at any point during the above steps.
SSO with native platforms
Currently, SSO is only possible with native platforms (such as iOS or Android) if the application uses the Universal Login for authentication.