IdP- vs SP-initiated SSO

In today’s world where the average business manages 88 applications, single sign-on has become indispensable. IT professionals looking to manage their company’s identity and access management, from user authentication to identity providers, rely on SSO to simplify work streams for them and the users they manage.

But not all single sign-on solutions are created equally.

As we covered in-depth in our B2B Auth School series, there are two main technical protocols used for single sign on today: Security Assertion Markup Language (SAML) and OpenID Connect (OIDC). Within SAML, there are two main types of login flows: those initiated by identity providers, and those initiated with service providers.

In this blog post, we’ll look at the differences between these two forms of SAML single sign-on, and their implications for developers looking to incorporate SSO capabilities into their application.

Recap: what is SAML and how does it work?

Security Assertion Markup Language, or SAML, is the legacy standard protocol for single sign on. Specifically, SAML standardizes the exchange of authentication and authorization data between parties, most commonly for single sign-on transactions. Those parties are typically defined as:

• Service Provider (SP): the B2B app or website that users attempt to log into. In SAML, they receive both user identities and control user access to resources from the Identity Provider via a SAML assertion. 
• Identity Provider (IdP): the service that maintains user identities and issues SAML responses on behalf of the B2B customer (i.e. Okta, OneLogin). 
• Auth provider: a 3rd party or in-house auth solution that interfaces and coordinates auth flows between identity providers and service providers.
• B2B customer: the customers of the SP (usually a company or businesses) that wish to log into the service provider’s application with SSO, and use an identity provider for identity management.
• Member: also often referred to as a user, the member in B2B authentication is the end user who is a part of the B2B customer’s organization within the service provider’s app. They are the person or machine attempting to authenticate (or “gain user access”) to resources within the service provider using their identity provider. 

SAML standardizes transactions between these different parties through requests and responses written in extensible markup language (XML) (for a closer look at how these SAML messages work, check out our in-depth blog on SAML transactions).

SP vs. IdP SSO: a crucial difference

The phrases “SP” or “IdP-initiated SSO” refers to where a member begins their user authentication journey.

1. SP-initiated: they can start their login journey with the service provider, which will then redirect them to the identity provider for authentication, OR
2. IdP-initiated: they can start their login journey directly with their identity provider, and once authenticated they can navigate to the service provider they wish to access.

While these two options only slightly alter the experience for the end user, it’s the transactions behind the scenes that are crucially different.

SP-initiated 

1. A member of an organization (likely an employee of a company) goes to log in to the app they want to use (i.e., the SP).
2. The service provider then redirects that member to their company’s identity provider, with a SAML request. Among other pieces of information, this request contains two key parameters: a requestID, that uniquely identifies this authentication request, and a RelayState, which can be a string of any value added to the SAML request URL. These two parameters are used later to verify that the IdP’s response is in fact intended for this user and this SP.
3. Once redirected, the member authenticates with the identity provider.
4. After the member has authenticated, the identity provider then creates a SAML response with all the relevant information about that member (their ID, what resources they’re authorized to access). This response also includes an InResponseTo field that verifies requestID, as well a separate parameter verifying the RelayState
5. When the SP receives the IdP’s SAML assertion, it checks the requestID and RelayState against the ones in its records, to make sure the correct request is being addressed by the IdP.
6. Upon receipt and verification of the SAML response by the SP, the user is logged in.

IdP-initiated 

1. Instead of going to the SP, the member begins by logging in directly to their IdP.
2. Once authenticated, the member can then see all of the apps and resources their company has granted them access to. They select the app or service they want to use.
3. The IdP then creates the SAML assertion, and redirects the member to the SP. Like with SP-initiated SSO, this assertion contains information about the user and resources they can access, but it does not contain a requestID or RelayState.
4. Assuming the SP accepts the assertion, the member is then logged in.

The main difference then, between IdP and SP-initiated SSO on the backend amounts to one additional redirect and two additional parameters.

As we’ll see in the next section, those components can make a world of difference.

IdP-initiated vulnerabilities

Without the requestID and RelayState in IdP-initiated SSO, there is no way for the SP to verify that the SAML assertion they’re receiving corresponds to the right request.

In other words, if a hacker or bad actor were to gain access to an IdP-initiated SAML assertion, they could access the member’s account with the SP application, even if the member themselves did not request it.

In this “man-in-the-middle” type of attack, the SAML assertion is intercepted on its way from the IdP to the SP, as follows:

1. 1. The member logs in directly to their IdP.
   2. Once authenticated, the member can then see all of the apps and resources their company has granted them access to. They select the app or service they want to use.
   3. The IdP then creates the SAML assertion, and redirects the member to the SP. Like with SP-initiated SSO, this assertion contains information about the user and resources they can access, but it does not contain a requestID or RelayState.
   4. The hacker-in-the-middle intercepts the SAML assertion before it reaches the SP.
   5. At this point, the hacker will either log into the SP posing as the organization member, or it can replace the IdP’s SAML assertion with another that logs the member into the SP as the attacker.
   6. When the SP receives the SAML assertion, all they have to go off of are the issuer (the IdP) and the signature, which, if the hacker leaves them untampered, will appear valid.

In each of these scenarios, without additional security measures, there’s no way to verify this SAML assertion is in fact resulting from a legitimate member’s authentication request.

A SAML-only issue

If you’ve read any of our B2B auth school series, you’ll know that SAML is now one of two major protocols for single sign on – OpenID Connect, or OIDC is the other.

IdP-initiated SSO is not a concern with OIDC though because it is not possible with that protocol. By design and because of its direct evolution from OAuth 2.0, OIDC authentication is token-based, with identity tokens that are designed to be read and validated by the same application that made the authorization request. Even in cases where members begin the authentication process from a third party that is not the service provider (or what’s called the relying party or RP in OIDC), the member is still first directed to the RP initiation endpoint, and begins the transaction almost identically to a true RP (or in SAML’s case, SP) initiated SSO login.

XML is more flexible, but as we’ve seen, that flexibility comes with risk. 

Protecting IdP-initiated SSO

So what’s to be done? There are a few steps that can be taken to thwart these attacks, but they unfortunately put the onus on the SP (and/or the SP’s authentication provider):

Beware the unsolicited InResponseTo

The SAML 2.0 specification warns that an SP must not validate any unsolicited SAML responses they receive from IdPs that contain the InResponseTo parameter. This indicates a prior SP-initiated SAML assertion has been intercepted from the IdP and is being falsely re-used in an attempt to gain unauthorized access to the member’s account.

Set tight validity periods

Both the IdP and the SP have the power to set the validity period (the time for which a SAML assertion is considered trustworthy or valid). Generally, no IdP should take more than a couple minutes to issue a SAML assertion, so any time longer than that and you risk leaving your application open to those attacks. Standard constraints include NotBefore and NotOnOrAfter.

Replay detection

In addition to setting tight expiry windows on your SAML assertions, SPs can also track which messages have already been used and prevent those from being reused by hackers. That said, replay detection does not protect against hackers intercepting unused SAML assertions.

Dealing with SAML for your product

Despite these vulnerabilities, many B2B customers today still prefer IdP-initiated SSO. This is in part because from their IT department’s perspective, certain aspects of user identity and authentication services are easier to manage with centralized, gated, access to all their different apps and services. 

But this means that service providers working with these IdPs then need to work very carefully with either their in-house auth team or their auth provider to put all necessary precautions in place to protect their customers and users from IdP-initiated SSO vulnerabilities. None of the solutions above are ironclad, so it’s doubly important to have dedicated conversations with your customers and your auth provider about how best to offer protection with their preferred SSO method. 

If these challenges sound like something you’d like to talk to an auth provider about, we’d love to chat about our own SSO solutions.