Magic-Link Login for Client Apps: Passwordless, Domain-Locked, Done in an Afternoon

Every password you hand a client is a small liability you now own. They forget it (support ticket). They reset it (another support ticket). They write it on a sticky note or reuse it from another site (your security hole). Multiply that across every client and every login, and password management quietly becomes a job you never agreed to do.

A magic link removes the whole category of problem. The client types their email, you email them a one-time sign-in link, they click it, and they're in — no password to create, remember, reset, or leak. There's nothing for them to manage, and crucially, nothing for you to store: no password hashes sitting in your database waiting to be breached. It's the same pattern you've already used a hundred times when a site emails you a 'click here to log in' link.

To complete a magic-link login, the person has to open the actual email in the client's inbox. That means access to the account is gated on possession of that inbox — which is, in practice, a second factor for free: you can't log in just by knowing or guessing a password, because there is no password.

Be precise about this, though: a magic link is effectively a possession factor (you control the inbox), not a literal TOTP/authenticator-app two-factor setup. It's stronger than a password alone because it removes password reuse, guessing and credential-stuffing as attack paths — but its security rests on the client's email account being secure. If you need true MFA on top, NextAuth supports adding it; the magic link itself is the passwordless base, not a replacement for a hardware key in high-risk contexts.

You don't need anything exotic. Three pieces, all of which you've probably already used:

For a client dashboard you usually want exactly one company's people to get in — and nobody else. Auth.js gives you a hook for this: the signIn callback. Return true to allow the sign-in, false to reject it. Restricting to a single domain is one line:

Authentication breaks the moment a secret leaks, so every key lives in environment variables — never in the committed code. Run this checklist before you ship:

Put together, the path from empty project to working domain-locked login is short:

Magic links are an excellent default for client dashboards, but they're not magic in the literal sense. Deliverability matters — if the email lands in spam, the client can't log in, so authenticate your sending domain properly. And the security model leans entirely on the client's email account being secure; for genuinely high-risk systems, layer real MFA on top rather than treating the inbox as the only gate. For the everyday client portal, though, this is the login that generates zero support tickets and gives you no password database to lose sleep over.