Docs

IdP-Initiated Single Sign-On

Many instructions for setting up a SAML federation begin with Single Sign-on (SSO) initiated by the service provider. The service provider redirects the user to the identity provider for the purposes of authentication. This process is commonly used for consumer-facing scenarios.

However, in enterprise scenarios, it is sometimes common to begin with the identity provider initiating SSO, not the service provider. For example, an enterprise company might set up a portal to ensure that users navigate to the correct application after they sign on to the portal.

Risks of using an IdP-Initiated SSO flow

IdP-Initiated flows carry a security risk and are therefore NOT recommended. Make sure you understand the risks before enabling IdP-Initiated SSO.

In an IdP-initiated flow neither Auth0 (which receives the unsolicited response from the Identity Provider) nor the application (that receives the unsolicited response generated by Auth0) can verify that the user actually started the flow. Because of this, enabling this flow opens the possibility of an Login CSRF attack, where an attacker can trick a legitimate user into unknowingly logging into the application with the identity of the attacker.

The recommendation is to use SP-Initiated flows whenever possible.

On IdP-Initiated flows and OpenID Connect

OpenID Connect (OIDC) does not support the concept of an IdP-Initiated flow. So while Auth0 offers the possibility of translating a SAML IdP-Initiated flow (from a SAML connection) into an OIDC response for an application, any application that properly implements the OIDC/OAuth2 protocol will reject an unrequested response.

When using OIDC applications, the best option is to have the users start the login flow at the application or configure the portals to send the user to the application's login initiation endpoint (without an IdP-Initiated SAML response) so that, again, the application starts the authentication flow.

How to set up IDP-initiated SSO

To setup IdP-Initiated SSO, go to the Enterprise Connections section of the dashboard and choose SAMLP Identity Provider. Under the Settings section you can see the configuration for IdP-Initiated SSO.

Default Application: When the IdP initiated login succeeds this is the application where users are routed. This setting shows available applications enabled for this connection. Select the application from the dropdown that you want the users to login with IdP initiated. Only one application can be selected for an IdP-initiated login per SAML connection.

Response Protocol: This is the protocol used to connect your selected Default Application. Most commonly applications are configured with the OpenID Connect protocol (read here for possible pitfalls). However if you have configured a SAML2 Web App addon for your application and want to route the SAML assertion you will need to select SAML.

Query String: Query string options help to customise the behavior when the OpenID Connect protocol is used. You can set multiple options similar to setting parameters with a query string. You can set:

  • redirect_uri: When the IdP-initiated login has completed the request is then redirected to the first URL listed in the Allowed Callback URLs for the application. However if you set a redirect_uri the IdP will redirect to this URL. This brings flexibility for cases like when you have set subdomain scheme with a wildcard and you only want to redirect to one specific subdomain.
  • scope: You could define scopes for the ID Token sent. Note that it is possible to set multiple scopes.
  • response_type: This field is used to set the token for Implicit Grant Flow for SPA applications. You could set code for Authorization Code Grant Flow for regular web applications.

Example Query String:

redirect_uri=https://jwt.io&scope=openid email&response_type=token

Post-back URL

When using IdP-Initiated SSO, please make sure to include the connection parameter in the post-back URL: https://YOUR_DOMAIN/login/callback?connection=YOUR_CONNECTION_NAME

Lock/Auth0.js

If your application is a Single-Page Application that uses Lock or Auth0.js to process the authentication results, you will have to explicitly indicate that you want to allow IdP-Initiated flows (and thus open the application to possible Login CSRF attacks).

If you are using Auth0.js, you have to update the webAuth.parseHash of the library and set the flag __enableIdPInitiatedLogin to true.

If you're using Lock, you can include the flag using the options parameter sent to the constructor.

Here's the flag itself:

Note that the enableIdPInitiatedLogin flag is preceded by one underscore when used with Lock and two underscores when used with the auth0.js library.