What is the difference between IdP-initiated SSO and SP-initiated SSO?

IdP-initiated SSO starts at the identity provider, where the user signs in and selects an application from a dashboard. SP-initiated SSO starts at the service provider, which redirects the user to the IdP for authentication and then accepts the signed assertion. Most modern IdPs support both flows, and the right choice depends on how your users typically begin their work.

Which SSO flow is more secure: IdP-initiated or SP-initiated?

Neither flow is inherently more secure than the other. Both rely on the same trust relationship, signed assertions, and validation steps. SP-initiated SSO does include an explicit request from the SP, which can give the IdP more context for risk-based decisions. IdP-initiated SSO requires extra care in token validation because the SP receives an assertion without first requesting it. Strong security depends more on the controls applied, phishing-resistant MFA, signed assertions, short sessions, and continuous monitoring, than on the flow itself.

Can an organization use both IdP-initiated and SP-initiated SSO?

Yes. Most organizations use both. Internal employees may rely on IdP-initiated SSO through a corporate dashboard, while external partners or B2B users access the same applications through SP-initiated flows. A modern IdP supports both models from the same trust configuration.

What protocols do IdPs and SPs use to exchange authentication information?

The two most common SSO protocols are Security Assertion Markup Language (SAML), used widely in enterprise applications, and OpenID Connect (OIDC), used in modern web and mobile applications. SAML uses XML to package assertions, while OIDC uses lightweight JSON Web Tokens (JWTs). Both rely on signed messages and pre-established trust between the IdP and the SP.

IdP-initiated vs. SP-initiated SSO: how each flow works

Q: How do identity providers and service providers establish trust?

The IdP and SP exchange configuration data once during setup, including signing certificates and endpoint URLs. After that, the IdP signs every authentication assertion with its private key, and the SP validates the signature using the IdP's public certificate. This signed exchange is what allows the SP to trust the IdP without storing user credentials itself.

Single sign-on uses two flows: IdP-initiated SSO starts at the identity provider, and SP-initiated SSO starts at the service provider. The two flows differ in where login begins, which applications they suit, and how each secures the exchange.

Download the identity trust guide

Introduction

Single sign-on (SSO) lets users log in once and access multiple applications without signing in again. Behind that simple experience are two different authentication flows, IdP-initiated SSO and SP-initiated SSO, and the choice between them shapes both your security posture and your user experience. This article explains how identity providers (IdPs) and service providers (SPs) coordinate during SSO, the difference between the two flows, and the security best practices IT administrators need to apply at each step.

Want a deeper look at how identity threats are evolving and what a security-first IAM strategy looks like? Download the Restoring trust in identity guide.

Key takeaways

The most important points to know about how IdPs and SPs work together for SSO:

An identity provider (IdP) authenticates users. A service provider (SP) is the application the user is trying to reach. The two coordinate through a trust relationship to deliver SSO.
IdP-initiated SSO starts at a central dashboard. SP-initiated SSO starts at the application the user wants to access. Most modern environments support both.
The IdP-to-SP exchange is a high-value target for attackers. According to the Cisco Talos Year in Review 2024, identity and access management applications are the most targeted category in MFA attacks at 24%.
Strong SSO security depends on signed assertions, validated tokens, short session lifetimes, and phishing-resistant MFA at the IdP layer.

What is the relationship between an identity provider and a service provider?

An identity provider (IdP) verifies who a user is. A service provider (SP) is the application or resource the user wants to reach. The IdP authenticates. The SP grants access based on the IdP's signed confirmation. In an SSO setup, the SP does not store user credentials and does not run its own login screen. It trusts the IdP to handle authentication and accepts a signed message, called an assertion or token, that confirms the user's identity. For a full breakdown of the IdP role, including how identities are created and stored, see our identity provider guide.

How identity providers and service providers establish trust

Before SSO can happen, the IdP and the SP must establish a trust relationship. This is a one-time configuration step where both sides exchange the information needed to recognize and verify each other's messages. The trust relationship relies on open standards. The two most common are:

Security Assertion Markup Language (SAML): A standard for exchanging authentication and authorization data, common in enterprise applications.
OpenID Connect (OIDC): A modern authentication layer built on OAuth 2.0, common in cloud and mobile applications.

Once trust is established, every login flows through this connection. The IdP issues a signed assertion. The SP validates the signature and grants access. The user experiences a single login. For a closer look at how identity federation extends this model across organizations, see our guide to federated identity management vs. SSO.

The two SSO models: IdP-initiated vs. SP-initiated

Once trust is in place, an SSO login can begin in one of two places: at the IdP or at the SP. Each model has its own flow, its own use cases, and its own security considerations.

How IdP-initiated SSO works

In IdP-initiated SSO, the user starts at the identity provider. The flow looks like this:

The user logs in to the IdP and sees a dashboard of available applications.
The user selects an application from the dashboard.
The IdP creates a signed assertion containing the user's identity and access permissions.
The IdP sends the assertion directly to the SP.
The SP validates the assertion and logs the user in.

This model is common in environments where employees work with a known set of applications every day, such as corporate intranets or university portals.

How SP-initiated SSO works

In SP-initiated SSO, the user starts at the application. The flow looks like this:

The user navigates to the SP.
The SP detects the user is not signed in and redirects the request to the IdP.
The IdP authenticates the user.
The IdP creates a signed assertion and sends it back through the user's browser to the SP.
The SP validates the assertion and logs the user in.

This model fits dynamic environments where users discover applications independently, such as B2B platforms, software-as-a-service (SaaS) applications, and consumer services.

When to use IdP-initiated vs. SP-initiated SSO

Use IdP-initiated SSO when:

Your users access a stable set of internal applications every day.
A central application launchpad improves productivity.
Your environment is largely on-premises or hybrid with managed devices.

Use SP-initiated SSO when:

Your users access applications from many different starting points, including email links and bookmarks.
Your application portfolio changes often as you add or remove SaaS tools.
You need deep linking so users land on the exact page they requested.

Most modern IdPs support both flows. The decision often comes down to your environment and how your users typically start their work.

Where the login starts

IdP-initiated SSO begins at the IdP dashboard. SP-initiated SSO begins at the application itself, which then redirects the user to the IdP for authentication.

Best for

IdP-initiated SSO suits stable environments with a known set of applications. SP-initiated SSO suits dynamic environments with varied or changing applications.

Common settings

IdP-initiated SSO is common in corporate intranets and education portals. SP-initiated SSO is common in SaaS, B2B services, and consumer applications.

Identity is the new attack surface

Cisco Talos research shows attackers are increasingly targeting the identity layer.

Security implications of the IdP and SP exchange

The handoff between the IdP and the SP is where SSO security succeeds or fails. Attackers know this. According to Cisco Talos research published in the 2024 Year in Review, identity and access management applications are the most targeted category in MFA attacks, accounting for 24% of incidents. More than half (60%) of Cisco Talos incident response cases in 2024 had an identity attack component. Strong SSO depends on doing several things well at the same time.

Best practices for identity providers

The IdP is the authority that signs every assertion. If the IdP is compromised, every connected SP is at risk. To protect the IdP layer:

Enforce phishing-resistant multi-factor authentication (MFA). Methods like passkeys, biometrics, and FIDO2 security keys resist credential theft and adversary-in-the-middle attacks better than SMS codes or push approval alone.
Monitor authentication activity continuously. Look for unusual login patterns, impossible travel, and unfamiliar devices.
Rotate signing keys and certificates on a regular schedule. Compromised signing keys allow attackers to forge valid-looking assertions.
Limit the attributes released to each SP. Send only the claims the SP actually needs. Over-sharing user attributes creates privacy and security risk.
Disable default credentials and weak passwords. Better yet, move toward passwordless authentication where possible.

Best practices for service providers

The SP is the gatekeeper that decides what the assertion is allowed to do. To protect the SP layer:

Validate every assertion. Verify the signature, the issuer, the audience, and the expiration time on every login.
Use HTTPS for all communication. Assertions travel through the user's browser, which makes transport security essential.
Apply least-privilege authorization. Use the roles and claims in the assertion to grant only the access the user actually needs.
Set short session lifetimes. Long sessions increase the window for session hijacking and stolen-token replay attacks.
Reject unsigned or improperly signed tokens. Accept only assertions signed by trusted IdPs.

The growing risk of mid-session attacks

Strong authentication at the moment of login is no longer enough on its own. Attackers increasingly target the session after MFA succeeds, stealing session cookies or tokens to impersonate the authenticated user. Defending against this requires continuous verification throughout the session, not just at the initial sign-in. This is one of the central themes in Duo's Restoring Trust in Identity guide. The guide outlines a four-step framework for end-to-end phishing resistance that goes beyond MFA to protect users from enrollment through every authentication and at high-risk moments like helpdesk calls. Download the guide to explore the full framework.

Why the IdP and SP relationship matters for IT administrators

For IT administrators, the IdP-to-SP exchange is one of the highest-leverage points in your security architecture. Get it right, and one strong authentication policy protects every connected application. Get it wrong, and a single weakness can cascade across your entire SaaS portfolio. Three trends make this exchange more important than ever:

Application sprawl. A typical organization now uses dozens to hundreds of SaaS applications. SSO consolidates control over all of them.
Identity-targeted attacks. Cisco Talos found that 70% of reported ransomware cases in 2024 leveraged valid accounts for initial access. Attackers prefer logging in to hacking in.
Distributed work. When users authenticate from anywhere, the IdP becomes the consistent enforcement point for security policy.

Cisco Duo's 2025 State of Identity Security Report found that 73% of IT and security leaders say security is an afterthought in identity infrastructure decisions. Treating the IdP-SP exchange as a core security control, not just a convenience feature, closes that gap.

Secure SSO with Duo

Duo Directory is an identity provider that delivers SSO, phishing-resistant MFA, and device trust from a single platform. It supports both IdP-initiated and SP-initiated SSO across cloud, on-premises, and hybrid applications, with strong security applied by default. To learn how Duo's security-first approach to IAM addresses the full identity lifecycle, from enrollment through every authentication, download the Restoring Trust in Identity guide. Ready to take the next step? Download the Restoring Trust in Identity guide for a complete look at security-first IAM, end-to-end phishing resistance, and continuous identity intelligence.