What is the difference between a core identity provider and a web application SSO provider?

A core identity provider is the authoritative directory that stores and governs identities across the environment. A web application SSO provider is focused on simplifying sign-in to browser-based apps through federated authentication. They solve different problems, so organisations should choose based on whether they need identity control at the core or access convenience at the application layer.

How a core identity provider differs from a web app SSO provider

A core identity provider is the authoritative source of identity control: it is where users are registered, governed, deprovisioned, and tied to broader access policy. A web application SSO provider is narrower, acting as the authentication and federation layer that lets users sign in to browser-based apps without each app managing credentials itself. The distinction is architectural, not just product branding.

The simplest way to think about the difference is scope. The core identity provider owns the identity plane, while the SSO provider primarily improves sign-in experience for applications. That means a core IdP usually has stronger lifecycle, policy, and admin responsibilities, while an SSO layer may sit on top of that identity control and translate it into SAML or OIDC sign-in flows for apps.

For a practical example, an organisation may use the same platform for both roles, but the functions are still different. Identity governance, account recovery, federation trust, and session controls belong to the core identity plane, whereas app-facing SSO focuses on whether a user can reach a browser app with the right assertion, token, or session. Identity Provider and SSO Security Guide is useful here because it shows how the same platform can expose both the directory control and the app sign-in surface.

What changes at the application layer versus the identity core

A core identity provider is judged by how well it governs identity across the environment: provisioning, deprovisioning, authentication policy, admin protections, and trust boundaries. A web app SSO provider is judged more by how cleanly it delivers federated access into SaaS and browser applications. That difference matters because you can have a strong SSO experience while still having weak identity governance underneath.

In other words, SSO convenience does not automatically mean identity authority. If the directory, lifecycle, or recovery process is weak, the app SSO layer simply becomes a faster path into the same underlying weakness. IAM and Identity Provider Buyer’s Guide is a useful reference because it frames the decision around identity control, not just login convenience.

This is also why browser SSO and core IdP decisions should not be collapsed into one question. App SSO can be a feature of the identity platform, but the architectural responsibility is different: one layer authenticates to the app, the other defines who the identity is, whether it still exists, and what it may do. When those responsibilities are blurred, teams often overestimate their actual control over access.

Why the distinction matters for trust, lifecycle, and federation

The separation becomes visible when something goes wrong. If an attacker compromises the identity core, they may affect many applications at once because the trust relationship is upstream of app access. If an attacker only exploits an app SSO integration, the blast radius may be narrower, but still serious if the federation trust or token handling is weak. The right mental model is not “which product has SSO,” but “where is the authoritative trust decision made?”

That distinction is why identity-provider hardening and federation monitoring are central to the core layer, not just to the apps using it. The Workforce Identity Security Guide covers the wider identity control plane, including SSO, federation, lifecycle and session theft, which is exactly where the core-vs-app split becomes operationally important.

For the application layer, the main concern is whether the SSO flow is properly federated, scoped, and resistant to token abuse. For the identity core, the main concern is whether access is still valid, whether the account is still owned, and whether the trust relationships remain correct. That is why organisations should treat SSO as an access pathway, not as proof of identity governance.

Risk and Threat Considerations

The main risk is assuming a browser SSO feature gives the same control as a true identity authority. When that happens, organisations can miss excessive standing access, weak recovery paths, stale accounts, or compromised federation trust, all of which can turn a convenience layer into a broad compromise path.

Failure mechanism: Attackers target the identity core, federation trust, or recovery process because those paths can grant access to many downstream applications without needing to attack each app individually. A weaker app SSO implementation can also expose tokens or assertions that shortcut the trust model.

Impact: Compromise at the core can become tenant-wide or environment-wide access, while compromise at the SSO layer can expose one or many applications depending on how federation, token handling, and session controls are configured. The difference affects blast radius, incident response priority, and how quickly access must be revoked.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	IA-2 — Identification and Authentication (Organizational Users)	Core identity providers govern user authentication authority across the environment.
	IA-5 — Authenticator Management	The distinction depends on lifecycle control of credentials, tokens, and sign-in material.
	IA-9 — Service Identification and Authentication	Federated SSO relies on authenticating services and trust relationships behind app sign-in.
Recommendation — Use IA-2 to enforce strong authentication for organizational identities at the core IdP. Apply IA-5 to manage credential issuance, rotation, and revocation centrally. Use IA-9 to secure service-to-service and federation trust paths that support SSO.
OWASP ASVS	V10 — OAuth and OIDC	Web application SSO commonly uses OIDC or OAuth-based federation for browser login.
	V8 — Authorization	The core IdP decision and the app-layer access decision must not be conflated.
Recommendation — Verify OIDC and OAuth flows to ensure the SSO layer is correctly implemented and bounded. Validate authorization separately from authentication so app access matches the identity policy.

Practitioner Guidance

What to verify: Confirm which system is authoritative for identity lifecycle, admin policy, and recovery, and then check whether the SSO layer is only consuming that authority or quietly duplicating it. If the SSO product can create, extend, or recover access without the core identity controls seeing it, you have a governance gap.

Decision rule: If you are comparing platforms, choose the core identity provider first for governance, lifecycle, and trust ownership, then evaluate SSO as an application access capability layered on top. If your primary need is only browser login convenience, SSO can be enough, but do not confuse that with an identity strategy.

Practitioner takeaway: The core identity provider should answer “who is this, should they still exist, and what are they allowed to do,” while the web application SSO provider should answer “how do they sign in to this app.” Treating those as the same control is where teams most often overestimate their security posture.