What Is Single Sign-On (SSO)?
Section titled “What Is Single Sign-On (SSO)?”Single sign-on lets people use multiple systems based on an established authentication session. An employee might authenticate with the organization’s identity platform and then open an expense tool and an internal portal without entering a password for each one.
SSO applies to custom applications, on-premises systems, cloud services, and SaaS. This article focuses on SAML 2.0 and OpenID Connect 1.0. Sources and product information were checked on November 1, 2026.
Why use SSO?
Section titled “Why use SSO?”SSO reduces repetitive login steps and can centralize authentication policy and logging. It does not mean a person will never authenticate again: session expiry, sensitive operations, and policy changes may trigger another check.
Authentication establishes who someone is. Authorization determines what that person may do. Successful SSO authentication does not automatically grant administrative access or define the correct permissions.
Providers and applications
Section titled “Providers and applications”An identity provider (IdP) authenticates the user. In SAML, the application consuming that result is a service provider (SP). OIDC calls the provider an OpenID Provider (OP) and the application a relying party (RP), or client.
Organizations can run their own IdP or use a cloud identity platform such as Microsoft Entra ID. Each application needs a trust configuration. The application normally receives an authentication result rather than the user’s IdP password.
SAML 2.0
Section titled “SAML 2.0”Security Assertion Markup Language (SAML) communicates authentication information using XML. An assertion describes a subject, an authentication event, and potentially attributes. A NameID identifies the subject; it may be an email-shaped value or a persistent opaque identifier. Do not assume it always equals the person’s email address.
An SP-initiated browser flow
Section titled “An SP-initiated browser flow”- The user opens the application.
- The SP creates an AuthnRequest and directs the browser to the IdP.
- The IdP authenticates the user, potentially reusing its existing session.
- The browser delivers a SAML Response containing an assertion to the SP’s Assertion Consumer Service (ACS).
- The SP validates the response, resolves the local user, and creates an application session.
Validation includes signatures, trusted issuer, audience, destination, time constraints, and request correlation where applicable. Use a maintained SAML library. Some applications also support IdP-initiated login, which requires its own security assessment.
OpenID Connect and OAuth 2.0
Section titled “OpenID Connect and OAuth 2.0”OAuth 2.0 is primarily a framework for delegated authorization, such as granting access to an API. OIDC adds authentication on top of it. Obtaining an OAuth access token alone is not a complete login protocol.
An OIDC ID Token is a JWT containing claims about authentication and the subject. Applications normally identify a user with the combination of issuer (iss) and subject (sub). An Access Token serves a different purpose: accessing a protected resource.
Authorization Code Flow
Section titled “Authorization Code Flow”- The RP sends the browser to the OP with a request including
scope=openid, a registeredredirect_uri, and request-correlation protections such asstate. - The OP authenticates the user and obtains consent where required.
- The OP returns a short-lived authorization code to the registered redirect URI.
- The RP exchanges the code at the token endpoint using PKCE and, for confidential clients, client authentication.
- The RP validates the ID Token and establishes an application session.
Checks include signature, issuer, audience, expiry, and the expected nonce if sent. PKCE binds the code exchange to the client that initiated the request, limiting abuse of intercepted codes. Treat this as an overview; follow current security guidance and your library’s integration requirements.
SAML and OIDC compared
Section titled “SAML and OIDC compared”| Aspect | SAML 2.0 | OIDC 1.0 |
|---|---|---|
| Authentication artifact | XML assertion | JWT ID Token |
| Application role | SP | RP or client |
| Subject identification | NameID or agreed attributes | Usually issuer plus subject |
| Common use | Enterprise web federation | Web and mobile sign-in |
| Configuration focus | Metadata, certificates, ACS, audience | Discovery, keys, client registration, redirect URIs |
Both work beyond SaaS. Choose based on application support, maintained libraries, and operational requirements.
How federation relates to SSO
Section titled “How federation relates to SSO”Identity federation establishes trust so systems or organizations can exchange identity information. SAML and OIDC federation can deliver SSO. Other mechanisms, including Kerberos in internal domains, can also provide a single sign-on experience.
Cloud identity platforms, MFA, and access policies
Section titled “Cloud identity platforms, MFA, and access policies”Microsoft Entra ID is one example of a cloud platform that applications can trust for authentication. Multifactor authentication (MFA) combines different factor types to strengthen verification. SSO and MFA address different needs and can work together.
Conditional access applies requirements based on context such as user, device, or location. Confirm current product support and licensing. Do not assume that every action within an application’s existing session causes a fresh identity-platform policy evaluation.
See how passkeys work for authentication methods, and NIST’s zero trust architecture for resource-oriented access decisions.
Security and operational considerations
Section titled “Security and operational considerations”| Concern | What to establish |
|---|---|
| IdP outage | Impact on new logins, recovery ownership, business continuity, and existing-session behavior |
| MFA and access policy | Coverage for users and administrators, with documented exceptions |
| Alternate login paths | Local passwords, other IdPs, mobile clients, and API access |
| Existing sessions | Application sessions and IdP sessions are separate; test revocation explicitly |
| Emergency administration | Protect, monitor, and periodically test a recovery route when normal authentication fails |
| Certificates and keys | Renewal ownership, expiry monitoring, and rotation procedures |
| User identifiers | Behavior during email changes, renaming, and rehire |
Blocking SSO sign-in does not guarantee that the application’s account or sessions are disabled. Single logout also depends on both parties’ support and configuration; it is not universal revocation of every token.
Deployment checklist
Section titled “Deployment checklist”Inventory protocol support, licensing, user identifiers, and existing-account mappings. Pilot normal login as well as denial for unassigned users, MFA, identifier changes, key rotation, and recovery. Verify alternate paths and the offboarding process before expanding deployment. Assign owners for configuration changes and incident response.
Where provisioning fits
Section titled “Where provisioning fits”Some applications create accounts at first federated login through JIT provisioning. Preparing users in advance and maintaining accounts for people who never log in require separate lifecycle processes. See SSO vs. account provisioning for the distinction and SCIM and account provisioning for implementation.
Summary
Section titled “Summary”SSO centralizes authentication. A complete design also verifies protocol messages, protects the IdP, manages permissions and accounts, and handles sessions and recovery explicitly.