Single Sign-On

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 name of the feature (Single Sign-on).

For example, if you log in to a Google service such as Gmail, you are automatically authenticated to YouTube, AdSense, Google Analytics, and other Google apps. Likewise, if you log out of your Gmail or other Google apps, you are automatically logged out of all the apps; this is known as Single Logout.

SSO provides a seamless experience for users when using your applications and services. Instead of having to remember separate sets of credentials for each application or service, users can simply log in once and access your full suite of applications.

Whenever users go to a domain that requires authentication, they are redirected to the authentication domain where they may be asked to log in. If the user is already logged in at the authentication domain, they can be immediately redirected to the original domain without signing in again.

Single Sign-on and Single Logout are possible through the use of sessions. There may be up to three different sessions for a user with SSO:

• Local session maintained by the application

• Authorization Server session, if SSO is enabled

• Identity Provider (IdP) session, if the user chose to log in through an Identity Provider (such as Google, Facebook, or an enterprise SAML Identity Provider)

With SSO, a central domain performs authentication and then shares the session with other domains. The way a session is shared may differ between SSO protocols, but the general concept is the same.

For example, the authentication domain may generate a signed JSON Web Token (JWT) (encrypted using JSON Web Encryption (JWE)), which contains all the information needed to identify the user for any other domain requiring authentication. This token is passed to the client, but because it is signed, it cannot be modified in any way by the client. The token can be passed to the original domain by a redirect and used by the authentication domain and any other domains to identify the user.

The easiest and most secure way to implement Single Sign-on (SSO) with Auth0 is by using Universal Login for authentication. In fact, currently SSO is only possible with native platforms (like iOS or Android) if the application uses Universal Login. The Swift and Android quick starts provide some examples of using Universal Login.

If you cannot use Universal Login with your application, review the following for additional info on embedded authentication:

• Lock

• Auth0.js

For SSO with Auth0, the Central Service is the Auth0 Authorization Server.

Let's look at an example of the SSO flow when a user logs in for the first time:

1. Your application redirects the user to the login page.

2. Auth0 checks to see whether there is an existing SSO cookie.

3. Because this is the first time the user is visiting the login page and no SSO cookie is present, the user will be asked to log in using one of the connections you have configured.

   

4. Once the user has logged in, Auth0 will set an SSO cookie and redirect the user to your application, returning an ID Token that contains identity information for the user.

Let's look at an example of the SSO flow when a user returns to your website for a subsequent visit:

1. Your application redirects the user to the login page.

2. Auth0 checks to see whether there is an existing SSO cookie.

3. Auth0 finds the SSO cookie, and if necessary, updates it. No login screen is shown.

4. Auth0 redirects the user to your application, returning an ID Token that contains identity information for the user.

You can check a user's SSO status from an application by calling the checkSession method of the auth0.js SDK, which will attempt to silently authenticate the user within an iframe. Whether the authentication is successful or not indicates whether the user has an active SSO cookie.

Security Assertion Markup Language (SAML) and Web Services Federation (WS-Fed) are both protocols that are widely used in SSO implementations. Both SAML and WS-Fed exchange authorization and authentication data in XML format; the main parts of this exchange are the user, the identity provider, and the service provider.

With SAML or WS-Fed:

1. A user requests a resource from the service provider.

2. The service provider checks with the identity provider to see if the user should have access to the resource.

3. The identity provider verifies the user's identity, and if valid, asserts back to the service provider that the user should have access.

OpenID Connect (OIDC) is an authentication protocol commonly used in consumer-facing SSO implementations. The OIDC protocol handles authentication through JSON Web Tokens and a central identity provider.

With OIDC:

1. A user requests access to an application.

2. The application redirects the user to the identity provider for authentication.

3. The identity provider verifies the user, and if successful, prompts the user to grant data access to the application.

4. If access is granted, the identity provider generates an ID Token, which contains user identity information that the application can consume.

5. The identity provider returns the user to the application.

Lightweight Directory Access Protocol (LDAP) is an application protocol used to access a directory of credentials that can be shared by multiple applications; it is commonly used by intranets. When paired with Active Directory (AD), LDAP provides a centralized location for user identity, so the application makes an authentication request to the LDAP/AD server. The LDAP protocol exchanges information in LDAP Data Interchange Format (LDIF).

For Service-Provider-initiated SSO, Auth0 is the SSO Service Provider (SP).

When a user logs in to an application:

1. The application presents the user with one or more external identity providers.

2. The user selects an identity provider to authenticate with and logs in.

3. Upon successful authentication, the user is returned to the application.

SP-initiated SSO in Auth0 is handled by connections.

For Identity-Provider-initiated SSO, a third-party Identity Provider (IdP) is the SSO provider.

When a user logs in to an application:

1. The application redirects the user to an identity provider.

2. The third-party identity provider performs authentication and authorization.

3. Upon successful authentication, the user is returned to the application.

When planning an IdP-initiated SSO implementation, you may choose to use Auth0's SSO Dashboard Extension, which allows you to create a dashboard that lists multiple enterprise applications that can be enabled for SSO. This dashboard is then presented to your users to log in.

For Business to Business (B2B) scenarios, SSO can simplify packaging your application for enterprise consumption. With Auth0, your applications can support common enterprise federation scenarios, such as Active Directory (AD), Lightweight Directory Access Protocol (LDAP), Ping, or Security Assertion Markup Language (SAML). This allows your partners and enterprise customers to log in with their preferred enterprise identity technologies.

• Case Study: O'Reilly

For Business to Consumer (B2C) or Customer Identity Access Management (CIAM) scenarios, SSO can provide frictionless access to your applications or services. You can let customers authenticate through popular social identity providers, such as Google, Facebook, LinkedIn, Twitter, and Microsoft, instead of requiring them to make another account.

• Case Study: Giving Compass

• Service-Provider-Initiated Single Sign-On
• Identity-Provider-Initiated Single Sign-On
• API Endpoints for Single Sign-On
• Troubleshoot SAML Configurations
• Verify Connections