What Is Single Sign-On (SSO)?

Single sign-on (SSO) is an authentication capability that lets a user establish one session with a trusted identity provider and then access multiple connected applications without entering credentials again for each one, while each application still makes its own authorization decisions.

SSO reduces the number of separate login events an employee encounters during a work session. Instead of every application independently collecting a password, connected applications rely on authentication performed by an identity provider (IdP) under an established trust relationship.

That convenience has a precise boundary. SSO can carry verified identity and authentication information to an application, but it does not automatically decide which files, records or administrative actions the user may access. It also does not prove that the user's endpoint is healthy.

An identity provider is the prerequisite component that authenticates the user and issues information an application can validate. This article places SSO within the wider identity and device trust model.

Why single sign-on matters

Without SSO, employees may maintain separate credentials and sessions for email, collaboration, finance, support and other applications. Each additional login creates another place to enter, transmit, store, reset and potentially expose credentials. It also encourages inconsistent sign-in experiences and makes authentication policy harder to coordinate.

SSO moves the primary authentication event to a shared identity layer. Applications can accept a verifiable assertion or identity token instead of handling the user's primary credential themselves. Centralization can make it easier to apply stronger authentication, disable access through a common identity control and observe sign-in activity across connected services.

SSO does not remove application accounts or authorization. A finance application still needs to know whether an authenticated employee may approve an invoice, and a code repository still needs project-level permissions. Identity and access management includes those broader identity lifecycle and access-governance responsibilities; SSO addresses the shared sign-in experience within that system.

How single sign-on works

Most enterprise SSO uses a federated login flow. The IdP and application establish trust before the user signs in, including identifiers, endpoints, accepted protocol behavior and cryptographic keys. The application is commonly called a service provider in Security Assertion Markup Language (SAML) or a relying party in OpenID Connect (OIDC).

A typical application-initiated flow follows this sequence:

1. The user requests an application. The application finds no acceptable local session and starts an authentication request.
2. The application redirects to the IdP. The request identifies the application and includes protocol values that bind the response to the intended transaction.
3. The IdP evaluates its session and policy. If no suitable IdP session exists, the user authenticates. The IdP may require multifactor authentication or another step according to policy.
4. The IdP returns a signed response. The response contains an assertion or ID token with identity and authentication claims for the intended application.
5. The application validates the response. It checks items such as the issuer, audience, signature, time limits, transaction binding and expected destination before accepting the result.
6. The application creates its own session. It maps the federated identity to an account, applies local authorization and issues an application session.

NIST describes federation as an IdP making a subscriber account available to a relying party through a protocol and calls the resulting process single sign-on in its current NIST guidance. The shared IdP session avoids another credential prompt, but each application session remains a separate security boundary.

IdP-initiated and application-initiated SSO

In application-initiated SSO, the user begins at the application, which sends an authentication request to the IdP. This flow gives the application transaction context that it can bind to the response.

In IdP-initiated SSO, the user begins in an IdP portal and selects an application. The IdP sends a response without a matching authentication request from that application. Some SAML deployments support both approaches; the OASIS overview documents the distinct browser flows and their message bindings. Security requirements and supported flows depend on the protocol and implementation.

SSO components and trust boundaries

SSO is a coordinated system rather than one shared session copied everywhere. Each component has a distinct responsibility.

The application should accept only responses intended for it and only from an expected issuer. Audience restrictions, expiration, transaction correlation and signature validation help prevent a valid response from being reused in the wrong context. A successful signature alone is not sufficient if the application ignores the rest of the protocol checks.

SAML and OpenID Connect

SAML and OIDC can both support federated SSO, but they package and exchange identity information differently. SAML commonly uses XML assertions and browser bindings between an IdP and a service provider. OIDC is an identity layer built on OAuth 2.0 and uses an ID token containing claims about authentication; the controlling OIDC Core specification defines how a client verifies the user's identity from that result.

OAuth 2.0 alone is an authorization framework, not a user-authentication protocol. An OAuth access token represents delegated access to a protected resource; it should not be treated as proof of user authentication unless a defined identity protocol such as OIDC supplies and validates that meaning.

A federated login example

Lakehouse Studio, a fictional architecture company, connects its project system, expense service and document portal to one corporate IdP. Priya starts at the project system from her assigned laptop. The application redirects her to the IdP, which has no current session and asks for her passkey plus a policy-required verification step.

After authentication, the IdP returns a response intended for the project system. The application validates it, maps Priya's federated identifier to her local account and creates a session with access to her assigned projects. When she opens the expense service minutes later, that service redirects to the same IdP. The existing IdP session satisfies its authentication policy, so Priya does not enter credentials again.

The expense service still checks its own permissions and lets Priya submit an expense but not approve it. Later, an administrator disables Priya's identity during offboarding. New SSO attempts stop at the IdP, but the team must also terminate or expire existing application sessions and remove application assignments. Central authentication does not guarantee instant revocation inside every connected service.

SSO and trusted-device context

SSO establishes a reusable user-authentication context. It does not establish device trust by itself. A valid IdP session may be presented from a managed laptop, an unmanaged home computer or a compromised browser session unless the access policy also evaluates endpoint evidence.

Organizations can combine SSO with device trust by evaluating device identity, management state, posture, evidence freshness and resource sensitivity during the sign-in decision. The result may allow routine access, require stronger authentication, restrict a session to lower-risk actions or deny the request. Conditional access is the downstream control that turns those identity, device and risk signals into an access outcome.

Device records and posture commonly originate in an endpoint management layer. Teams evaluating how to maintain that mixed-fleet context can review unified endpoint management; the IdP and each application remain responsible for authentication policy, protocol validation and resource authorization.

Benefits of single sign-on

Well-designed SSO can improve both the employee experience and the consistency of identity controls.

• Fewer credential prompts: Users authenticate through a common identity service instead of entering a separate password into every connected application.
• Reduced credential exposure: Applications can rely on federated results without receiving or storing the user's primary IdP credential.
• More consistent authentication policy: The identity team can apply supported authentication and session requirements at a shared control point.
• Faster access changes: Disabling an IdP account or removing an assignment can block new authentication to many connected applications.
• Clearer sign-in evidence: Central IdP events can show authentication method, application, time and decision, while application logs record local session and authorization activity.
• Simpler application onboarding: A defined federation interface can reduce the need to create a separate authentication design for every service.

These benefits grow with integration coverage and reliable account lifecycle management. An application outside SSO, a local emergency account or a long-lived application session can remain accessible through a separate path.

Single sign-on risks and limitations

SSO concentrates authentication, which makes its design and operation consequential. Important failure conditions include:

• Session compromise: An attacker who obtains an active IdP or browser session may reach several applications without needing the user's password again.
• IdP dependency: An IdP outage, configuration error or unavailable authentication method can interrupt access across many connected services.
• Weak application validation: Incorrect issuer, audience, signature, destination or transaction checks can let an application accept a response it should reject.
• Overbroad session policy: A long IdP session or weak reauthentication rule can carry old assurance into a more sensitive request.
• Incomplete logout: Ending one application session may not end the IdP session or sessions at other applications. Users and administrators need clear expectations for logout and revocation.
• Lifecycle gaps: Disabling the IdP account may block new sign-ins while existing local sessions, separate application accounts or cached permissions remain active.
• Attribute and mapping errors: An unstable identifier or incorrect group claim can create the wrong local account or permissions.
• Phishing persistence: SSO reduces password entry points but does not eliminate deceptive sign-in pages, consent abuse or theft of session material.
• Missing device assurance: Successful user authentication says nothing by itself about endpoint ownership, configuration or compromise.

Risk should be managed across the full chain: protect authenticators and IdP administration, use suitable multifactor or phishing-resistant methods, configure federation narrowly, validate every response, limit session duration, monitor sign-ins and coordinate deprovisioning with local session revocation.

SSO and related concepts

Several identity terms describe different parts of the same access system.

Multifactor authentication and SSO are complementary, not interchangeable. MFA changes the evidence required to establish or renew an authentication session; SSO determines how connected applications reuse the resulting authentication context.

Single sign-on is therefore best understood as controlled reuse of authentication, not universal access. The IdP establishes a session and sends verifiable identity information, each application validates that information and authorizes its own resources, and policy can require fresh user or device evidence when context changes.