Service-Provider-Initiated Single Sign-On

Overview of Single Sign-on (SSO) initiated by a Service Provider (SP).

For Service-Provider-initiated Single Sign-On (SSO) implementations, 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 (IdPs).
2. The user selects an IdP to authenticate with and logs in.
3. Upon successful authentication, the user is returned to the application with an active session.

SP-initiated SSO in Auth0 is handled by connections.

Auth0 SSO sessions vs. application sessions

When users log in, various session layers can be created. For SP-initiated SSO implementations, it’s important to understand that the SSO experience is made possible by the Auth0 Session Layer, which is stored centrally on the Authorization Server. Leveraging this session layer, users can easily authenticate to different applications, each of which may have its own application session to track whether the user is logged in to it specifically.

Build your own implementations

OIDC/OAuth

• Social Identity Providers
• Add a generic OAuth2 Authorization Server to Auth0
• Auth0 Marketplace

SAML

• Auth0 provides instructions to configure the following SAML IdPs with Auth0:

  • Okta
  • OneLogin
  • PingFederate 7
  • Salesforce
  • SiteMinder
  • SSOCircle

• We also provide generic instructions to configure Auth0 as a SAML service provider.

• Configure Identity-Provider-Initiated Single Sign-On

Limitations

• Native applications can only use Universal Login.
• OpenID Connect (OIDC) does not support IdP-initiated SSO.

Learn more

• Identity-Provider-Initiated Single Sign-On
• API Endpoints for Single Sign-On
• Troubleshoot SAML Configurations
• Troubleshoot SAML Errors