History of SSO

Start with a shared computer. Several people need to use the same machine, keep their files separate, and return to their work later. An account gives the operating system a way to distinguish them, while a password supplies evidence that the returning user controls that account.

Early time-sharing systems, including MIT's CTSS in the 1960s, made this a practical problem. The account's meaning was local: this machine knew its users and enforced access to its resources.

Then the work spread across a network. A person needed several services, and sending a reusable password to each one created more places where it could be exposed.

Kerberos, developed through MIT's Project Athena, introduced a trusted authentication service and tickets for accessing network services. A user could authenticate and obtain a ticket for a particular service, which could check that ticket under the protocol's rules.

The useful change was where trust lived. Each service could rely on the authentication infrastructure instead of collecting the user's password for every interaction.

Organizations also needed a shared place to manage employees and their access. A directory could hold accounts and group membership, while authentication mechanisms let computers and services use that organizational identity.

Windows domain environments brought these pieces into everyday workplace sign-in. A Windows domain is a group of computers and accounts managed together, a different meaning of domain from a DNS name. Kerberos became the default domain authentication protocol with Windows 2000, alongside the continuing presence of older mechanisms such as NTLM, an earlier Windows protocol in which a computer proved it knew a password by answering a challenge.

The convenience depended on administration as well as cryptography. Someone still had to create accounts, assign suitable access, and remove it when employees left.

Windows domain×

A group of computers and accounts managed together

Directory

Accounts and group membership

Authentication

Kerberos, the default with Windows 2000

Older mechanisms

Such as NTLM

Computers and services use that organizational identity.

Administration×

Someone still had to

• Join: create accounts
• Change jobs: assign suitable access
• Leave: remove it when employees left

The convenience depended on administration as well as cryptography.

Web applications introduced another boundary. Each application had its own HTTP requests, cookies, and sessions. Signing in to one site did not automatically sign a browser in to another.

Systems such as Yale's Central Authentication Service, or CAS, used browser redirects to a central sign-in service. An application received a ticket, validated it with that service, and established its own session.

The central session could spare a person another password prompt. The application session still belonged to the application. That distinction explains why single sign-on and signing out everywhere have always been different problems.

Next, an application needed to trust accounts managed by another organization. The participants needed an agreed format for the sign-in result and rules for exchanging and validating it.

SAML standardized assertions and the exchanges around them, with SAML 2.0 arriving in 2005. Shibboleth, software that universities built to share sign-in with each other, and the work of the Liberty Alliance, an industry group, helped shape federated access across organizational boundaries. WS-Federation, a federation standard led by Microsoft and IBM, developed in the related web-services ecosystem.

Before two organizations could federate, they had to exchange metadata: documents in which each side published its identifier, the addresses that receive its messages, and the certificate for checking its signatures. Each side configured its trust from the other's metadata.

Early OpenID pursued another approach to using an identity across websites. It is part of this history, but OpenID 2.0 and OpenID Connect are different protocols. A similar name does not make their messages interchangeable.

Applications also began asking to act on a person's behalf. A photo printer needed photos; a calendar tool needed events. Sharing the user's password gave those applications too much access and made it hard to withdraw one connection.

OAuth addressed delegated access. OAuth 2.0 was published in 2012, and OpenID Connect followed in 2014 with a standardized authentication layer on top. Applications could request access tokens for APIs and, when using OpenID Connect, receive an ID token for the sign-in result.

This is why a modern sign-in can contain both kinds of token without giving them the same purpose. One supports an API request; the other reports authentication to the client.

Sharing the user's password gave those applications too much access and made it hard to withdraw one connection.

OAuth×

OAuth 2.0

Published

2012

Addressed

Delegated access

Token

Access token

Purpose

Supports an API request

OpenID Connect×

OpenID Connect

Published

2014

Addressed

A standardized authentication layer on top

Token

ID token

Purpose

Reports authentication to the client

Centralizing sign-in makes authentication especially consequential. A stolen password at a central provider can affect several connected applications, so services added stronger methods and additional factors.

WebAuthn brought public-key authentication into the web platform. Passkeys made this approach more familiar to users: an authenticator proves possession of a private key, and the credential is bound to the relying party rather than typed into any page that asks for it. Here the relying party is the website the passkey was created for, which is why a look-alike site can't use it.

A stronger authentication method changes the evidence used at sign-in. It does not remove the need to validate federation messages, enforce permissions, manage sessions, or provide careful account recovery.

Password×

Password at the identity provider

Evidence at sign-in

A password typed into a page

Look-alike site

Receives what is typed into it

Results to apps

SAML or OpenID Connect results

Passkey×

Passkey at the identity provider

Evidence at sign-in

An authenticator proves possession of a private key

Look-alike site

Can't use it: bound to the relying party

Results to apps

SAML or OpenID Connect results

A stronger method does not remove the need to validate federation messages, enforce permissions, manage sessions, or provide careful account recovery.

These approaches coexist. An organization may use Kerberos for parts of its internal network, SAML for one application, OpenID Connect for another, and passkeys at its identity provider. Choosing one does not erase every other system it needs to work with.

Read a sign-in by following its boundaries: where did the person authenticate, what evidence reached the application, what did the recipient check, and which session or permission now lets the next request succeed?

Those questions let you read an unfamiliar system without starting from its product name. First find the account and the evidence, then follow how the next participant decides to trust them.