History of SSO
Imagine starting your workday by signing in to your computer, opening your email, and checking an internal application. You may move between all three without entering your password again. The experience feels simple, but it depends on systems agreeing about who signed in, what evidence they will accept, and how long that evidence remains useful.
That agreement did not arrive all at once. As computing moved from shared machines to networks and then to independent services on the internet, authentication had to solve a larger problem at each step. The history of single sign-on is the story of those changing boundaries.
The 1980s: taking a sign-in across a network
Now imagine that your files, email, and printer are managed by different computers. Signing in to your workstation does not automatically give each of those services evidence it can trust. Asking for your password everywhere creates more interruptions and more places where that password could be exposed.
Kerberos, developed through MIT's Project Athena during the 1980s, became an important early approach to this network authentication problem. It used a trusted authentication service and cryptographically protected tickets. After an initial authentication, a client could obtain tickets for individual services without asking the user to type a password into each one.
For example, you could sign in at a campus workstation and then access a network file service. The file service checked evidence issued through Kerberos instead of collecting your password itself. Its access rules still determined which files you could open.
The Kerberos design was described in a 1988 paper, and Kerberos version 5 was specified in RFC 1510 in 1993. These are milestones in a longer development process, not a claim that one publication invented every form of SSO. Later articles will unpack tickets, the key distribution center, and the checks that make the exchange work.
The 1990s and early 2000s: signing in to an organization
As organizations connected more workstations and services, a centrally managed work account became increasingly useful. Employees could use one organizational identity, while administrators had a common place to manage those accounts.
In Windows networks, authentication mechanisms including NTLM supported integrated access to services. Windows 2000 brought Kerberos version 5 into the domain authentication model as the default protocol. Applications that participated in that environment could use the work sign-in to authenticate users without another password prompt.
A shared directory and SSO solve related but different problems. A directory can give several applications the same account information while those applications still prompt separately. SSO also requires a way to carry or establish trusted authentication between those interactions.
The early 2000s: bringing SSO to websites
The browser introduced another boundary. Signing in to one website did not automatically create a session at another, and independent applications needed a deliberate way to use a central sign-in service.
Yale's Central Authentication Service, or CAS, was one early web SSO implementation. An application could redirect the browser to a central authentication service, receive a service ticket, and validate that ticket with the service. The application then established its own session.
For a student, this could mean signing in to a university service once and then opening another participating campus application without another password prompt. The applications did not need to share one browser cookie. They used the central service to establish who had authenticated.
The 2000s: federation across organizational boundaries
Web applications also needed to accept identities managed somewhere else. A university might want students to access a publisher's research library using their university accounts. The publisher needed a trustworthy authentication message, even though it did not manage those accounts or passwords.
The Security Assertion Markup Language, or SAML, standardized ways to exchange identity-related assertions. SAML 1.0 became an OASIS Standard in 2002. SAML 2.0 followed in 2005, incorporating work from earlier SAML versions, Liberty Alliance, and Shibboleth.
WS-Federation developed another approach to federation using the web services security family. Version 1.2 became an OASIS Standard in 2009. Its browser sign-in mechanisms also allowed an application to accept identity information through an established trust relationship.
These approaches let an application rely on another organization's authentication. They did not require every application to use the same session or make the same access decisions. Later protocol articles will compare the messages and trust configuration behind those relationships.
The late 2000s and 2010s: identity and access on the wider web
The original OpenID protocols explored letting people use an identity provider across participating websites. OpenID Authentication 2.0 was finalized in 2007. It belongs to the history of federated web sign-in, but it is a different protocol from OpenID Connect.
Meanwhile, applications needed a way to access another service on a user's behalf. A photo printing application, for example, needed permission to retrieve photos without collecting the person's photo account password. OAuth addressed that delegated access problem. OAuth 2.0 was published as RFC 6749 in 2012.
OAuth's role here matters: access to an API and authentication to an application are different requirements. OAuth alone does not define the standard sign-in result an application needs to identify its user.
OpenID Connect, finalized in 2014, added an authentication layer on top of OAuth 2.0. It defined an ID token and rules for how a client obtains and validates information about an authentication. An application could establish its own session using that result, while access tokens served the separate purpose of accessing APIs.
The 2010s and 2020s: strengthening the sign-in itself
Sharing a sign-in makes the authentication service especially important. If an attacker gains control of that account or its sessions, several connected applications may be affected. MFA, stronger authenticators, and policies that consider the circumstances of a sign-in help address that risk.
Web Authentication, or WebAuthn, became a W3C Recommendation in 2019. In 2022, Apple, Google, and Microsoft announced expanded support for FIDO-based passwordless sign-in, including credentials commonly called passkeys. These developments made public-key authentication more accessible through familiar browsers and devices.
A passkey can change how you authenticate to an identity provider. The provider can then use SAML or OpenID Connect to sign you in to an application. Passwordless authentication and federation operate at different parts of that journey, so adopting one does not automatically replace the other.
Today: several generations working together
SSO has not developed as a clean sequence where every new protocol removes the one before it. An organization can use Kerberos for internal network services, SAML for a business application, and OpenID Connect for a newer web application. The relevant question is which trust relationship and environment each protocol supports.
The security guidance around these systems continues to change. In 2025, RFC 9700 consolidated updated OAuth 2.0 security practices based on deployment experience and known attacks. Understanding when a protocol was introduced is only part of understanding how it should be used now.
New questions also arise when software services and agents act on their own or on a person's behalf. Those interactions need identities and carefully limited authority, but they are not all human SSO. Later training will distinguish workload authentication and delegation from a person's interactive sign-in.
Across this history, one idea remains consistent: a successful authentication is useful elsewhere only when another system has a sound reason to trust it. The protocols define how that evidence is exchanged. Applications still need to decide what the authenticated account may do.