Course Preview

Single Sign-On

Single sign-on lets one authenticated identity-provider session open multiple connected applications without asking for credentials each time. Each application still validates the sign-in response, creates its own session, and enforces its own permissions.

itIdentity, access, and cryptography | OpenSkills.info

Course pathWalk it in order

Look it upDip in anytime

Go furtherLeaves this page

Don't Panic — Single Sign-On

Single sign-on is a way for several applications to reuse one successful sign-in without pretending that they have merged into one enormous application. That last part matters. The browser may stop asking for credentials, but each application still checks its own evidence, creates its own session, and decides what its local account may do. The login screens have merely agreed to stop making the same introduction repeatedly.

The central character is the identity provider, the service that authenticates the user and keeps the central session. When an application needs a sign-in, it sends the browser there. The identity provider returns signed authentication evidence. The application then checks the issuer, signature, intended audience, return location, transaction values, time window, and claims before it lets anyone in. A signature alone is not a diplomatic passport for every door in the building.

The useful mental picture has three moving parts. The identity-provider session decides whether another authentication prompt is needed. A short protocol transaction carries evidence between the parties. The application session decides whether the browser can continue using that one application. They have different owners and expiry rules, which explains why local logout often ends one session while the next visit quietly signs in again through the still-active central session.

For browser federation, SAML version two and OpenID Connect do much of the heavy lifting. SAML uses XML assertions and is common in established enterprise connections. OpenID Connect adds an authentication result to OAuth version two and commonly uses an authorization code before the application receives an ID Token. OAuth alone is for delegated API access; an access token and an ID Token may resemble small, serious-looking parcels, but they have different destinations and jobs.

SSO also does not replace authorization or provisioning. A claim can help an application map an account, but the application still owns permissions. SCIM and just-in-time provisioning handle account lifecycle on a different schedule. That is why a centrally disabled user can still have an existing application session, and why session limits and revocation paths matter even after the sign-in route looks tidy.

Centralizing authentication brings a welcome reduction in repeated password entry and a less welcome concentration of risk. An identity-provider outage can block new sign-ins across connected applications. A compromised signing key or privileged administrator can affect every relying party. Key rollover therefore needs overlapping trust material, refreshed metadata, and a test before the old key goes away. Otherwise the first test is conducted by everyone trying to log in, which is an inefficient form of theatre.

Read the Intro for the complete trust path and the limits around sessions, logout, and lifecycle. Use the Slides to keep the actors and session layers straight. Keep the Cheatsheet nearby when comparing SAML with OpenID Connect or diagnosing a failed connection. The Field Notes concentrate the operational decisions that tend to arrive later, carrying a clipboard and an unpleasantly specific question.

Where this skill leads

Relevant careers

See how this topic contributes to broader role-level skill maps.

Security Engineersupporting

Sources