An identity provider (IdP) authenticates the user and issues a signed assertion. A service provider (SP) is the application that trusts that assertion and grants access. In IdP vs SP terms, the IdP answers “who is this user?” and the SP answers “what may this user do here?”
Difficulty: Intermediate. This article is for: SaaS engineers adding enterprise SSO and IT admins connecting apps to Okta, Microsoft Entra ID, or Shibboleth.
What is the difference between IdP vs SP vs SSO?
SSO is not a third system. It is the outcome when one IdP session unlocks many SPs.
One IdP authenticates; each SP validates the assertion and keeps its own session.
| Component | Job | Owns | Examples |
|---|---|---|---|
| IdP | Authenticates users, signs assertions | Credentials, MFA policy, user directory | Okta, Microsoft Entra ID, Shibboleth IdP |
| SP | Validates assertions, authorizes access | ACS URL, app roles, app session | Salesforce, Slack, HubSpot, your SaaS |
| SSO | Result: one login, many apps | Nothing; it is a pattern | Not applicable |
US federal guidance uses the same split. NIST SP 800-63C-4, finalized July 31, 2025, defines federation as one credential service provider supplying authentication and optional subscriber attributes to multiple separately administered relying parties, and it supersedes the earlier SP 800-63C. In SSO IdP vs SP language, NIST’s “relying party” is the SP.
Explore your options: What Is a SAML IdP? Providers, Examples, and 2026 Security Checks
What is an identity provider vs service provider example?
- Workforce: Acme’s Microsoft Entra ID tenant is the IdP. HubSpot, where Acme’s sales team works, is the SP.
- Higher education: A university runs a Shibboleth IdP. A licensed journal database runs Shibboleth SP software and trusts the university’s assertions.
- B2B SaaS: Your customer’s Okta org is the SAML IdP. Your product is the SP, and each customer tenant gets its own entity ID and certificate trust.
What is IdP vs SP initiated SSO?
IdP vs SP initiated describes where the login starts, not who authenticates. The IdP authenticates in both cases. The OASIS SAML 2.0 Technical Overview confirms SAML V2.0 supports both flows and calls the SP-initiated scenario, where a user arrives at the SP through a bookmark, the more common one.
| Factor | SP-initiated | IdP-initiated |
|---|---|---|
| Where the user starts | App URL or bookmark | IdP dashboard tile |
| First SAML message | AuthnRequest from SP | Response from IdP (unsolicited) |
| InResponseTo attribute | Present | Absent |
| Request correlation | SP matches response to its stored request ID | None possible |
| Deep links | RelayState returns user to the requested page | Lands on a default page unless RelayState is preset |
| Forced re-authentication | Possible with ForceAuthn | Not possible from the SP |
| Injection and replay exposure | Lower | Higher; needs compensating controls |
| Best fit | Direct app access, mobile, customer-facing apps | Workforce portals |
In SAML authentication, IdP vs SP terms, Microsoft Entra ID labels these “SP initiated mode” and “IDP initiated mode,” and most vendor docs call them IdP-initiated login vs SP-initiated login. All three naming pairs describe the same two flows.
What does the SP initiated SSO flow look like step by step?
- User opens app.example.com/reports/q3 with no session.
- SP generates an AuthnRequest with a unique ID and stores that ID server-side.
- SP redirects the browser to the IdP’s SingleSignOnService URL (HTTP-Redirect binding).
- IdP authenticates the user, applying MFA and conditional access.
- IdP posts a signed Response to the SP’s ACS URL (HTTP-POST binding) with InResponseTo set to the stored ID.
- SP validates signature and ID, creates a session, and redirects to /reports/q3 using RelayState.
What is IdP initiated SSO, and how does the IdP initiated SSO flow work?
IdP-initiated SSO means the IdP sends a SAML Response the SP never asked for. Okta’s developer documentation describes it as the IdP starting a SAML response itself rather than reacting to a redirect from the SP.
- User signs in to the IdP portal.
- User clicks the app tile.
- IdP posts a signed Response with no InResponseTo to the SP’s ACS URL.
- SP validates what it can, creates a session, and lands the user on a default or preset page.
See related information: SAML vs SSO: Is SAML the Same as Single Sign-On?
What does the IdP vs SP initiated flow look like as a diagram?
SP initiated SSO flow: the matching InResponseTo proves the response answers the SP’s own request.
IdP initiated SSO flow: the unsolicited response has no request ID, which the bounce pattern fixes.
Why is IdP initiated SAML riskier, and how should the SP validate it?
Is IdP initiated vs SP initiated SSO more secure?
SP-initiated is more secure because the difference fits in one attribute. Compare the two Response headers:
<!-- SP-initiated: solicited response -->
<samlp:Response ID="_r91" InResponseTo="_req_7f3a"
Destination="https://app.example.com/saml/acs" ...>
<saml:SubjectConfirmationData InResponseTo="_req_7f3a"
Recipient="https://app.example.com/saml/acs"
NotOnOrAfter="2026-09-25T14:05:00Z"/>
<!-- IdP-initiated: unsolicited response -->
<samlp:Response ID="_r92"
Destination="https://app.example.com/saml/acs" ...>
<saml:SubjectConfirmationData
Recipient="https://app.example.com/saml/acs"
NotOnOrAfter="2026-09-25T14:05:00Z"/>The SAML 2.0 Profiles specification sets three rules that matter here: a solicited response must carry an InResponseTo that matches the request ID (section 4.1.4.2), an unsolicited response must not carry one (section 4.1.5), and an SP receiving assertions over HTTP-POST must track used assertion IDs for their validity window to block replay (section 4.1.4.5). Without a request ID to match, a stolen IdP-initiated assertion looks legitimate unless the SP enforces that replay cache and the checks below.
What should the SP validate on every SAML response?
| Check | Field | Blocks | Flow |
|---|---|---|---|
| Signature verifies against IdP metadata certificate | ds:Signature | Forged assertions | Both |
| Request ID matches a stored, unused ID | InResponseTo | Injected responses | SP-initiated |
| Audience equals your SP entity ID | AudienceRestriction | Assertions minted for another app | Both |
| Recipient and Destination equal your ACS URL | Recipient, Destination | Cross-endpoint replay | Both |
| Time window valid, skew tolerance of a few minutes | NotBefore, NotOnOrAfter | Expired assertions | Both |
| Assertion ID not previously seen | Assertion/@ID cache until expiry | Replay | Both, critical for IdP-initiated |
| RelayState on an allow-list of relative paths | RelayState | Open redirects | Both |
The bounce pattern: On receiving an unsolicited response, the SP discards it and immediately starts a fresh SP-initiated request. The user still clicks a tile, but every session is backed by a correlated InResponseTo.
Why does the IdP vs SP choice matter for breach risk in 2026?
Centralizing login at the IdP concentrates attacker attention there. The Verizon 2026 Data Breach Investigations Report records these identity figures for incidents between November 2024 and October 2025:
| Metric | 2026 DBIR figure |
|---|---|
| Credential abuse as the first initial access vector | 13% (16% under the 2025 methodology, before pretexting was tracked separately) |
| Credential abuse at any point in the breach | 39% |
| Vulnerability exploitation as the first initial access vector | 31%, now the top vector |
| Third-party organizations that fully remediated missing or weak MFA on cloud accounts | 23% |
The takeaway for IdP vs SP design: stolen credentials rarely open the door first anymore, but they remain the most common tool once attackers are inside.
- IdP action: Enforce phishing-resistant MFA before issuing any assertion.
- SP action: Disable local password login for users on SSO-enforced domains, so stolen app passwords cannot bypass the IdP. Keep one monitored break-glass admin login for IdP outages or certificate mistakes.
Should SAML assertions be signed, encrypted, or both?
| Option | Protects against | When to require |
|---|---|---|
| Signed Response | Tampering with the whole message | Minimum baseline |
| Signed Assertion | Tampering with the assertion itself, including when it is extracted from the Response | Always for IdP-initiated SAML |
| Encrypted Assertion | Attribute exposure in browser history, logs, or proxies | When assertions carry sensitive attributes |
Verify that the signature covers the exact assertion your code reads. XML signature wrapping attacks insert a second, unsigned assertion alongside a validly signed one, and parsers that verify one element but read another accept the forged one. Use a maintained SAML library rather than hand-rolled XML parsing.
Check related resources: What Is a SAML Assertion? Structure, Example, and Validation (2026)
How does the SP know which IdP to send the user to?
A single-tenant SP has one IdP, so there is nothing to decide. A multi-tenant SaaS SP must pick the right customer IdP before it can build an AuthnRequest. This step is called IdP discovery or home realm discovery.
| Method | How it works | Trade-off |
|---|---|---|
| Email domain lookup | User types an email; SP maps the domain to a tenant’s IdP | Best UX; requires verified domain ownership per tenant |
| Tenant subdomain | acme.app.example.com maps to Acme’s IdP | No typing; users must know their URL |
| Org slug on login page | User enters a company identifier | Works for shared or unverified domains |
IdP-initiated SSO skips discovery entirely because the IdP already knows who the user is. That is often the real reason enterprise customers ask for portal tiles.
What is the difference between the IdP session and the SP session?
The SSO IdP and each SP keep separate sessions. Signing out of one does not end the other unless Single Logout is configured on both sides.
| Session | Controlled by | What ends it |
|---|---|---|
| IdP session | IdP policy | IdP sign-out, idle or absolute timeout |
| SP session | Your application | App sign-out, app timeout, or SessionNotOnOrAfter in the assertion if you honor it |
An SP session that outlives the IdP session means a user disabled at the IdP keeps app access until the SP session expires. Pair SSO with SCIM deprovisioning to close that window.
What user attributes does the IdP send the SP?
| NameID format | Value | Use when |
|---|---|---|
| emailAddress | User’s email | Simple setups; breaks when users change email |
| persistent | Stable opaque ID per SP | Recommended primary key for account linking |
| transient | New random ID per login | Anonymous or privacy-sensitive access |
Map extra attributes (email, first name, last name, groups) explicitly in the IdP’s attribute statement. Key your user table on the persistent NameID, not email, so renamed or re-hired users do not create duplicate accounts.
What goes in IdP metadata vs SP metadata?
The IdP vs SP SAML trust is established by exchanging metadata XML files, one per side.
| Element | IdP metadata | SP metadata |
|---|---|---|
| Role descriptor | IDPSSODescriptor | SPSSODescriptor |
| Primary endpoint | SingleSignOnService (where AuthnRequests go) | AssertionConsumerService (where Responses go) |
| Signing certificate | Required: SP uses it to verify assertions | Optional: IdP uses it to verify signed AuthnRequests |
| Signing preference | WantAuthnRequestsSigned | AuthnRequestsSigned, WantAssertionsSigned |
| Shared fields | entityID, NameIDFormat, optional SingleLogoutService | Same |
Console labels vary by platform. In Microsoft Entra ID’s SAML setup, the Reply URL field takes the ACS URL, and the Sign on URL field takes the app’s SP-initiated login URL.
How do Okta, Azure, and Shibboleth split IdP vs SP roles?
| Platform | Usual role | IdP-initiated entry | SP-initiated trigger |
|---|---|---|---|
| Okta | IdP; also SP when federating inbound from another IdP | End-user dashboard tile | App redirects to the Okta org |
| Microsoft Entra ID | IdP | My Apps tile | Sign on URL populated in Basic SAML Configuration |
| Shibboleth | Separate IdP and SP software packages | IdP endpoint /idp/profile/SAML2/Unsolicited/SSO?providerId= plus the SP entity ID | SP handler /Shibboleth.sso/Login |
Is Okta an IdP or SP?
Okta is an IdP for apps in its catalog. For Okta IdP vs SP questions, the exception is inbound federation: Okta acts as the SP when it trusts an external IdP such as a partner’s Entra ID.
Is Azure AD (Microsoft Entra ID) an IdP?
Yes. For Azure SSO IdP vs SP setups, Entra ID is always the IdP for enterprise apps. Leaving the Sign-on URL empty makes My Apps launch the app IdP-initiated; populating it switches launches to SP-initiated.
What is the Shibboleth IdP vs SP split?
Institutions run Shibboleth IdP; content providers run Shibboleth SP. They ship as distinct products, which makes the role boundary unusually explicit. The Shibboleth IdP 5 unsolicited SSO documentation describes IdP-initiated SSO as a less interoperable mode that some SPs insist on, which matches the SP-initiated default recommended here.
Which SAML IdP providers support both flows?
Every SAML IdP below supports IdP initiated vs SP initiated SAML. The differences are deployment model and defaults.
| SAML IdP providers | Deployment | Notable default or fit |
|---|---|---|
| Okta Workforce Identity | Cloud | Large prebuilt app catalog |
| Microsoft Entra ID | Cloud | Default for Microsoft 365 tenants |
| Ping Identity | Cloud or self-hosted | Complex federation and hybrid estates |
| Google Workspace | Cloud | Google-first organizations |
| JumpCloud | Cloud | Directory plus device management for SMBs |
| OneLogin | Cloud | Mid-market workforce SSO |
| Shibboleth IdP | Self-hosted, open source | Higher education federations |
| Keycloak | Self-hosted, open source | IdP-initiated stays disabled until you set a per-client IdP-Initiated SSO URL name |
| AD FS | Windows Server, on-premises | IdP-initiated sign-on page is disabled by default since Windows Server 2016 |
How does OIDC IdP vs SP compare to SAML?
OIDC renames the roles: the OpenID Provider (OP) is the IdP, and the Relying Party (RP) is the SP. Tokens are JSON Web Tokens, not XML assertions.
| Concept | SAML | OIDC |
|---|---|---|
| SP-initiated equivalent | AuthnRequest with ID | Authorization Code flow with state and nonce |
| IdP-initiated equivalent | Unsolicited Response | Third-party initiated login |
| Unsolicited tokens accepted | Yes, by design | No: the OP calls the RP’s initiate_login_uri, and the RP starts a normal request |
OIDC builds the bounce pattern into the specification, which removes the unsolicited-token risk entirely.
How do you test IdP vs SP initiated login before go-live?
Capture SAML traffic with a browser extension such as SAML-tracer, or read the SAMLResponse form field in the browser’s network tab and Base64-decode it.
| Test | Flow | Pass criteria |
|---|---|---|
| Open a deep link while signed out | SP-initiated | Lands on the deep link, not the home page |
| Launch from the IdP portal tile | IdP-initiated | Session created; response logged as unsolicited |
| Replay a captured Response | Both | SP rejects: duplicate assertion ID |
| Edit Audience in a captured Response | Both | SP rejects: signature invalid |
| Wait past NotOnOrAfter, then submit | Both | SP rejects: expired |
| Set RelayState to an external URL | Both | SP ignores it and uses the default page |
| Disable the user at the IdP | Both | Next login fails; existing session ends per your deprovisioning policy |
What errors break IdP vs SP SAML integrations?
| Symptom | Likely cause | Fix |
|---|---|---|
| “InResponseTo does not match” | Request ID stored in a session cookie lost across domains or load balancers | Store request IDs server-side; set SameSite=None; Secure on the SAML session cookie |
| “Invalid audience” | SP entity ID in IdP config differs from SP metadata | Copy entity ID exactly, including trailing slash |
| “Assertion expired” or “not yet valid” | Server clock drift | Sync NTP on SP hosts; allow limited skew |
| “Destination mismatch” | ACS URL registered with http vs https or wrong path | Match the ACS URL character for character |
| Signature fails after months of working | IdP rotated its signing certificate | Consume IdP metadata by URL and refresh on a schedule |
| User lands on home page, not the requested page | IdP-initiated login with no RelayState | Switch to SP-initiated or preset RelayState in the IdP |
Which flow should you choose?
Answer from the top; every path ends at one recommendation.
| Scenario | Recommendation |
|---|---|
| B2B SaaS selling to enterprises | Support both; default to SP-initiated; handle IdP-initiated with the bounce pattern |
| Internal workforce portal | IdP-initiated is acceptable when the full validation checklist is enforced |
| Customer-facing or public app | SP-initiated only |
| Deep links, mobile apps, email links | SP-initiated only |
| Sensitive actions needing fresh login | SP-initiated with ForceAuthn=”true” |
| US federal or FedRAMP workloads | SP-initiated, with assertion protections matched to the federation assurance level your agency requires under SP 800-63C-4 |
| New build with no SAML requirement | OIDC |
Verdict: which side should you optimize for?
Build your SP to be SP-initiated by default, because it is the only SAML flow where every assertion is provably tied to a request you made. Enable IdP-initiated logins only when customers require portal tiles, and only after your SP passes every row of the testing table above. If you are starting a new integration with no customer mandate for SAML, choose OIDC.
Frequently asked questions
Can one system be both an IdP and an SP?
Yes. Identity brokers and SAML proxies act as an SP toward an upstream IdP and as an IdP toward downstream apps.
Is an SSO IdP the same as an identity provider?
Yes. “SSO IdP” is shorthand for the identity provider that issues assertions in a single sign-on deployment.
Does single logout depend on which flow started the session?
No. SAML Single Logout uses separate SingleLogoutService endpoints and works the same regardless of initiation, as long as both sides publish them in metadata.
