Skip to Content

The Dangers of SAML IdP-Initiated SSO

When using SAML, we have two methods for starting Single Sign On (SSO): SP-initiated or IdP-initiated. Both have their use cases, but one is more secure than the other. No points for guessing from the title.

IdP-Initiated SSO vs SP-Initiated SSO

Service Provider (SP) initiated SSO involves the SP creating a SAML request, forwarding the user and the request to the Identity Provider (IdP), and then, once the user has authenticated, receiving a SAML response & assertion from the IdP. This flow would typically be initiated by a login button within the SP.

Identity Provider (IdP) initiated SSO involves the user clicking on a button in the IdP, and then being forwarded to a SP along with a SAML message containing an assertion. This flow would typically be initiated by a page within the IdP that shows a list of all available SPs that a user can login to. Another common use case of this flow is to allow users to bookmark the IdP login page.


SP-Initiated SSO

When using SP-initiated SSO, a modern SAML solution will do the following:

  1. Generate a request ID and include it in the SAML request message
  2. Generate a relay state (either (random) application state or just as a simple CSRF mechanism) and include it in the SAML request URL
  3. Securely store the two values before redirecting to the IdP (think a cookie or a server-side cache)

When the SP then receives a SAML response it will then fetch the stored request ID and relay state values and then check them against the SAML responses InResponseTo value and relay state, respectively.

This allows us to prove that we are expecting an assertion (proven by the presence of the request ID and relay state) and that the response is intended for us (by matching the request ID and relay state).

This validation procedure is similar to the OpenID Connect usage of the state and nonce parameters.

IdP-Initiated SSO

When using IdP-initiated SSO, we do not get the same assurances as SP-initiated. Instead, the SP receives unsolicited SAML messages and assertions, and loses any protocol mechanism that allows them to detect whether that message has been stolen or replayed.

The Dangers of SAML IdP-Initiated SSO

IdP-Initiated SSO is highly susceptible to Man-in-the-Middle attacks, where an attacker steals the SAML assertion. With this stolen SAML assertion, an attacker can log into the SP as the compromised user, gaining access to their account.

It can also allow for attacks where an attacker can intercept the SAML assertion and replace it with another, causing the user to log in as the attacker.

This leaves Service Providers in a tricky place. A SP can see that the message and assertion are valid since it was issued by the expected issuer and signed with the expected key, but they cannot verify that a malicious party did not steal the assertion.

IdP-Initiated SSO Attacks

Another common complaint regarding IdP-Initiated SSO, is that it can overwrite existing sessions within a SP. However, this is more often an implementation detail rather than a limitation in the protocol’s approach.

Modern IdP-Initiated SSO

We can try and mitigate some of the flaws I this flow using the following techniques:

Follow the Specification

Section 4.1.5 (Unsolicited Responses) of the SAML 2.0 profiles specification states that a SP must ensure that any unsolicited SAML responses received do not contain an InResponseTo value. This prevents responses generated using SP-Initiated SSO from being stolen and re-used.

Use the Minimum Possible Response Trust Length

When validating SAML responses and assertions, you validate when they were issued and when they expire. The IdP can state when to no longer trust it, but the SP also gets a say. So, make sure that’s as low as possible, after all the response is probably going to be generated by the IdP and then immediately sent across to the SP. That shouldn’t take more than a few seconds.

Unfortunately, clock skew between the IdP and SP can be an issue with this validation (it is for many of our customers), so you’ll need to find an acceptable middle ground.

Replay Detection

To try and prevent responses/assertions from being re-used, a replay detection mechanism could be implemented. By remembering what responses have already been seen, we can at least stop stolen message from being reused. However, this approach does not prevent the response from being stolen and then used, or another response from being injected.

Rock Solid Knowledge Implementation

The Rock Solid Knowledge IdentityServer4 SAML component now supports IdP-initiated SSO, but only for service providers receiving assertions. This means that our SP component can still work with opinionated IdPs who only support IdP-initiated SSO. We currently do not have any plans to support IdP-initiated SSO within the IdP side of our component.

IdP-initiated SSO is available in Rsk.IdentityServer4.Saml version 2.4 onwards.

Enabling IdP-Initiated SSO

IdP-initiated SSO is disabled by default, however it can be enabled with the following configuration:

    .AddSaml2p(options =>
        // existing SP & IdP config

        options.AllowIdpInitiatedSso = true;
        options.IdPInitiatedSsoCompletionPath = "/IdP-Callback";

Once the SAML assertion has been validated and the user signed in, the user will be redirected to the path set in IdPInitiatedSsoCompletionPath. The contents of this page are up to the user.

Replay Detection

To detect replayed SAML responses, our component uses your implementation of IDistributedCache to remember SAML response IDs that it has previously received. By default, IDistributedCache falls back to an in-memory implementation. For production scenarios, we recommend using a non-volatile cache such as Redis or SQL Server.


SAML IdP-initiated SSO definitely has its flaws, however by taking lessons learned from modern applications and protocols, we can try and mitigate some of these concerns. Unfortunately, we cannot prevent assertion theft and injection, but we can at least stop replay attacks.

These mitigations do push yet more complexity onto the service provider to combat the limitations of the IdP. I’ve seen some articles advocate IdP-initiated SSO due to the fact that a SP might not be capable of creating requests, but now instead they must start caring about replay attacks. In my opinion, this is more complex to do in a load balanced environment than simply remembering a relay state in the context of the browser.

  • Hawkins Inc
  • Repower
  • Bosch
  • RandA
  • Plymouth NHS
  • American Heart Association
  • Systopia
  • Deliotte

Awards & Certifications