The Generations of Authentication: A Timeline

An engineer I worked with spent a morning drawing the full authentication path for one internal request: an employee opening a dashboard that pulls from three services, one of them now driven by an agent that summarises the result.

The drawing ended up with seven distinct authentication events, and she noticed something while labelling them. The laptop had a Kerberos ticket from unlock, out of a protocol whose design is roughly forty years old. The browser presented a session cookie, a mechanism invented in 1994 for shopping carts. The dashboard bounced her to the identity provider over SAML, a 2005 specification, which authenticated her with a passkey — 2019 at the earliest, 2022 in the form she actually used. Behind it, one service held an OAuth 2.0 bearer token and another still held an API key, which is the 1990s wearing a hoodie. The agent held a token acquired by RFC 8693 exchange, in service of a spec that did not exist five years ago. And her recovery path, the one she'd use if the laptop died, ended at an SMS code — a shared secret sent over a network we've known to be untrustworthy since before most of the stack was written.

Seven generations, six decades of design, all live in one request, all load-bearing.

That is the normal condition, and almost none of it is a mistake anyone made. It's the sediment of a field that has changed its mind about the threat model roughly every fifteen years and has never once succeeded in removing what it replaced.

This piece is about that succession, and what you can predict from its shape. The organising claim is narrower than "authentication got better":

Each generation of authentication was a response to a change in the topology of trust — who the parties are, where the boundaries sit, and what an attacker is now assumed to control. Each solved its predecessor's central problem completely. And each introduced a new failure class that took roughly a decade to become visible, because the new failure was invisible from inside the threat model that motivated the change.

That last clause is the interesting one. The failures weren't overlooked out of carelessness; they were structurally unobservable, because each generation is designed against the previous generation's attacker while the attacker that will matter is the one created by the new topology.

On scope: this isn't a history of password policy — composition rules, rotation, and the arms race between defenders' rules and crackers are covered in The Password Policy Arms Race. This is about mechanisms and their trust models. I'm hedging dates throughout; where only the decade is defensible, the decade is the claim.

Generation 1: the shared secret on a trusted host

The world that forced it. Time-sharing. When a computer ran one program at a time in a room you had to physically enter, the access control was the door. Once MIT's CTSS and its contemporaries let multiple users share one machine in the early 1960s, the machine needed a way to tell them apart — mostly for accounting and for keeping people out of each other's files. The password prompt is generally traced to that moment.

What it assumed. Nearly everything. The trust boundary was the machine room — hardware, operating system, operators, storage, terminal cable, all inside it. The only untrusted entity was a user who wasn't supposed to be this user. No network, no third party, no adversary holding a copy of your storage.

What it solved. Distinguishing one authorised human from another, cheaply, with no hardware — and it has never been beaten on cost. A password requires zero enrolment infrastructure, works on any input device, survives every transport, and costs nothing to issue.

The new failure class. The password file. Store the verifier next to the resource and you have created an asset worth more than any individual account — and "storage is inside the trust boundary" is the assumption that fails first. There's a well-told CTSS incident from the mid-1960s in which an editor's use of a fixed temporary filename caused the password file to be shown to everyone who logged in; retellings differ on details, but it's about as early a lesson as the field has.

The engineering response — hashing, salting, work factors — arrived in Morris and Thompson's 1979 paper and is still what we run; the arms race article does that derivation. What matters here is the structural point: generation 1 answered its failure class by hardening the artifact rather than removing it, and every subsequent generation up to number six is, underneath, still a shared secret in a new wrapper.

Generation 2: the network is hostile

The world that forced it. By the early 1980s the interesting resources weren't on the machine you sat at. Your file server, print server and mail spool were elsewhere, and the naive extension of generation 1 was to send your password to each of them. Two things made that untenable at once: the wire was passively observable — on shared media like early Ethernet, by anyone with a NIC in promiscuous mode — and the number of hosts holding your password had gone from one to dozens.

What it assumed. The sharpest assumption in the whole history, worth stating in its own words: the network is entirely under the attacker's control, but the endpoints and one trusted third party are not. Kerberos, which came out of MIT's Project Athena in the mid-1980s (v4 in the late 80s, v5 standardised in 1993 and revised in 2005), is the first widely deployed system designed on that premise. It built on the Needham–Schroeder symmetric-key protocol of 1978, with the timestamp fix Denning and Sacco proposed in 1981 after showing the original was replayable — one of the earliest cases of a protocol broken and patched in the literature rather than in the field.

What it solved. Your password stops travelling. It never leaves the client; it derives a key that decrypts a ticket-granting ticket, and thereafter the client presents tickets — time-limited, encrypted for one named service — to prove identity. A passive observer learns nothing reusable; a compromised print server learns nothing that helps it impersonate you to the file server. That second property, service scoping, took the rest of the industry twenty-five years to rediscover under the name audience restriction.

The new failure class. Two, both consequences of the topology rather than the cryptography.

First, the trusted third party is now a single point of total compromise. The KDC holds keys for every principal in the realm: generation 1 had a password file per host, and generation 2 consolidated them into one file that unlocks the organisation. The modern name for cashing that in is the "golden ticket": with the key material behind the ticket-granting service, an attacker mints cryptographically perfect tickets for any user, any service, any group membership, and nothing downstream can tell. This is the first appearance of a pattern we'll see three more times — the new architecture simplifies the resource server's job by having it trust an assertion, and the value of compromising the asserter rises accordingly.

Second, tickets are bearer artifacts. Absent extra binding, a ticket presented from the wrong machine is still a valid ticket. The generation designed on the premise that the network is hostile still produced an artifact whose possession is sufficient. Hold that thought.

Kerberos also gives the pattern its first adoption data point: largely a university technology through the 1990s, default for the largest enterprise directory only with Windows 2000, and still running under tens of millions of desktops today.

Generation 3: the web quietly reinvents bearer tokens

The world that forced it. HTTP was stateless by design, which was fine while it served documents and stopped being fine the moment a page needed to remember who you were between requests. The mechanism that solved it — the cookie, introduced at Netscape in 1994, standardised in 1997 and again more carefully in 2011 — was designed for shopping carts, not authentication.

What it assumed. That the browser is a faithful agent of the user, that a value the server sets comes back only from that user, and that the origin is a meaningful security boundary. The trust boundary is the browser session — one nobody designed deliberately.

What it solved. Statelessness, universally, and with no infrastructure at all: no directory, no KDC, no realm, no clock synchronisation, nothing but a header. That's why it beat everything else, and why every subsequent generation ends up expressed in its terms.

The new failure class. Nobody sat down and decided that web authentication would be based on bearer tokens. It happened because the only available state mechanism was a bearer token, and authentication got built on top of it by default. The consequences arrived over the following decade, each with its own name:

• Session hijacking — a stolen cookie is indistinguishable from the legitimate one, because indistinguishability is what a bearer artifact means. The server cannot ask "is the presenter the party I issued this to?"
• CSRF, named around 2001 — the browser attaches your cookie to requests your page didn't make. The convenience feature, ambient credentials, is precisely the vulnerability.
• XSS as credential theft — the same-origin policy protects the cookie from other origins and does nothing about script running as your origin. HttpOnly (2002) patched the artifact, not the model.
• Session fixation, described around 2002 — fix the identifier before login and authentication upgrades the attacker's session.

Every mitigation is an attribute flag bolted on over twenty-five years: Secure, HttpOnly, SameSite (proposed mid-2010s, defaulted to Lax by Chrome in 2020 — twenty-six years after cookies shipped), prefixes, partitioning. A remarkable amount of retrofitting for a mechanism whose original job was remembering a shopping cart.

The lesson is the one engineers most consistently underrate: the cheapest available mechanism becomes the security architecture, whether or not it was designed to be one. Nobody chose bearer semantics for the web. They were the path of least resistance, and the path of least resistance is a design process.

Generation 4: from authenticating users to accepting assertions about them

The world that forced it. By the late 1990s an employee needed accounts on dozens of systems, a growing number run by other companies. The generation-3 answer — a password per site — produced reuse, help-desk cost, and no central revocation. The generation-2 answer didn't cross organisational boundaries; Kerberos realms assume shared administration, and cross-realm trust never scaled socially.

What it assumed. That your organisation can enter a contract with another about identity, express it as a cryptographic trust relationship, and treat the assertion arriving over that relationship as a faithful account of an authentication event that happened somewhere you cannot see.

SAML 1.0 landed in 2002 and 2.0 in 2005; the consumer-web lineage ran OpenID through the mid-2000s, OAuth 1.0 in 2007, OAuth 2.0 in 2012, and OpenID Connect in 2014. The distinctions between them matter — see SAML vs OAuth vs OIDC and OAuth, Demystified — but what they share is the move that defines the generation.

What it solved. Applications got out of the credential business. One that accepts assertions stores no passwords, implements no MFA, runs no reset flow, and cannot leak what it doesn't hold. Across five hundred applications, credential-handling code went from five hundred implementations to one — the most underrated security win of the 2000s, and it happened for cost reasons rather than security ones.

The new failure class. The trust boundary left your codebase. Your application's security now depends on a document produced by another organisation, and on your ability to check it properly. This created an entire category of bug that has no analogue in earlier generations: the assertion was cryptographically valid and still wrong.

Every entry in the catalogue is a place where "verify the signature" was necessary and insufficient:

• Signature verified, but over a different element than the one you read — XML signature wrapping, which a 2012 study found affected a startling proportion of shipping SAML implementations.
• Signature verified against a trusted key rather than the one you meant for this issuer; or valid for a different audience because nobody checked aud; or valid but replayed, because your replay cache is per-node and you run three nodes.
• Valid, but the sub you keyed the local account on was an email address the directory later reassigned to a different human.
• Everything valid, because an attacker holding the identity provider's signing key mints whatever they like — "golden SAML," described publicly in 2017 and used at scale in the 2020 supply-chain intrusion that made it famous.

Note the structural repeat: generation 4's top-level failure is generation 2's. Compromise the asserter, own everything downstream, and every relying party's verification passes. Parties went from two to three; value concentrated in the middle one.

There's a subtler one too. Federation moved authentication further in time and distance from the resource being protected: the identity provider knows the user authenticated at 09:02 with a strong factor, and the API called at 14:30 knows only that a token exists. Everything in between — laptop stolen, account disabled, risk score changed — is information the resource server cannot get. Every later argument about token lifetimes, introspection and continuous evaluation is downstream of that gap.

Generation 5: raising the cost without changing the kind

The world that forced it. Leaked corpora made credential stuffing an industrial process — reuse meant a breach anywhere was a breach everywhere — and phishing became a business rather than a prank. The password's failure was no longer primarily cryptographic. It was that users typed the same one everywhere, and could be persuaded to type it into the wrong place.

What it assumed. That the attacker has your password but not your phone. The trust topology adds a channel or a device the attacker is presumed not to control, and the whole generation rests on that presumption of independence.

The mechanisms vary wildly in quality: hardware token displays from the late 1980s, HOTP standardised in 2005 and TOTP in 2011, SMS codes, and push approval, which arrived in the early 2010s and became the enterprise default because it required no enrolment ceremony beyond installing an app.

What it solved. A great deal. Large providers have reported very large reductions in bulk account takeover after adding a second factor, and those figures, though vendor-published, are directionally consistent. Against automated attacks, stuffing and untargeted phishing, generation 5 worked.

The new failure class — and the structural point most authentication timelines miss. Generation 5 did not change the kind of credential. It changed the quantity. A TOTP code is a shared secret — the seed lives on your phone and on the server, which is why a seed-database compromise is catastrophic in exactly the way a password database is, as a well-known 2011 incident at a token vendor showed. An SMS code is a shared secret sent over a channel with no authentication of the recipient and an operator-controlled routing table, which is why SIM swapping works. A push approval is a shared secret compressed to one bit, and that bit can be extracted by asking repeatedly at 2am.

All of them are phishable, because all of them are things the user can be induced to relay. The real-time phishing proxy — tooling of this kind became widely available around 2018–2019 — sits between the user and the real site, forwards the password, forwards the prompt, forwards the code, and captures the resulting session cookie. Notice where it ends: the attacker's prize is a generation-3 artifact. Every factor was verified correctly, and the outcome is a bearer cookie in the wrong hands.

The honest verdict: generation 5 raised the cost of attack by an order of magnitude and did not change its class at all. It bought roughly a decade, which is a respectable thing for a control to do, and is still buying it for most accounts in the world. But an attacker willing to run a proxy defeats it as completely as they defeated generation 1. Why SMS OTP Won't Die covers why the weakest member of this generation is nevertheless the correct choice in more situations than security people like to admit.

Generation 6: the credential stops being a secret

The world that forced it. Real-time proxies made it clear that no amount of additional shared secrets fixes phishing, because phishing attacks the human's ability to identify who they're talking to, and humans cannot do that reliably. Fixing it required moving identification of the relying party out of human judgement and into the protocol.

What it assumed. That the client platform can enforce an origin binding the user cannot override, and that a private key can live in hardware the user doesn't have to trust themselves to protect. The trust boundary moved into the authenticator and the platform.

The lineage: the FIDO Alliance formed in 2013, U2F keys arrived around 2014, WebAuthn reached W3C Recommendation in March 2019, and passkeys — synced, discoverable credentials with recovery handled by a platform vendor — were announced in 2022. The Magic Behind Passkeys covers the mechanics.

What it solved. The first genuinely categorical change in the sequence rather than an incremental one, and it's worth naming why. The credential is:

• Not a shared secret. The verifier holds a public key; a breach of the credential store yields nothing an attacker can authenticate with. The asset class that generations 1 through 5 spent forty years hardening simply isn't there.
• Origin-bound. The signature covers the origin as the browser computed it, not as the user perceived it. A proxy on a lookalike domain gets a signature for the lookalike domain, which the real site rejects; human judgement about the URL is out of the security argument.
• Non-replayable. Each assertion signs a fresh server challenge, so there is no artifact to capture and reuse.

Three independent properties, each killing a class of attack the previous five generations could only make more expensive — defensibly the largest single improvement in the field's history.

The new failure class. Recovery, portability, and the platform as a new trusted party.

Generation 6 bound the credential to hardware, so loss of hardware is loss of the account. Every prior generation had an implicit recovery story: you knew the secret, so anyone who could establish you were you could issue a new one. A keypair in a secure element has none. The answers on offer are multiple registered authenticators (correct; users don't do it), platform sync (which makes a consumer platform account the root of trust, moving the boundary again), or a fallback channel — meaning generation 5 or 1, capping the account at whatever the fallback provides. Passkey Account Recovery Is the Whole Problem makes that argument in full; the point for this timeline is that generation 6's new failure class is the mandatory presence of an older generation behind it.

A second, quieter one: origin binding is a real security property and also a real coupling — a domain change or merger becomes an authentication migration — and synced passkeys make cross-ecosystem portability a business decision belonging to companies that are not you. Why Passkeys Won't Eliminate Passwords Any Time Soon covers the deployment reality.

Generation 7: the authenticating party isn't a person

The world that forced it. Two curves crossed. Machine identities came to outnumber human ones — typically ten to fifty times over, as I argued in Non-Human Identity Is Now the Majority — and then software agents started acting on a user's behalf continuously, at machine speed, in sessions outliving any plausible notion of the user being present.

What it assumes. That identity is a chain rather than a subject: not "who is this?" but "on whose authority, through which intermediaries, is this action taken, and is every link still valid?" RFC 8693 token exchange, standardised in 2020, is the closest thing we have to a primitive for it: the subject stays the original user while actors accumulate in an act chain, so a downstream service can see both the principal and the delegation path.

What it might solve. Delegation that is visible and constrainable. The common pattern today is an agent holding a long-lived credential with the union of every permission it might ever need, and no downstream service able to distinguish "the user did this" from "software did this while the user was asleep." Making the chain explicit is a precondition for anything better — it's why ClavionX models an agent as a first-class object with its own policy and keeps delegation as plain token exchange rather than a special-cased path. A delegation chain nobody can inspect is not delegation; it's impersonation.

The new failure class, as far as anyone can see it yet. The confused deputy at industrial scale — an agent with legitimate authority induced by untrusted input to exercise it for an attacker; that one is written up separately. But the authentication-specific question is the one this timeline makes visible. Every generation from 1 to 6 was built to answer "is the human here, now?" Generation 7 has no coherent answer, because for an agent the honest answer is "the human was here three hours ago, and consented to something whose scope they estimated rather than enumerated."

If the pattern holds, the failure class we'll be naming around 2033 is consent validly obtained and materially exceeded: the delegation was real, the chain verified, the scope was granted, and the action was nothing the user would have authorised had they been asked specifically. Which is structurally generation 4's "valid and still wrong," one level up.

The whole sequence, compressed

Five things that never changed

Reading down that table, the invariants are more useful than the sequence.

1. Recovery is always the weakest link, and never gets a generation of its own. Every generation spent its design effort on the authentication path and treated recovery as an operational detail, so recovery reverts to an earlier era's mechanism: passkeys to OTP, OTP to email, email to a password, and a password to a human on a phone asking knowledge-based questions we've known for a decade are easier for attackers than for owners. The security of an account is the security of its weakest reachable path, and that path is almost always recovery — which is why recovery is the hardest problem in identity.

2. Every generation's convenience feature becomes the next generation's attack surface — not an incidental one, the central one. Cookies existed so you wouldn't retype your password; ambient cookie attachment is CSRF. SSO existed so you wouldn't log in twice; the assertion pipeline is where golden SAML lives. Push existed so you wouldn't type a code; one-tap approval is MFA fatigue. Passkey sync exists so you needn't re-enrol every device, and it makes a consumer platform account the root of your enterprise's trust. Convenience means removing a decision from the user, and that removes the point at which an anomaly could have been noticed.

3. The trust boundary moves outward, and the party count only grows. One machine, then a realm with a KDC, then a browser and a server, then two organisations, then a device vendor, a platform sync service, agent frameworks and model providers. Not once in sixty years has a generation reduced the number of parties, and each one added is a party whose compromise is now yours.

4. Bearer artifacts keep coming back, because they are cheap. This is the invariant that surprises people most, so let me put it sharply: generation 6 does not eliminate bearer tokens, it moves them one step later. A passkey login is unphishable and non-replayable and ends by setting a session cookie — a bearer artifact with exactly the properties of 1994. An attacker who steals it — malware, an XSS in one page, an over-scoped extension — gets everything the passkey was protecting, and your logs show a perfect phishing-resistant authentication event. Token binding, DPoP and mTLS-bound tokens exist precisely to close this and are deployed almost nowhere, because binding is expensive and bearer is free. The history reads as repeated discovery that possession-is-sufficient artifacts are dangerous, followed by repeated decisions to use them anyway.

5. Transitions take fifteen to twenty years, and nothing ever fully dies. Kerberos: mid-80s design, 2000 mainstream, still running. Cookies: 1994 to a safe cross-site default in 2020. Federation: 2002 spec to default enterprise posture in the late 2010s. Second factors: 2005 standard, mass adoption from about 2018. If passkeys follow the curve, "most consumer logins" is a mid-2030s milestone and "no passwords anywhere" is not on the curve at all. LDAP simple binds still work; NTLM is still enabled somewhere in your estate. There is a password in your system right now, and something will still accept it in 2040.

The payload: you are running five generations at once, and the attacker picks

The fifth invariant isn't a closing flourish; it's the most operationally important fact here. In its strongest form: your effective authentication security is not the strongest generation you have deployed. It is the weakest generation reachable for a given account, and the attacker chooses which one to use.

Obvious stated abstractly, routinely violated in practice, because organisations measure the wrong number. The dashboard says "passkey enrolment: 78%," which on its own tells you almost nothing. The number that matters is: for a user who has enrolled a passkey, what else still works? If the password still validates at the same endpoint, you haven't deployed generation 6 for that user — you've offered it as one option among several, and the attacker will pick another. Enrolment without disablement is a usability improvement, not a security control.

So the useful exercise isn't counting enrolments; it's drawing the map. For a representative account, enumerate every path that ends in an authenticated session and label each with its generation:

Nine rows is typical for an enterprise. Two are the ones you discuss in reviews. The security of the account is the minimum over all nine.

Four consequences follow, and they're where this timeline earns its keep.

Deprecation is the work; deployment is the easy half. Rolling out a new generation is a project with a sponsor, a budget and a launch. Removing the old one is a long tail of legacy clients, integration partners, one call centre and a device fleet nobody can inventory — no launch, no sponsor, and a real chance of breaking someone important. That's why every generation persists: the last 3% of its usage attaches to the most politically expensive 3% of the estate. Budget most of a passkey rollout for after the enrolment curve flattens, and write down in advance the criteria on which the password path gets disabled per user. A deprecation without a trigger condition will not happen.

Downgrade paths should be enumerated deliberately, not discovered. Attackers don't attack your strongest factor; they look for the endpoint that predates it — the legacy mail protocol, the "app password," the API that binds against the directory directly, the recovery flow. Ask of every rollout: what does an attacker do if they decline to use it? If the answer is "the old thing still works," you've added a factor for honest users only.

Your logs speak several dialects. A generation-2 ticket request, a generation-4 assertion, a generation-5 push approval and a generation-7 token exchange are four event shapes with four notions of subject, and correlating one user across them is work most teams discover mid-incident. The design-time question is whether "which generation authenticated this session?" is a queryable field. Surprisingly few systems can answer it, and it's the first thing you want at 3am.

Assurance level must be carried, not assumed. If several generations can mint a session, the session must record which one did, and downstream decisions must be able to read it. That's what AMR and ACR claims are for, and why they're worth populating honestly rather than as a constant. A payment endpoint requiring phishing-resistant authentication cannot enforce it if the token doesn't say how the user authenticated — and defaulting to "assume the good one" is exactly backwards, because the sessions to be suspicious of are the ones that came in through the old door.

What the pattern predicts

Seven data points is suggestive, not a law. Three predictions look reasonable anyway.

Passwords won't be removed; they'll be demoted to a recovery mechanism and stay there for decades. The generation-1 credential has already been demoted twice — primary, then one of two factors, then fallback — and never once deleted from a large estate. Plan for a password path you operate but do not advertise, and hold it to the primary path's standard, because it's the one that will be attacked.

The next visible failure class will be about delegation and consent, not credentials. Generation 6 largely closes the credential as an attack surface for accounts that fully adopt it, and attackers relocate. The remaining soft targets are the session artifact after authentication (invariant 4) and the authority granted to software acting for a user (generation 7) — so expect the notable incidents of the next several years to be, roughly in order: stolen post-authentication sessions, over-scoped agent credentials, and consent flows that were technically valid.

And whatever generation 8 is, its recovery flow will run on generation 6 or 7, and someone will attack it there. That has been true of every generation so far, which is either a strong induction or an admission that the field's blind spot sits exactly one step behind wherever it is looking.

The reason to hold the whole sequence in your head isn't nostalgia. It's that "what is my authentication posture?" has no single answer — it has one per generation you're still running, and the honest number is the smallest. Most organisations have never written that list down. It takes an afternoon, and it's usually the most alarming document anyone produces that quarter.