Single Sign-On (SSO): How It Works, SAML vs. OIDC, and Integration

Single sign-on (SSO) lets a person authenticate with an identity provider (IdP) and use that authentication to access multiple independent applications. It reduces repeated sign-ins, but it does not make applications share one authorization policy or one session. Developers and IT teams need to understand the trust relationship, protocol, and session lifecycle before enabling SSO for a web app, SaaS tool, or internal service.

What Is Single Sign-On?

SSO is an identity-federation pattern: a user signs in to an IdP, and that trusted IdP provides an application with a verifiable statement about the authentication. The application, often called the service provider (SP) or relying party (RP), validates that statement and creates its own session.

The user may then visit another application connected to the same IdP. If the IdP still has a valid session, it can issue a new response without asking the user to enter credentials again. The applications remain separate services with separate sessions and access rules.

SSO is not the same as password synchronization, authorization, or account provisioning. It centralizes or delegates authentication; each application must still decide what an authenticated user may do and how that user’s account is created, updated, or disabled.

Why SSO Exists

Without federation, every application can maintain its own credentials, sign-in flow, and recovery process. Users may reuse passwords, administrators must manage accounts in multiple places, and an employee’s departure can leave forgotten accounts behind.

An IdP gives an organization a consistent point to enforce authentication policies such as multifactor authentication (MFA), conditional access, and account risk checks. A relying application can accept the result rather than handling the user’s primary credentials itself. Centralization can improve oversight, but it also makes the IdP a high-value service: an IdP outage can block sign-in to connected apps, and a compromised IdP account can have broad impact.

SSO reduces the number of application passwords; it does not eliminate phishing, compromised sessions, excessive permissions, or weak recovery processes. Strong IdP protection, app-specific authorization, and tested recovery paths remain necessary.

How SSO Works: Architecture and Request Flow

A common browser-based flow is:

User's browser -> Application -> Identity provider
       ^                                |
       |                                | authenticates user and returns
       |                                | a signed protocol response
       +------ Application validates response
               and creates its own session

1. The user requests a protected page at an application.
2. The application starts an authentication request and redirects the browser to its configured IdP.
3. The IdP checks its own session. If needed, it authenticates the user and applies policy such as MFA.
4. The IdP returns a protocol response to a registered application endpoint.
5. The application validates the response, maps permitted identity attributes, and creates its own session.
6. The application uses that local session for later requests until it expires or is revoked.

The browser carries redirects and responses between the parties, but the application must not treat a redirect or decoded token as proof of identity. It must verify the expected issuer, signature, audience, time limits, and flow-specific correlation values using a maintained protocol library.

OpenID Connect flow

OpenID Connect (OIDC) is an identity layer built on OAuth 2.0. For a typical web sign-in, the application uses the authorization code flow. It sends the browser to the IdP, receives a short-lived authorization code at a pre-registered callback, and exchanges that code for tokens. Public clients such as single-page or mobile apps use Proof Key for Code Exchange (PKCE); confidential web clients should also use PKCE where supported.

The ID token communicates authentication information to the client. An access token is intended for a resource server, such as an API; it is not a substitute for an ID token when the client needs to establish a user session. The application validates the ID token’s signature, issuer, audience, expiration, and nonce, and checks the request’s state before accepting the response. Use the OpenID Connect Core specification for protocol requirements and the OAuth 2.0 Security Best Current Practice for current security guidance.

SAML flow

Security Assertion Markup Language (SAML) is an XML-based federation protocol widely used for browser-based enterprise integrations. In an SP-initiated flow, the application sends a SAML authentication request to the IdP. The IdP returns a signed assertion through the browser to the application’s Assertion Consumer Service (ACS) endpoint.

The application checks the signature against trusted IdP keys and validates the assertion’s issuer, audience, recipient, destination, validity window, and request correlation where applicable. It also prevents replay and safely handles any return destination. SAML messages must be parsed and verified with a maintained library; custom XML signature handling is not an appropriate shortcut. The OASIS SAML 2.0 specification defines the core assertions and protocol.

Sessions, logout, and account lifecycle

The IdP session and each application session have independent cookies, expiration policies, and revocation behavior. Signing out of one application may not sign a user out of the IdP or other apps. SAML Single Logout and OIDC logout mechanisms can coordinate some participants, but support and delivery are not universal; design and test the behavior rather than promising global logout.

Authentication also does not automatically create or remove application accounts. Just-in-time provisioning may create an account during first sign-in, while SCIM can synchronize account and group lifecycle events separately. Treat deprovisioning as a distinct control and confirm how quickly disabled users lose both IdP access and existing application sessions. The SCIM protocol specification, RFC 7644 describes a standard provisioning interface.

Components and Protocol Variants

An SSO integration normally involves:

Choose based on what the application and IdP actually support, the type of client, and how users and permissions are managed. An organization may use more than one protocol; keep each registration and its trust boundaries explicit. For a directory-based environment, the Active Directory architecture and management guide explains how directory identities, LDAP, DNS, and Kerberos fit together.

Real-World SSO Use Cases

• Employee SaaS access: Staff authenticate through a corporate IdP to reach collaboration, finance, or HR services, with MFA and access policy applied centrally.
• Customer accounts across a product suite: Related applications can rely on a customer identity platform while retaining distinct application permissions and session controls.
• Internal developer platforms: Engineers use a common IdP to reach source hosting, deployment dashboards, and service catalogs without each tool collecting a separate primary password.
• Hybrid Windows and Linux estates: A directory can remain the source of identity attributes while federation handles application sign-in. Directory lookup and SSO solve different parts of the design; see the Linux LDAP integration guide.

SSO is useful when repeated authentication or inconsistent policy is a real problem. It is not automatically the right choice for every machine-to-machine credential, highly isolated system, or emergency account. Workload identity and short-lived service credentials are usually better suited to non-human access.

Practical SSO Integration Considerations

Register the application and inspect IdP metadata

Before coding, choose the protocol and client type, register exact redirect or ACS URLs, identify the trusted issuer, and agree on the claims or attributes the application needs. Use separate registrations and keys for development, staging, and production. Request only necessary attributes and scopes; do not use a display name or email address as a durable authorization identifier without an explicit lifecycle policy.

For OIDC providers that publish discovery metadata, inspect the configured issuer and endpoints before wiring a client:

curl --fail --silent --show-error \
  https://idp.example.com/.well-known/openid-configuration

This illustrative configuration captures common OIDC registration choices; it is not a product-specific configuration file. Store confidential client credentials in a secret manager or protected environment configuration, never in source control.

issuer: https://idp.example.com
client_id: web-portal
redirect_uri: https://app.example.com/auth/callback
response_type: code
scopes:
  - openid
  - profile
  - email
pkce: S256

Protect the sign-in and application sessions

• Use a maintained OIDC or SAML library and follow its secure defaults; do not implement token or XML signature validation yourself.
• Match redirect and ACS URLs exactly against registered values. Validate state for request correlation and cross-site request forgery protection; validate OIDC nonce and use PKCE for code flows.
• Validate token or assertion signature, issuer, audience, expiration, and the protocol-specific recipient and correlation fields. Reject unexpected algorithms, issuers, audiences, or destinations.
• Create an application session only after successful validation. Use HTTPS and appropriately configured Secure, HttpOnly, and SameSite cookies; rotate the session identifier after authentication and expire or revoke sessions according to risk.
• Keep authorization in the application. Map only approved claims or groups to roles, and define what happens when a role or group claim is missing or stale.
• Protect the IdP with MFA and strong administrative controls. Monitor authentication failures, configuration changes, certificate/key rotation, and provisioning events.

Test the failure paths

Test both successful sign-in and rejected responses: expired or replayed assertions, wrong audience or issuer, altered state, unknown users, disabled accounts, IdP outage, lost signing-key rollover, and denied application access. Verify sign-in and sign-out across multiple apps, including existing sessions. Record how administrators regain access if the IdP or federation configuration fails.

For the wider operational controls around identity, monitoring, and device access, see digital workplace security best practices. Logging can help investigate federation failures; the Windows Event Log analysis and monitoring guide covers one common source, and PowerShell automation guidance can help with repeatable Windows administration.

Common SSO Misconceptions

• “SSO means one shared session everywhere.” The IdP and each app generally maintain separate sessions. A valid IdP session may avoid another credential prompt, but applications still issue their own cookies.
• “OAuth 2.0 is a login protocol.” OAuth defines delegated access. Use OIDC when the client needs standardized user authentication and identity claims.
• “Authentication grants access to every feature.” A valid identity proves who signed in; the application still evaluates roles, resource ownership, and policy.
• “Single logout always logs a user out of every app.” Logout coordination depends on protocol and participant support. Revoke or expire local sessions deliberately and test the result.
• “SSO provisions and removes accounts.” Federation communicates authentication; provisioning, group synchronization, and deprovisioning require separate lifecycle mechanisms and checks.
• “Centralized sign-in is automatically more secure.” SSO can strengthen policy, but a compromised IdP account or weak recovery flow can affect many connected applications.

Related Articles

• Linux LDAP integration with NSS, PAM, and SSSD
• Active Directory architecture and management
• Digital workplace security best practices
• Accessible authentication systems
• Intune MDM configuration for Windows devices
• Windows Event Log analysis and monitoring
• Windows automation with PowerShell