Identity Is Much More Than Login
A few months ago, I decided to redesign one of the most important services in my system from scratch: the Identity Service.
At first, I thought this would mostly be about authentication, JWT, OAuth, and access tokens.
I was wrong.
The deeper I went, the more I realized that building an identity system is much closer to modeling the real world than implementing APIs.
What most people mean by “identity”
Most developers associate identity with:
- Login
- Registration
- JWT
- OAuth
- Access tokens
Those are only the tip of the iceberg:
The questions that change the design
The hard part begins when you start asking:
| Question | Why it hurts a flat users table |
|---|---|
| Should User and Person be the same? | Accounts ≠ humans |
| Device session vs user session? | Theft and multi-device behavior diverge |
| How do refresh tokens rotate? | Replay attacks need token families |
| Encrypt PII at rest? | Names and contacts are sensitive assets |
| Organizations and employees? | People wear multiple roles |
| Multiple citizenships? | Nationality is a relationship, not a flag |
| Location as an entity? | Addresses and geo are not free-text forever |
Answering those forced me to rethink assumptions I had carried for years.
Modeling reality
Software architecture is often less about frameworks and more about modeling reality.
People have identities. They belong to organizations. They change devices. They migrate. They own multiple contact methods. They have histories.
And all of that eventually shows up in your schema.
Suddenly, designing an identity service becomes much more than implementing JWT authentication.
What this book explores next
User vs Person
Why a user account is not the same thing as a human being.
Contacts and citizenship
Channels as aggregates; nationality as a relationship — not a forever flag.
Dual sessions and token families
Device before account; rotation with reuse detection.
Auth, orgs, and the edge
OTP / password / OAuth converge; organizations and geo; Next.js cookie ordering.
Final thoughts
Building this service taught me something I wish I had understood earlier:
Architecture is not about technologies. Architecture is about understanding the domain you’re trying to model.
Frameworks change. Languages change. Databases change. The domain remains.
And if you model it well, everything else becomes much easier.
Next chapter
Continue with Why User and Person Are Different.
Canonical version. Also on Medium.