SP-Initiated vs IdP-Initiated SSO: Security Guide

SP-Initiated vs IdP-Initiated SSO: Trust Directions and Security Mechanics

In Single Sign-On (SSO) implementations using SAML 2.0, the entry point of the authentication flow dictates the security model, data integrity, and user experience. While both flows achieve the same end state—a valid authentication assertion—the mechanisms differ significantly in how trust is established and how data is transmitted. Understanding the distinction between Service Provider (SP)-initiated and Identity Provider (IdP)-initiated flows is critical for preventing security vulnerabilities such as phishing and relay state manipulation. The SP-Initiated flow, where the application requests authentication, is generally considered the more secure default, though IdP-initiated flows have specific use cases.

The SP-Initiated Flow: User-Driven Trust

In an SP-initiated flow, the user attempts to access a specific resource at the Service Provider (the application). The SP does not yet know who the user is, so it initiates the authentication handshake by redirecting the user’s browser to the IdP.

Mechanism

1. Request: The user navigates to https://app.example.com/dashboard.
2. Redirect: The SP generates a AuthnRequest XML document, signs it with its private key, and URL-encodes it. It redirects the user’s browser to the IdP’s Single Sign-On Service URL, passing the encoded request and a RelayState parameter.
3. Authentication: The IdP validates the request signature, checks if the user is already authenticated, and prompts for credentials if necessary.
4. Response: The IdP constructs an Assertion, signs it, and redirects the browser back to the SP’s Assertion Consumer Service (ACS) URL. Crucially, the RelayState value from the initial request is echoed back in this response.
5. Validation: The SP verifies the signature, checks the assertion validity period, and uses the RelayState to restore the user’s original context.

RelayState Handling

The RelayState parameter is a carrier token that allows the SP to maintain state across the SAML exchange. It typically contains a URL or a session identifier that tells the SP where to redirect the user after successful authentication.

From a security perspective, RelayState must be validated. If the SP blindly trusts the RelayState value returned by the IdP, an attacker could manipulate the initial redirect URL to include a malicious RelayState pointing to a phishing site. After authentication, the IdP (being a trusted party in the user’s eyes) redirects the user to this malicious URL. This is known as an open redirect vulnerability.

<!-- Example AuthnRequest with RelayState -->
<samlp:AuthnRequest 
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
    Destination="https://idp.example.com/sso"
    ID="_id123"
    IssueInstant="2023-10-01T12:00:00Z">
    
    <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
        https://app.example.com
    </saml:Issuer>
    
    <!-- The RelayState is passed in the query string, not inside the XML -->
    <!-- https://idp.example.com/sso?SAMLRequest=...&RelayState=/dashboard -->
</samlp:AuthnRequest>

The IdP-Initiated Flow: IdP-Driven Assertion

In an IdP-initiated flow, the user starts at the Identity Provider (e.g., https://idp.example.com). The IdP presents a list of available applications. The user selects an application, and the IdP pushes an authentication assertion directly to that application without the SP initiating the request.

Mechanism

1. Selection: The user logs into the IdP and clicks on "Access App X" from the dashboard.
2. Unsolicited Request: The IdP generates an AuthnRequest (or skips it entirely in some profiles, sending just the assertion) directed at the SP’s ACS URL. Note that in many IdP-initiated flows, the IdP sends an unsolicited assertion, meaning no prior AuthnRequest was received from the SP.
3. Response: The IdP redirects the browser to the SP’s ACS URL, attaching the signed Assertion.
4. Validation: The SP receives the assertion, validates the signature, and logs the user in.

The Problem with Unsolicited Responses

The term "unsolicited" refers to the fact that the SP did not ask for this assertion. In a strict SAML 2.0 implementation, an SP should only accept assertions in response to a valid AuthnRequest. However, many IdPs send unsolicited assertions for convenience.

This creates a security risk. If the SP accepts unsolicited assertions from any IdP, an attacker could craft a malicious IdP and send a forged assertion to the SP, potentially gaining unauthorized access. To mitigate this, SPs must strictly validate the Issuer of the assertion against a whitelist of trusted IdPs.

Security Implications: Phishing and Context Loss

Phishing Vulnerability in IdP-Initiated Flows

IdP-initiated flows are more susceptible to phishing attacks because the user is already authenticated at the IdP. If an attacker can trick a user into clicking a link that mimics an IdP application launch, the IdP may redirect the user to a malicious SP that accepts unsolicited assertions. Since the user is already logged into the IdP, they may not notice the redirect to a fake application.

In contrast, SP-initiated flows are more secure because the SP controls the initial redirect. The user must first visit the legitimate SP URL, which ensures the context is correct before the IdP is involved.

Context Loss in IdP-Initiated Flows

In IdP-initiated flows, the RelayState is often absent or limited. The IdP typically redirects the user to a default landing page defined in the SP’s metadata or a hardcoded default. This limits the ability to return the user to the specific resource they intended to access. Developers must configure the SP to handle these default destinations gracefully, often requiring additional post-authentication routing logic.

Best Practices for Developers

1. Validate RelayState: Always validate the RelayState parameter in SP-initiated flows. Use a signed token or a server-side session store to map the RelayState value to a safe destination. Never trust client-side values directly.
2. Reject Unsolicited Assertions by Default: Configure SPs to reject unsolicited assertions unless explicitly required by business needs. If unsolicited assertions are accepted, ensure strict validation of the IdP’s signature and issuer.
3. Use HTTPS: Both flows rely on HTTP redirects. Ensure all endpoints (ACS, SSO) use HTTPS to prevent man-in-the-middle attacks.
4. Metadata Management: Keep SP and IdP metadata up-to-date. The metadata contains the public keys used for signature validation. Expired or incorrect keys can lead to authentication failures or security bypasses.
5. Prefer SP-Initiated for Security: For most enterprise applications, SP-initiated flows are preferred due to their stronger security posture and better context management. Use IdP-initiated flows only for convenience features like dashboards or app catalogs.

References to Standards

When implementing these flows, engineers should refer to the OASIS SAML 2.0 Core specification for the formal specification of SAML 2.0 protocol mechanics, particularly regarding request/response structures and error codes. Additionally, consult the official OASIS SAML 2.0 Specifications for detailed guidance on binding profiles and security considerations. Adhering to these standards ensures interoperability and security compliance.

Common Pitfalls

1. RelayState Length Limits: Many IdPs impose strict length limits on the RelayState parameter, often capping it at 80 characters in older implementations. If your application requires passing complex state (e.g., deep links, multi-step form data), relying solely on RelayState will fail. Use a secure session store or encrypted token instead.
2. Unsolicited Assertion Acceptance Risks: Leaving the "Accept Unsolicited Assertions" flag enabled on an SP is a common misconfiguration. This allows any IdP to log a user into the SP without explicit consent from the SP, bypassing potential pre-authentication checks.
3. Metadata Expiration Handling: Metadata files contain certificate expiration dates. If these are not monitored, authentication will silently fail when certificates expire. Automated rotation or monitoring of metadata is essential for production systems.

Practical Takeaways

• SP-Initiated is Safer: It provides a clear, validated path for authentication and preserves context via RelayState, minimizing phishing risks.
• IdP-Initiated is Riskier: While convenient for dashboards, it introduces complexity around unsolicited assertions and potential context loss.
• Always Validate RelayState: Never trust the RelayState value directly; treat it as untrusted input that must be verified against a known safe list or session store.
• Reject Unsolicited by Default: Only accept unsolicited assertions if absolutely necessary, and enforce strict issuer validation.

FAQ

What is RelayState? RelayState is an optional parameter in SAML messages that allows the Service Provider and Identity Provider to pass arbitrary data between them. It is commonly used to preserve the user's original request URL or session context across the authentication redirect.

Can IdP-initiated SSO be secure? Yes, IdP-initiated SSO can be secure if implemented correctly. The key is to strictly validate the Issuer of the assertion, ensure the SP does not accept unsolicited assertions from untrusted IdPs, and handle the lack of RelayState gracefully by routing users to a secure default landing page.

Why is SP-initiated preferred? SP-initiated flows are generally preferred because they start with the user's intent to access a specific application. This ensures the SP is aware of the login attempt before the IdP processes it, providing better context management and reducing the attack surface for phishing and unauthorized access.

What happens if RelayState is missing? If RelayState is missing in an SP-initiated flow, the SP cannot automatically redirect the user to their original destination. The SP must handle this gracefully, typically by redirecting the user to a default home page or requiring them to manually navigate to the desired resource after login.

Conclusion

The choice between SP-initiated and IdP-initiated SSO is not just about user interface design; it is a security decision. SP-initiated flows provide a clear, validated path for authentication, leveraging RelayState for context preservation and minimizing phishing risks. IdP-initiated flows offer convenience but introduce complexities around unsolicited assertions and context loss. Engineers must understand these mechanisms to implement secure identity integrations.

Explore our full SAML 2.0 series to deepen your understanding of identity protocols.