Authentication is one of those topics that feels familiar, yet regularly causes confusion — even among experienced developers.
OIDC, Passkeys, Magic Links…
We can implement them, copy examples, wire up SDKs.
But when someone asks “how exactly does this flow work?” or “how is this different from that?”, the explanation often collapses into hand-waving.
I kept running into the same problem:
authentication is usually taught through code, but the real difficulty lies before code — in understanding the sequence of trust decisions.
So I tried a different approach.
Instead of starting from implementation details, I built a small tool that treats authentication as:
- a sequence of steps
- actors interacting across trust boundaries
- decisions that change system state
No SDKs. No config files.
Just flows.
The goal isn’t to replace documentation or tutorials.
It’s to make the structure visible — so that comparisons become possible.
When you put different auth methods side by side, interesting things emerge:
- where user intent is confirmed
- where secrets actually live
- where control shifts from user to server
- where security assumptions differ
This is still an experiment.
There’s no login, no database, no personalization.
Right now, it’s closer to a thinking aid than a product.
But I’m curious whether this “concept-first” way of looking at authentication is useful to others — or if it’s just academic navel-gazing.
Here’s the experiment:
auth-flow-studio
Feedback, criticism, and alternative mental models are very welcome.
If nothing else, I hope it sparks better conversations about auth — before we all jump into code.
Top comments (0)