Single Sign-On is the feature; federation protocols (SAML, OAuth 2.0, OpenID Connect) are how it actually works underneath. Understanding the difference matters when evaluating a new application's SSO support, troubleshooting a login integration, or deciding how strictly to enforce SSO-only access. This article explains the mechanism, compares the three protocols, and covers why SSO is a security control, not just a convenience feature.
What SSO actually does
Single Sign-On lets a user authenticate once with an identity provider (IdP) — such as Microsoft Entra ID or Okta — and then access multiple applications (service providers, or SPs) without authenticating separately to each one. The applications trust the identity provider's assertion that the user is who they claim to be, rather than each maintaining and verifying its own separate credential for that user.
SSO is a security control, not just convenience
Fewer passwords for users to create, remember, and potentially reuse is a direct security benefit, not just a usability one — see the Password Manager Guide for the same underlying logic applied to credential reuse generally. SSO also centralizes authentication policy: MFA, Conditional Access, and offboarding all apply at the identity provider once, rather than needing separate enforcement per application.
The three protocols compared
| Protocol | Primary Purpose | Typical Use Case | Data Format |
|---|---|---|---|
| SAML 2.0 | Authentication (identity assertion) | Enterprise SSO into web applications, especially older/legacy business software | XML |
| OAuth 2.0 | Authorization (delegated access to resources) | Letting one app access data in another on a user's behalf (e.g., 'Sign in with' granting calendar access) | JSON / tokens |
| OpenID Connect (OIDC) | Authentication, built on top of OAuth 2.0 | Modern consumer and business SSO — most 'Sign in with Microsoft/Google' flows | JSON Web Tokens (JWT) |
SAML is the older, XML-based standard and remains extremely common in enterprise software, particularly applications that predate modern JSON-based standards. OAuth 2.0 is fundamentally an authorization framework — it was designed to let an application access specific resources on a user's behalf, not to prove identity by itself. OpenID Connect adds an identity layer on top of OAuth 2.0, making it suitable for authentication (proving who the user is) rather than just delegated resource access — this is what most modern "Sign in with Microsoft" or "Sign in with Google" buttons actually use.
OAuth 2.0 alone is not an authentication protocol
A surprisingly common integration mistake is using bare OAuth 2.0 (without the OpenID Connect identity layer) to "log a user in." OAuth 2.0 was designed to grant delegated access to a resource, not to reliably assert who the user is — using it for authentication without OIDC's identity token has historically led to real security vulnerabilities in custom integrations. If an application needs to authenticate a user, it should use OIDC or SAML, not raw OAuth 2.0.
How a typical SSO login flow works
- A user attempts to access an application (the service provider).
- The application redirects the user to the identity provider instead of showing its own login form.
- The user authenticates with the identity provider — including whatever MFA and Conditional Access policy applies there.
- The identity provider sends a signed assertion (a SAML assertion or an OIDC token) back to the application, confirming the user's identity.
- The application trusts this assertion (having established that trust relationship in advance) and grants access — without ever seeing or handling a password itself.
This is why deploying SSO for an application removes that application's own password entirely from the picture in most configurations — the application no longer authenticates the user directly, which is also why enforcing "SSO-only" login (disabling any local password fallback) closes a common bypass path.
Each protocol's flow in detail
The general sequence above looks slightly different depending on which protocol is actually carrying the assertion:
Federation across organizations
"Federation" specifically refers to trust relationships that span organizational boundaries — for example, a vendor's application trusting your organization's identity provider directly, or two organizations' identity providers trusting each other for cross-company collaboration (as Microsoft Entra ID's B2B federation does). This differs from SSO within a single organization's own application portfolio, though the same underlying protocols (SAML, OIDC) power both.
Practical recommendations
- Prefer SSO for every application that supports it, rather than allowing a mix of SSO and locally-managed passwords — mixed environments are where password reuse and weaker credentials tend to persist.
- Disable local password fallback once SSO is confirmed working, so the application can't be accessed by bypassing the identity provider's authentication and Conditional Access policy.
- Understand which protocol a new application uses before procurement, since older or highly customized business software sometimes only supports SAML, or in rarer cases neither — this affects integration effort and timeline.
- Centralize MFA and Conditional Access enforcement at the identity provider, so policy changes apply everywhere at once rather than needing per-application configuration.
- Review federated trust relationships periodically — a federation configured for a vendor relationship that has since ended is a dangling trust relationship worth cleaning up, similar in spirit to reviewing stale privileged access.
Common mistakes
- Using bare OAuth 2.0 as if it were an authentication protocol, which can create real security gaps in custom integrations — always confirm OIDC (or SAML) is actually in use for authentication.
- Leaving a local password fallback enabled "just in case" after SSO rollout, which undermines the centralized policy enforcement SSO is meant to provide.
- Assuming SSO alone means MFA is enforced. SSO centralizes where authentication happens; MFA still needs to be explicitly required at the identity provider — see Multi-Factor Authentication: Methods and Best Practices.
- Not reviewing stale federated trust relationships with vendors or partners no longer in an active relationship.
FAQ
Is OAuth 2.0 the same thing as OpenID Connect? No — OAuth 2.0 is an authorization framework (delegated resource access); OpenID Connect adds an identity/authentication layer on top of it. Many people say "OAuth" when they actually mean OIDC-based login, which is a meaningful technical distinction for anyone building or evaluating an integration.
Does SSO make an organization more or less secure than separate passwords per application? More secure in practice, for two main reasons: fewer credentials means less password reuse across systems, and security policy (MFA, Conditional Access, offboarding) is enforced centrally rather than needing separate configuration per application.
What happens to SSO access when an employee is offboarded? Disabling the employee's identity provider account should immediately revoke access to every SSO-connected application at once — this is one of SSO's biggest practical advantages over per-application accounts, which require separate deprovisioning steps prone to being missed. See Identity Lifecycle and Joiner-Mover-Leaver Governance.
Can an application support both SAML and OIDC? Yes, many modern identity providers and applications support multiple protocols simultaneously; the choice is typically made once during initial integration setup based on the application's own supported options and organizational preference.