Building email magic-link auth by hand — codes, tokens, rotation, cookie handling — taught me more about my own threat model than any auth vendor's documentation ever did.
I could have reached for an auth vendor and had passwordless login working in an afternoon. I built it by hand instead — a one-time code sent by email, exchanged for a signed token, set as an HTTP-only cookie — and it took considerably longer than an afternoon, and I don't regret a single hour of it, because every hour taught me something about my own threat model that a vendor's documentation would have quietly handled for me and never explained.
The first thing you're forced to think about, building this yourself, is what the code actually protects against and for how long. A six-digit code is guessable by brute force if there's no rate limit on the verification endpoint, so the rate limit isn't an optional hardening pass, it's load-bearing from the first version. And the code has to expire — not eventually, but on a window short enough that a code sitting in an inbox for a day isn't still a live credential a week later. Neither of those is a hard problem. Both are the kind of problem a vendor solves invisibly, which means you never have to think about it, which also means you never learn why it mattered.
The second thing is what happens after the code is verified — what you actually hand back to the browser, and what that thing is allowed to do. I ended up issuing a short-lived signed token, verified server-side, rather than trusting anything the client could tamper with, and storing it in a cookie marked HTTP-only and Secure so that no client-side script could read it even if something else on the page were compromised. None of this is exotic. It's the standard shape auth vendors implement for you by default. Building it myself meant every one of those defaults was a decision I had to make on purpose, and articulate a reason for, rather than inherit.
Rotation was the part I underestimated hardest. A token that's valid forever is a liability that grows the longer the system runs, because every issued token is a standing credential somewhere, and "somewhere" eventually includes a device that was lost, a session that was never properly closed, a token that leaked into a log it shouldn't have touched. Building rotation in from the start — short-lived tokens, a refresh path, a way to invalidate everything issued to an account if it's ever compromised — is a different design problem than bolting rotation onto a token scheme that assumed it would live forever. Vendors tend to get this right, I assume, because a token that outlived its welcome is a failure mode they see far more often than any single product ever will. I got it right, eventually, because I read the failure mode and reasoned backward from it, which is a much slower way to arrive at the same place but leaves you actually understanding why the place is correct.
What surprised me most is how much of "auth is hard" turns out to be "auth has a lot of small decisions, each with a specific reason, that are invisible until you have to make them yourself." A vendor doesn't make auth simple by removing the decisions. It makes auth simple by making the decisions for you, well, and not telling you it did. That's a completely legitimate trade for most products, most of the time — I wouldn't insist everyone build this by hand. But I would say that if you never build it once, you carry a threat model made of assumptions you've never had to justify, and the first time one of them turns out to be wrong, you won't know which one it was.
I run the hand-built version now with confidence I don't think I'd have with a vendor's black box, not because it's more secure — it probably isn't, a mature vendor has fixed edge cases I haven't hit yet — but because I know exactly what it does and why, at every step from the email going out to the cookie coming back. That legibility is worth something on its own, separate from whatever the security delta actually is.