The State of Identity (Part I):
How Digital Identity Quietly Evolved from Web 2.0 to the Modern Internet
Identity was never supposed to be interesting.
In the early days of the web, it was plumbing — something you implemented once, tucked behind a login page, and rarely thought about again. You had users, they had passwords, and the database decided who could do what. Simple, local, and largely invisible.
But identity didn’t stay simple for long.
Not because engineers suddenly cared more about security, but because the web itself changed shape.
Every major shift in digital identity over the last two decades has been a reaction — not a revolution. A response to scale, distribution, and broken assumptions. If you trace identity’s evolution carefully, you’ll notice a pattern: identity breaks only after architecture breaks first.
Before SSO: When Identity Was Local—and Already Failing
In the early Web 2.0 era, identity lived inside the application.
Most systems were monoliths. Authentication meant checking a password hash. Authorization was a few if statements sprinkled across request handlers. Sessions were stateful, often stored in memory or a shared cache. Trust was implicit — if the request reached your server, it was probably legitimate.
This model worked because systems were small, ownership was centralized, and the browser was the primary interface.
But even before large platforms emerged, cracks were visible. By the mid-2000s, academic and industry research was already documenting widespread password reuse, insecure storage, and growing phishing attacks. Users were juggling dozens of accounts long before SSO existed as a mainstream concept.
The important point is this: identity was already failing before we had a better alternative.
The web had outgrown app-local identity, but the replacement hadn’t arrived yet.
The SSO Era: Identity Becomes Shared Infrastructure
As companies began operating multiple products under a single umbrella, identity stopped being a per-app concern.
This shift is easiest to see at companies like Google. Gmail, Search, YouTube, Docs, Calendar — each product evolved independently, but users expected continuity. Logging in repeatedly wasn’t just annoying; it broke the illusion of a cohesive platform.
Internally, the stakes were even higher. Maintaining separate authentication systems meant duplicated logic, inconsistent policies, and fragmented security controls. Centralizing identity wasn’t just about user experience — it was about operational sanity.
SSO emerged as a practical response. A single identity provider became the source of truth, issuing authentication assertions consumed by many services. Sessions could be shared. Account recovery could be centralized. Security posture could be enforced consistently.
Around the same time, consumer-facing federation appeared. Facebook Connect (later “Sign in with Facebook”) allowed users to carry their identity across the web. What looked like convenience was actually a profound architectural shift: identity moved outside the application boundary.
At this stage, identity became infrastructure.
But SSO still assumed browsers, cookies, and long-lived sessions. That assumption didn’t survive the next wave.
APIs Broke Sessions
The explosion of APIs, mobile apps, and single-page applications forced a reckoning.
Requests were no longer coming exclusively from browsers. They came from phones, background jobs, partner services, and third-party developers. Stateful sessions didn’t scale cleanly across regions and load-balanced fleets. Sticky routing became a liability. Central session stores became bottlenecks.
Large systems needed identity that could be verified without remembering anything.
That requirement — not elegance — is what pushed the industry toward tokens.
JWTs: Identity Becomes Portable
JSON Web Tokens didn’t gain adoption because they were beautiful. They won because they aligned with distributed systems reality.
A JWT allowed identity to travel with the request. Instead of asking a central service “who is this?”, a service could verify a cryptographic signature and make an authorization decision locally. No shared session state. No synchronous dependency. No tight coupling.
Inside large platforms, this unlocked massive horizontal scalability. Services could be deployed independently. Authorization logic could live closer to the business logic. Latency budgets improved.
But this shift also changed the nature of trust. Once issued, a token represented authority for its lifetime. Revocation became harder. Key management became critical. Security incidents became systemic instead of local.
Identity was no longer a feature — it was a contract encoded in cryptography.
OAuth: Delegation Without Passwords
As platforms matured, a different problem took center stage.
Users wanted third-party apps. Platforms wanted ecosystems. But handing out passwords to external developers was a security nightmare — and everyone knew it.
OAuth formalized a new idea: delegated authorization.
Instead of sharing credentials, users authenticated with a trusted provider and explicitly granted scoped access. Applications received tokens representing what they were allowed to do, not who the user was everywhere.
This model reshaped the internet. “Sign in with Google,” “Continue with Facebook,” and similar flows normalized the idea that identity and authorization could be separated — and that access could be limited, auditable, and revocable.
Developer platforms like GitHub showed how powerful this could be. Tools could request narrowly scoped access — read repositories, open issues, manage webhooks — without becoming custodians of user credentials.
OAuth didn’t just improve security. It changed how we reason about identity itself.
Identity became contextual.
Identity Today: The Shape of Trust
By the late 2010s, identity had fully escaped the application layer.
Modern systems treat identity as:
- A security boundary
- A policy engine
- A compliance surface
- A core piece of platform architecture
Zero-trust principles, short-lived credentials, explicit scopes, and continuous verification didn’t appear because they were fashionable. They appeared because everything else stopped working.
And that brings us to the present.
The same forces that reshaped identity before — scale, delegation, automation — are accelerating again. This time through AI agents, programmable wallets, and cryptographic ownership.
That story belongs in Part II.
References
Pre-SSO
- Password Management Strategies for Online Accounts
https://www.cs.princeton.edu/~felten/password.pdf - Microsoft Passport and the Identity Metasystem
https://learn.microsoft.com/en-us/previous-versions/ms995336(v=msdn.10) - Liberty Alliance Identity Federation Framework
https://www.oasis-open.org/committees/download.php/17908/liberty-idff-1.2.pdf
SSO / Federation
- Google Accounts Authentication – Getting Started
https://developers.google.com/accounts/docs/GettingStarted - Facebook Connect: Bringing Facebook to Your Site
https://developers.facebook.com/blog/post/2008/05/09/bringing-facebook-to-your-site-with-facebook-connect/
Tokens / Delegation
- Why OAuth? — Google Code Blog
https://developers.googleblog.com/2010/04/why-oauth.html - OAuth for the GitHub API
https://github.blog/2012-09-14-oauth-for-the-github-api/ - JSON Web Token (JWT) — RFC 7519
https://datatracker.ietf.org/doc/html/rfc7519