Auth & identity
April 12, 2023
Author: Stytch Team
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.
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:
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).
The phrases “SP” or “IdP-initiated SSO” refers to where a member begins their user authentication journey.
While these two options only slightly alter the experience for the end user, it’s the transactions behind the scenes that are crucially different.
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.
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:
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.
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.
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):
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.
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.
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.
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.