Magic Link

How it works

The user types their email, the server generates a single-use, time-limited token (usually a signed JWT or a random string stored server-side with a 10 to 15 minute expiry), and emails a link containing it. Clicking the link hits an endpoint that redeems the token for a session, no password ever exists. There's nothing exotic under the hood, it's the same token-exchange pattern as a password-reset email, just used as the primary login path instead of a fallback.

When it matters

Magic links cut signup and login friction for consumer apps where email is already the trusted identifier and users log in infrequently enough that "check your inbox" beats "remember a password." They matter less, and often actively hurt, in B2B contexts: enterprise buyers expect centralized login through their own identity provider so IT can deprovision an employee in one place, not chase down access to a marketing tool's inbox-based login. See Add SSO to Your B2B SaaS and Why Passwords Fail for the two ends of that tradeoff.

Common misconceptions

• "Magic links are inherently more secure than passwords." They remove password reuse and credential-stuffing risk, but they make the user's email inbox the entire authentication boundary. Compromise the inbox, compromise every account tied to it.
• "A magic link counts as multi-factor authentication." It's one factor, possession of the email account. Pair it with MFA if the account needs real protection, don't market it as MFA on its own.
• "Magic links can substitute for SSO in B2B deals." Enterprise buyers want SAML or OIDC through their IdP so admins control access centrally; a per-user email link bypasses that control and will stall procurement.