Authentication

I've shipped three very different authentication systems in production: OAuth2 with Spring MVC for a digital-currency platform, cross-domain session auth across an eSIM company's web properties, and passwordless auth (magic links plus Google sign-in) for nihongojouzu.jp. The designs share almost no code, because auth design starts from the threat model and the user, not from a library.

Cross-domain auth: the cookie reality

The eSIM platform's users move between company properties on different domains (store, account, marketing) and expect to stay signed in. Cookies don't cross registrable domains, so "just share the cookie" isn't an option. The workable pattern is a central session authority with short-lived handoff tokens:

The rules that make it safe are all about the handoff token: it's single-use, expires in seconds, is bound to the destination domain, and is exchanged server-side for a real session cookie. A token that lives in a URL will end up in someone's logs, browser history, and Slack. Design as if it's already leaked.

Magic links: fewer moving parts, different failure modes

For nihongojouzu.jp I went passwordless: Google sign-in for the one-tap path, magic links for everyone else. No stored passwords means no password database to breach, no reset flow, no credential-stuffing surface. But magic links move your risk into new places, each of which needs an explicit answer:

✓ Token: 128+ bits random, hashed at rest, single-use, 15-min expiry
✓ Email deliverability: auth is now only as reliable as your sender score
✓ Link scanners: corporate mail "clicks" links, so require a confirm tap,
  or consume the token via POST, never on GET
✓ Session lifetime: long sessions are the compensation for login friction

The link-scanner one bites everyone eventually. Enterprise email security opens every URL it sees, silently consuming single-use tokens before the human ever taps. If your magic-link login "randomly fails" for corporate users, that's why.

The rule that generalizes

Every auth system I've built reduces to the same discipline: name the token, write down its lifetime, decide who can redeem it, and log every redemption. OAuth2 access tokens, session cookies, magic-link tokens, cross-domain handoffs. They're all the same object wearing different clothes. The systems that get breached are usually the ones where somebody couldn't answer "what exactly does this token authorize, and until when?"