Why SP-initiated SSO is more secure than IdP authentication

Learn the key differences between SP-initiated SSO and IdP-initiated authentication, as well as the security vulnerabilities inherent to IdP authentication.

In this article, we'll outline how authentication works when initiated from the Service Provider (SP) and from the Identity Provider (IdP), as well as what the security implications are of using IdP-initiated logins. 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.

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.

IdP-initiated authentication is not used as often as SP-initiated authentication due to the security concerns outlined below. Most usage of this type is by enterprise companies that give their employees access to all eligible software products they can login to through an IdP's dashboard.

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.

Why is IdP-initiated authentication less secure than SP-initiated authentication?

IdP-initiated authentication is inherently less secure than SP-initiated authentication because the Service Provider is receiving an unsolicited authentication request from the Identity Provider, and there's no way for the Service Provider to detect if the request has been spoofed or hacked by an unauthorized user. Stealing a SAML Assertion in this way is called a "man-in-the-middle" attack.

At WorkOS, we recommend using SP-initiated SSO wherever possible.

How can the security vulnerabilities of IdP-initiated authentication be mitigated?

Despite the security vulnerability of IdP-initiated authentication, there are still two valid use cases for it:

  1. A Service Provider wants their product to be accessible to users that have logged into an Identity Provider, often to appeal to Enterprise customers.
  2. An Enterprise customer wants a specific Service Provider to be accessible to employees via an Identity Provider's dashboard.

Thus, it makes sense for Service Providers to put some guardrails in place to minimize the risk of a security breach by an attacker or unauthorized user. The Service Provider should ensure that:

  1. None of the unsolicited SAML responses it receives contain an InResponseTo value. This prevents the use of stolen or re-used SAML responses.
  2. Not too much time has elapsed since the IdP-initiated SAML response was issued. Typically, anything longer than 5-10 seconds is considered insecure.

Even when integrating with WorkOS, it’s the Service Provider’s (SaaS provider’s) responsibility to mitigate the risks of IdP-initiated authentication to their satisfaction.

Stick with SP-initiated SSO

Authentication flows that begin with the Service Provider are inherently more secure than those that begin with an Identity Provider. If you must use IdP-initiated authentication, be sure to put guardrails in place to minimize the risk of a man-in-the-middle attack.

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. 

The most secure way to set up your integration with WorkOS is with SP-initiated SSO. This is when the user starts from your application and is sent to their Identity Provider (IdP) to log in, and then redirected back to your application. Another less secure flow is IdP-initiated SSO. In this setup, the user logs in to their IdP and is redirected to your application directly from the IdP.

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 [email protected] and we’ll be happy to help.

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.