Skip to main content
Identity Authority
Category: Federation & SSO

IdP-Initiated SSO

Also known as: Identity Provider-Initiated Single Sign-On, Identity Provider Initiated SSO
Simply put

IdP-initiated SSO is a single sign-on flow that begins at the identity provider rather than at the application the user wants to reach. The user first signs in to the identity provider's portal (for example, Okta, Google Workspace, or Microsoft Entra ID) and then selects an application, and the identity provider passes along proof of the sign-in so the application grants access without a separate login.

Formal definition

IdP-initiated SSO is a SAML 2.0 web SSO pattern in which the flow originates at the identity provider (IdP) instead of the service provider (SP). Rather than the SP generating an authentication request (the SP-initiated pattern), the user authenticates at the IdP first, and the IdP then delivers an unsolicited SAML assertion to the SP, commonly via an HTTP POST of the assertion or, in some deployments such as PingFederate's artifact profile, via a SAML artifact sent through an HTTP redirect that the SP resolves out of band. The SP consumes the asserted authentication statement and establishes a session without having issued a prior AuthnRequest. Support and configuration vary by product; for example, some IdPs require the SP-side connection to be explicitly set to accept IdP-initiated requests. Note that because the SP receives an unsolicited assertion with no correlating request state, this pattern has different security considerations than SP-initiated flows; specific enforcement and validation behavior depends on the profile and deployment and is out of scope here.

Why it matters

IdP-initiated SSO shapes the user experience for many organizations that standardize on a central identity provider portal, such as Okta, Google Workspace, or Microsoft Entra ID. Users sign in once at the portal and launch applications from a catalog of tiles, which reduces repeated logins and gives administrators a single launch point to manage. This convenience is a primary reason the pattern remains common in enterprise SAML deployments, even though SP-initiated flows are often the default recommendation.

The security posture of IdP-initiated SSO differs from SP-initiated SSO in an important way: the service provider receives an unsolicited SAML assertion that it never requested, so there is no correlating AuthnRequest state to validate the response against. This absence of request-response correlation changes the assumptions an SP can make about an incoming assertion and is a recurring topic when architects weigh the two patterns. The specific enforcement and validation behavior depends on the SAML profile and the particular product configuration, so teams should evaluate their own deployment rather than assume uniform behavior across vendors.

Because support and configuration vary by product, some IdPs require the SP-side connection to be explicitly set to accept IdP-initiated requests, interoperability is not guaranteed by default. Understanding whether a given application accepts unsolicited assertions, and how it is configured to do so, is essential for both provisioning federation connections and troubleshooting failed logins. Misaligned expectations between IdP and SP configuration are a frequent source of integration friction.

Who it's relevant to

IAM engineers and federation administrators
Engineers configuring SAML 2.0 connections need to know whether each service provider accepts unsolicited assertions and how to enable it, since some IdPs require the SP-side connection to be explicitly set to accept IdP-initiated requests. They also need to understand delivery variations, such as HTTP POST of the assertion versus the artifact profile used in products like PingFederate, to configure endpoints correctly and troubleshoot failed logins.
Security architects
Architects choosing between IdP-initiated and SP-initiated flows must account for the fact that IdP-initiated assertions arrive without a correlating AuthnRequest, which removes request-response state and changes the assumptions an SP can make about incoming assertions. Evaluating the specific validation and enforcement behavior for a given SAML profile and product is necessary rather than assuming consistent behavior across vendors.
System administrators managing SSO portals
Administrators operating identity provider portals such as Okta, Google Workspace, or Microsoft Entra ID rely on IdP-initiated SSO to present users with a catalog of application tiles launched from a single authenticated session. They need to understand how portal tiles map to configured SP connections so that application access works as expected for end users.

Inside IdP-Initiated SSO

Identity Provider (IdP)
The system that authenticates the user and initiates the SSO flow. In IdP-initiated SSO, the flow begins at the IdP rather than at the service provider, typically after the user has already established an authenticated session with the IdP (for example, via an application portal).
Service Provider (SP) / Relying Party
The application or resource the user wants to access. In IdP-initiated SSO the SP receives an unsolicited assertion from the IdP without having generated a corresponding authentication request, which affects how the SP must validate and consume the message.
Unsolicited SAML Response / Assertion
In SAML 2.0, IdP-initiated SSO is carried by an unsolicited <Response> containing an assertion that has no corresponding <AuthnRequest> InResponseTo value. This is the defining structural difference from SP-initiated SSO.
RelayState
An optional parameter typically used to convey a deep link or target resource at the SP so the user lands on the intended page after the assertion is processed. In IdP-initiated flows it commonly substitutes for the state that an SP-initiated request would otherwise have carried.
Assertion Consumer Service (ACS)
The SP endpoint that receives and processes the assertion. In IdP-initiated SSO the assertion is posted to a pre-configured ACS URL, since there is no request from the SP to reference.
Authentication vs. subsequent authorization
The IdP asserts that the user has been authenticated and conveys identity attributes; the SP then performs its own authorization decision to determine what the user may access. IdP-initiated SSO addresses the delivery of authentication assertions, not the SP's access control model.

Common questions

Answers to the questions practitioners most commonly ask about IdP-Initiated SSO.

Does IdP-initiated SSO mean the identity provider authenticates the user on behalf of the service provider, so the SP does no verification of its own?
No. In IdP-initiated SSO the identity provider authenticates the user and then produces an assertion, but the service provider still performs its own validation before granting a session. Typically the SP validates the assertion's signature, checks the issuer, audience, and time-based conditions, and maps the asserted identity to a local account. Authentication of the user happens at the IdP; the SP's job is to verify the assertion is trustworthy and authorized for its context and then make an access decision. Treating the SP as a passive recipient that skips validation is a security mistake.
Is IdP-initiated SSO just the same thing as SP-initiated SSO with the steps in a different order?
Not exactly. The two flows differ in more than sequence. In SP-initiated SSO the service provider generates an authentication request that the IdP responds to, which lets the SP include request-specific context and correlate the response to a request it originated. In IdP-initiated SSO the IdP sends an unsolicited assertion to the SP without a corresponding request. Because there is no originating request to bind the response to, IdP-initiated flows are generally more exposed to certain replay and cross-site request forgery style concerns, and some standards and profiles discourage or restrict unsolicited responses. The distinction affects threat modeling and configuration, not just ordering.
How is IdP-initiated SSO typically configured in a SAML 2.0 deployment?
In most SAML 2.0 deployments the IdP is configured with the SP's metadata, including the Assertion Consumer Service (ACS) endpoint where unsolicited assertions are posted, and often a default RelayState value used to direct the user to a specific resource at the SP after login. The IdP exposes some form of launch link or application catalog entry that, when selected, triggers generation of an assertion and an HTTP POST to the SP's ACS. The SP must be configured to accept unsolicited assertions, since some implementations reject responses that lack a matching InResponseTo value. Exact configuration steps and terminology vary by vendor and product.
What is the role of RelayState in IdP-initiated SSO, and how does it differ from SP-initiated flows?
RelayState is an opaque value used to preserve state across the SSO exchange, commonly to indicate which resource the user should land on at the service provider. In SP-initiated flows the SP typically sets RelayState to remember the originally requested resource. In IdP-initiated flows there is no original SP request, so the RelayState is often supplied by the IdP configuration to point to a target application or deep link at the SP. Because the value influences post-login redirection, it should be validated or constrained by the SP to avoid open-redirect style abuse. Its precise handling depends on the SAML profile and the products involved.
What validation should the service provider perform when receiving an unsolicited assertion?
At minimum the SP should verify the assertion's signature against the trusted IdP signing key, confirm the issuer matches an expected IdP, and check that the audience restriction names the SP itself. It should enforce the assertion's time-based conditions such as NotBefore and NotOnOrAfter, and apply single-use or replay protection where supported, since unsolicited assertions lack an InResponseTo correlation. Depending on configuration the SP may also require the assertion or transport to be encrypted rather than only signed, since signing establishes integrity and origin but not confidentiality. Specific checks available depend on the SP implementation and the SAML profile in use.
What are the main security considerations that make some deployments prefer SP-initiated over IdP-initiated SSO?
IdP-initiated SSO is often viewed as carrying additional risk because the SP receives an assertion it did not request, which removes the request-to-response binding that helps mitigate replay and certain cross-site request forgery scenarios. This can make stolen or captured assertions harder to detect if replay protection is weak. Some organizations restrict or disable unsolicited assertions and require SP-initiated flows where feasible, or add compensating controls such as strict single-use enforcement, short assertion validity windows, and constrained RelayState handling. Whether IdP-initiated SSO is acceptable depends on the deployment's threat model, the profiles supported, and the compensating controls available in the products involved.

Common misconceptions

IdP-initiated SSO is just SP-initiated SSO run in the opposite direction and is functionally equivalent.
They differ meaningfully. SP-initiated flows generate an authentication request that the response can be correlated to (for example, via InResponseTo in SAML 2.0), while IdP-initiated flows deliver an unsolicited assertion with no such correlating request. This changes replay and validation considerations and is why some deployments restrict or avoid the pattern.
Because the assertion is signed, IdP-initiated SSO is inherently secure against injection or replay.
A signed assertion proves origin and integrity but is not the same as protection against replay or the absence of a correlating request. The lack of an InResponseTo binding in unsolicited responses removes one mechanism SPs would otherwise use to tie a response to a prior request, so additional controls are typically needed.
IdP-initiated SSO is a distinct protocol from SAML SSO.
It is a flow variant within the same federation standard (SAML 2.0 Web Browser SSO profile), distinguished by where the flow starts and by the use of an unsolicited response. It is not a separate protocol, and OAuth 2.0 / OpenID Connect handle initiation differently.

Best practices

Prefer SP-initiated SSO where practical, since it allows the SP to correlate the response to its own authentication request; reserve IdP-initiated SSO for scenarios such as portal-driven access where it is genuinely required.
Where IdP-initiated SSO is enabled, validate the assertion rigorously at the SP, including signature verification, audience restriction, issuer, and time-based conditions (NotBefore/NotOnOrAfter), rather than relying on the signature alone.
Configure and restrict the Assertion Consumer Service (ACS) URLs the SP will accept, and treat RelayState/deep-link targets as untrusted input to reduce open-redirect and injection risk.
Implement replay protection at the SP (for example, tracking assertion IDs within their validity window), since unsolicited responses lack an InResponseTo binding to a prior request.
Keep authentication and authorization separate: use the assertion to establish who the user is, then apply the SP's own access control model (such as RBAC or ABAC, depending on configuration) to decide what they may do.
Document and review IdP-to-SP trust configuration as part of governance, confirming which SPs accept IdP-initiated flows and validating this during periodic access and configuration reviews.
Application Security Isn’t Optional Anymore.