Back to Blog

IDP- vs. SP-initiated SAML single sign-on

A minimally technical introduction to IDP-initiated and SP-initiated SAML
profile picture
Ned O'Leary
X GitHub
Cofounder and CEO, SSOReady

Enterprise SSO vs. social login

When people talk broadly about SSO, they’re sometimes talking about OAuth, the JSON-based protocol that powers social logins like Sign in with Google or Sign in with Facebook. Developers often find OAuth fairly easy to support. At minimum, services like Sign in with Google come with abundant, clear documentation.

At SSOReady, when we say “SSO”, we mean enterprise SSO.

Enterprise SSO doesn’t use OAuth. Enterprise SSO relies on an XML-based protocol called SAML, and it works a bit differently.

Foundational concepts

Two kinds of software get involved in a SAML login:

  1. A service provider
  2. An identity provider

A service provider (or SP) is software that a user wants to access. For example, a user at AcmeCorp might need to join a video conference on Zoom. AcmeCorp’s internal IT team requires that users sign in to Zoom via SAML. In this case, Zoom is the service provider.

The identity provider (or IDP) is a different software application. It stores important user details and governs users’ access to applications like Zoom (i.e. SPs). The name single sign-on describes signing in to the IDP.

The SP and the IDP will have a pre-configured trust relationship. The SP accepts the IDP’s claims about user identity.

The service provider cannot grant a user access without communicating (indirectly via the browser) with the identity provider. It needs to receive trusted claims from the IDP. Distinct user login flows

Given that the user needs both to sign on to the IDP and to access the SP, one might notice that the user has two ways to initiate a SAML login:

  1. Attempt first to access the service provider
  2. Log in first through the identity provider

The first scenario above is known as SP-initiated SAML login. The user attempts first to access the service provider. The service provider has no information regarding the user’s identity. However, it commonly prompts the user for an email address, based on which it redirects the user to a preconfigured IDP. The IDP authenticates the user, then returns the user to the service provider. Here’s an example from Okta:

The second scenario, in which the user starts with the IDP, is called IDP-initiated SAML login. IDPs often come with interfaces from which end users can launch applications. I’ve included an example here of an Okta dashboard – from here, users can click tiles to launch your application.

When the user requests access to the service provider via IDP-initiated SAML, the service provider subsequently receives authentication details from the user’s browser. (The service provider does not interact directly with the IDP.) The SP will never have redirected the user to the IDP, so there’s some sense in which the login event is ‘unexpected.’

Why it’s important

Some developers implementing SAML login for the first time will neglect to handle IDP-initiated login flows. Their design will assume users initiate SAML login from the SP side.

This can result in a suboptimal user experience, especially because some customers will prefer their users to sign in via an IDP-initiated flow.

Make sure your application works properly for both types of SAML login.

If you use SSOReady for SAML SSO, you won’t need to worry about this. You’ll get both SP-initiated and IDP-initiated login by default.