How Single Sign On Works: The SSO Flow, Protocols and Sessions Step by Step

Single sign-on (SSO) lets a person sign in once to a trusted identity provider and then reach many applications without signing in to each one, because the applications accept proof of that sign-in instead of checking a password themselves. It is the backbone of workforce identity, yet the mechanics, who sends what to whom and where sessions live, are rarely explained clearly. This guide walks through the SSO flow step by step, compares SAML 2.0, OpenID Connect and Kerberos, explains desktop SSO with Kerberos and the Entra ID Primary Refresh Token, and sets out where SSO strengthens security and where it concentrates risk. It is for practitioners, application owners and executives who need to understand SSO before they harden or buy it. Attacks and hardening are covered in the Identity Provider and SSO Security Guide.

Key takeaways

• The identity provider authenticates; the application trusts. In SSO the application (service provider or relying party) never sees the password; it validates a signed assertion or token issued by the identity provider (IdP).
• There are at least two sessions. One session at the IdP and a separate one at each application; signing out of one does not automatically end the others, which is why logout is the hardest part of SSO.
• Three protocols do most of the work. SAML 2.0 for many enterprise web apps, OpenID Connect (an identity layer on OAuth 2.0) for modern web and mobile apps, and Kerberos for desktop and on-premises SSO in Active Directory.
• Signing keys are the crown jewels. Anyone holding the IdP's token-signing key can mint valid sign-ins for any user, as the Golden SAML technique showed.
• SSO concentrates control and risk. It enables one place for MFA, Conditional Access and offboarding, and it also makes the IdP and its administrators a single point of compromise.

What it is

SSO is a trust arrangement between parties with defined roles. The names differ by protocol but the pattern is the same.

OAuth 2.0 (RFC 6749) on its own is not SSO: it is an authorisation framework that lets an application obtain limited access to an HTTP service, and the RFC states that how the user is authenticated is beyond its scope. OpenID Connect adds the missing identity layer, and requests must include the openid scope. See the OAuth 2.0 and OpenID Connect Guide.

How it works

Step by step: SP-initiated SAML sign-in

Based on the OASIS SAML 2.0 Technical Overview, using the Redirect and POST bindings:

1. Request: the user opens an application without a session. The application remembers the requested page.
2. Redirect to IdP: the application redirects the browser to the IdP with an AuthnRequest in the SAMLRequest parameter and a RelayState value.
3. Authenticate: if the user has no IdP session, the IdP challenges them (password, passkey, MFA). If they already have one, this step is silent: that is the "single" in single sign-on.
4. Assert: the IdP creates a signed assertion with authentication and attribute statements and returns it to the browser in an HTML form.
5. Post to the application: the browser posts the form to the application's Assertion Consumer Service. The application validates the signature, audience and time window.
6. Local session: the application creates its own session, usually a cookie, and sends the user to the original page after its own access check.

IdP-initiated SSO skips steps 1 and 2: the user clicks an app tile in the IdP portal and the IdP posts an unsolicited assertion. It is convenient, but the application cannot tie the response to a request it made, so SP-initiated flows are generally preferred. See the SAML Security Guide.

Step by step: OpenID Connect authorisation code flow

1. The application redirects the browser to the OpenID Provider's authorisation endpoint with response_type=code, scope=openid, its client_id, a redirect_uri, and state and nonce values.
2. The provider authenticates the user, or reuses its existing session.
3. The provider redirects back with a one-time authorisation code.
4. The application exchanges the code at the token endpoint, server to server, for an ID token and an access token. No tokens pass through the browser in this flow.
5. The application validates the ID token: signature, iss, aud (must contain its client ID), exp, iat and that nonce matches what it sent, then creates its own session.

Applications can force a fresh sign-in with prompt=login or max_age (with max_age=0 equivalent to prompt=login, and the ID token then carrying auth_time), or ask for a silent check with prompt=none.

Desktop SSO: Kerberos and the Primary Refresh Token

• Kerberos in Active Directory: at Windows sign-in the client gets a ticket-granting ticket (TGT) from the Key Distribution Center on a domain controller and caches it. To reach a file share, intranet site or SQL server, it presents the TGT to get a service ticket and sends that to the service, which can authenticate the user without contacting a domain controller each time. Kerberos also gives mutual authentication, which NTLM does not. Browsers use it for intranet sites through Integrated Windows Authentication. See Active Directory Fundamentals and the Kerberos Security Guide.
• Primary Refresh Token (PRT) in Entra ID: on Entra joined, hybrid joined and registered devices, sign-in produces a PRT bound to a device key, protected by the TPM where present. Microsoft documents that it is valid for 90 days and renewed while the device is used (every 4 hours at Windows sign-in). The Web Account Manager uses it to get tokens silently for apps such as Outlook and Teams, and supported browsers send it in the x-ms-RefreshTokenCredential header. It does not apply in private browsing modes, and Conditional Access is not evaluated when the PRT itself is issued or renewed, only when app tokens are requested. See the Entra ID Primary Refresh Token (PRT) Security Guide.

Sessions and logout

NIST SP 800-63B-4 gives reauthentication limits that are a sensible reference for session lifetime: at AAL2 an overall timeout of no more than 24 hours and an inactivity timeout of no more than 1 hour (both "should"); at AAL3 no more than 12 hours overall ("shall") and 15 minutes of inactivity ("should"); at AAL1 up to 30 days. See the OpenID Connect Logout and Session Management Guide.

Why it matters

In NIST SP 800-53 terms, SSO implements IA-2 for staff and IA-8 for external users, and its session handling maps to AC-12 Session Termination and SC-23 Session Authenticity. Useful measures of an SSO programme: percentage of applications behind SSO, percentage of SSO sign-ins using phishing-resistant MFA, number of applications that still accept local passwords, median time from leaver to all sessions revoked, and age of IdP signing certificates.

Common misconceptions

• "SSO means one password for everything." SSO means one sign-in at one trusted place; applications never receive the password. A password manager filling the same password everywhere is not SSO.
• "Logging out of the portal logs me out everywhere." Only if the applications support and are configured for single logout or back-channel logout; otherwise their sessions continue until they expire.
• "OAuth is a sign-in protocol." OAuth grants access tokens; using a bare access token as proof of identity is a known mistake. OpenID Connect's ID token is the sign-in proof.
• "SAML is obsolete." SAML 2.0 remains widely used for enterprise web applications; OIDC is generally preferred for new web, mobile and API-driven apps. See the SAML vs OIDC Guide.
• "MFA at the IdP protects everything after." MFA protects the sign-in event. Once a session cookie or token exists, whoever holds it is the user until it expires or is revoked. See the Infostealer Logs and Session Token Abuse Guide.
• "Federation and SSO are the same." Federation is the trust between separate organisations or domains; SSO is the user experience it can deliver. See the Federation and Trust Relationships Guide.

Related concepts

• Provisioning: SSO handles sign-in, not account creation; SCIM handles joiners and leavers in each application. See the SCIM Provisioning Guide.
• Federation assurance: NIST SP 800-63C-4 grades how strongly assertions are protected. See the NIST SP 800-63C-4 Federation Assurance Levels Guide.
• Token binding: device-bound session credentials reduce cookie theft. See the Device-Bound Session Credentials (DBSC) Guide.
• Machine SSO: workloads use OIDC federation instead of stored keys. See the GitHub Actions OIDC Federation Hardening Guide.

Practitioner checklist

• Inventory every application and record whether it uses SAML, OIDC, Kerberos or local passwords.
• Prefer SP-initiated SAML and the OIDC authorisation code flow; validate signature, audience, issuer, expiry and nonce every time.
• Disable local password sign-in on applications once SSO works, keeping a documented break-glass account.
• Set session lifetimes per application risk, using NIST SP 800-63B-4 AAL2 and AAL3 limits as a reference.
• Configure single logout or back-channel logout where supported, and test that a disabled user loses every session.
• Protect IdP signing keys in hardware where possible, track certificate expiry and rotation, and alert on federation trust changes.
• Treat IdP administrators as Tier 0, with phishing-resistant MFA and help desk verification for resets.

Standards and references

• OASIS: Security Assertion Markup Language (SAML) V2.0 Technical Overview
• OpenID Foundation: OpenID Connect Core 1.0
• OpenID Foundation: OpenID Connect Back-Channel Logout 1.0
• IETF: RFC 6749 The OAuth 2.0 Authorization Framework
• NIST: SP 800-63B-4 Authentication and Authenticator Management
• Microsoft Learn: Kerberos authentication overview
• Microsoft Learn: Understanding Primary Refresh Token (PRT)

Related NHI Mgmt Group resources: Identity Provider and SSO Security Guide · SAML vs OIDC Guide · OAuth 2.0 and OpenID Connect Guide · Golden SAML and Federation Trust Abuse Defence Guide