SP-Initiated v IdP-Initiated SSO

Learn the key differences between SP-initiated SSO and IdP-initiated authentication.

In this article, we'll outline how authentication works when initiated from the Service Provider (SP) and from the Identity Provider (IdP). We’ll use the terms SP-initiated SSO and SP-initiated authentication interchangeably.

When do SaaS companies use SP-initiated authentication?

In the context of a SaaS application, SP-initiated authentication happens when the application exposes a login button for users to gain access to the software product. In this case, the SaaS application is the Service Provider and the application makes the authentication request to the Identity Provider via the Internet browser.

SP-initiated SSO is commonly used by consumer-facing apps where individual users can login to the application themselves to gain access. In fact, it’s the most common form of SSO that new WorkOS customers start with when they are becoming Enterprise Ready because most enterprise customers require it.

How does SP-initiated SSO work?

Suppose a user of a SaaS product initiates the authentication process by clicking on a login button within the application. The application will generate a request ID and a RelayState, then send those values along with the SAML Authentication Request to the Identity Provider via the browser. 

The SaaS application will store the request ID and the RelayState. When the Identity Provider returns a SAML response it will include the request ID and RelayState provided by the SaaS application. The SaaS application will then check those values against the stored values to ensure a match.

For a more detailed explanation of Single Sign On (SSO), check out The Developer's Guide to SSO on the WorkOS blog.

A chart showing the successful SP-initiated SAML authentication flow. The end-user enters login credentials into the app, then gets redirected to the IdP for authentication, and eventually is redirected back to the app after successful authentication.

When do SaaS companies use Identity Provider-initiated authentication?

If users of the SaaS product can access it by first logging into an Identity Provider, then clicking a button or a link to be automatically logged into the SaaS product, Identity Provider-initiated authentication is happening behind the scenes. Often, once a user is logged into their Identity Provider, they can select from a number of Service Providers to which they can be forwarded.

How does IdP-initiated authentication work?

Suppose an employee successfully logs into their employer's Identity Provider. They navigate to the dashboard which shows a variety of Service Providers the employee is able to access and they click on the desired Service Provider.

The Identity Provider then creates an SSO response and a SAML 2.0 Assertion which contains authentication details, information about the user, and the RelayState parameter. The Service Provider receives the SSO response from the Identity Provider via the browser, validates the SAML 2.0 Assertion, then generates a session for the user.

Integrating SSO with WorkOS provides the opportunity to offer both SP-initiated and Identity Provider-initiated authentication flows to your SaaS customers and is a pivotal step in becoming an Enterprise Ready business. 

If you have any questions about either of these authentication flows and how to offer them to your customers with a WorkOS integration, please reach out to us at and we’ll be happy to help.

In this article

This site uses cookies to improve your experience. Please accept the use of cookies on this site. You can review our cookie policy here and our privacy policy here. If you choose to refuse, functionality of this site will be limited.