02.04 · One login, many apps

Single Sign-On

A pattern that lets you authenticate once and reach every application you're entitled to. Solves the password-fatigue problem and concentrates organizational risk into one identity provider, where both gains and losses are amplified.

The point of SSO

Before SSO, every app was its own kingdom. You had a separate account at Email, HR, Payroll, the wiki, the bug tracker, the file server, the building access system. Each one stored its own copy of your password (badly), set its own session timeout (incorrectly), and forgot to revoke your access when you left the company (always). Users coped by reusing one password everywhere — which meant any one app's breach took the others with it.

SSO collapses that into a single relationship: the user authenticates to one system (an Identity Provider), and every downstream app trusts the IdP's assertion of who they are. One login. One password to enforce well. One place to add MFA. One place to disable the account when someone leaves.

The three roles

Role 1

User

The human (or service) trying to log in. They start at the app they want to use and end up authenticated there — without ever entering credentials at that app.

Example: you
Role 2

Service Provider (SP)

The app the user wants to reach. The SP doesn't store passwords, doesn't check passwords, doesn't know how the user authenticated. It just asks: "Is this person legit? IdP, vouch for them."

Examples: Brightspace, Workday, Slack
Role 3

Identity Provider (IdP)

The system that holds the user's account, enforces password / MFA / passkey policy, runs the actual authentication, and issues signed assertions that other systems trust.

Examples: Okta, Microsoft Entra ID, Google Workspace, Shibboleth (Northgate's)

SP and RP (Relying Party) mean the same thing. SAML uses "SP"; OIDC uses "RP". Same role.

The SSO dance, step by step

What actually happens when you click "Sign in" on a service connected to your university SSO. Press Play (or step through manually) to watch the redirects.

Sequence: User logs into Brightspace via Northgate SSO
User (browser)
SP · brightspace.northgate.edu
IdP · sso.northgate.edu

Key property: the browser is the only one that talks to both the SP and the IdP. The SP and IdP never directly exchange credentials — the user (via redirects) is the message carrier. Every part of SSO security depends on the signed assertion being unforgeable and bound to this user, this SP, and this moment.

SSO sessions — the sneaky part

The user really has three sessions running:

  • The SP session at Brightspace, controlled by a Brightspace cookie. Typical lifetime: hours.
  • The IdP session at sso.northgate.edu, controlled by an IdP cookie. Typical lifetime: 8 hours to days.
  • The primary auth event — the actual password / passkey moment. The IdP remembers this for its session lifetime, so subsequent logins to other SPs happen silently ("you were already signed in").

If you log out of Brightspace but not of the IdP, going back to Brightspace silently logs you back in. To truly log out you must single log-out — clear both sessions. Most users don't.

The trade-off you cannot opt out of

The single most important sentence in this module

SSO concentrates risk along with convenience. One IdP compromised means every SP it serves is compromised. The bargain is real and there is no architecture that escapes it — only architectures that pay more attention to the IdP because of it.

Practical consequences:

  • The IdP must use phishing-resistant MFA. Phishable MFA on an SSO IdP is the single highest-leverage credential in the organization.
  • The IdP must monitor anomalies aggressively. Login from a new country, new device, impossible-travel patterns — the IdP is the only place to see these signals.
  • The IdP must support hard recovery without lowering the bar. "Forgot password" → SMS reset on the IdP undoes everything.
  • Provisioning and de-provisioning go through the IdP. When someone leaves, disabling them at the IdP must instantly kill all SP sessions. (In practice, SAML doesn't enforce this; SCIM is the protocol that adds it.)

SSO vs. password manager — a common confusion

A password manager (1Password, Bitwarden, your browser's built-in one) is not SSO. It still has separate accounts at each site; it just types the passwords for you. SSO eliminates the separate accounts entirely. They are complementary: SSO for everything that supports it, password manager for the long tail of sites that don't.

When SSO fails — real incidents

  • Okta (2022). A third-party support contractor's laptop was compromised, granting attackers access to the Okta tenant of one of Okta's customers. The blast radius was a single customer (~366 organizations had some Okta-connected access touched). Worse: Okta initially under-disclosed it, which became its own incident.
  • Okta (Oct 2023). The Okta customer-support case-management system was compromised. Attackers read session tokens from uploaded HAR files. Customers including 1Password, Cloudflare, BeyondTrust, and others noticed before Okta and reported the breach to Okta.
  • SolarWinds / Microsoft 365 (2020). Attackers forged SAML tokens via the “Golden SAML” technique after compromising on-prem ADFS signing keys. Federated identity means a stolen signing key authenticates as anyone.
  • Microsoft (2023). An expired consumer signing key was used to mint forged tokens for Exchange Online — including government accounts. The root cause: a crash dump unexpectedly contained the key, the key landed in a corporate environment, and the key was then stolen.