How Magic Links Work
Passwordless login via email
A magic link is a URL sent to the user’s email that logs them in when clicked. No password needed. The flow:
- User enters their email
- Server generates a token, sends a link:
https://yourapp.com/auth/verify?token=abc123 - User clicks the link in their email
- Server validates the token and creates a session
This is essentially the password reset flow from the Securing Your API course, but instead of changing a password, it creates a session directly.
Why it works
Email access is the proof of identity. If you can read the email, you control the account. This is the same assumption that password reset makes — and every app with password reset already trusts email as an identity factor.
Magic links make this implicit trust explicit: instead of going through password reset to regain access, the user skips the password entirely.
How it relates to password reset
The implementation is nearly identical:
| Feature | Password Reset | Magic Link |
|---|---|---|
| User submits | ||
| Server generates | Time-limited, single-use token | Time-limited, single-use token |
| Token is stored as | SHA-256 hash | SHA-256 hash |
| Link goes to | Reset password form | Session creation |
| Token is consumed | When password is changed | When session is created |
The only difference is what happens when the token is verified: password reset changes the password, magic link creates a session.
When magic links are appropriate
Good fit: Low-risk apps, content sites, collaboration tools, newsletters, internal tools. Any app where email access is a reasonable proxy for identity.
Poor fit: Banking, healthcare, government services, apps handling sensitive financial data. These need stronger guarantees than email access provides. Email accounts can be compromised, emails can be forwarded, and email is transmitted in cleartext between mail servers.
Hybrid approach: Use magic links as a convenient option alongside passwords. Users who want stronger security can use passwords + 2FA. Users who want convenience can use magic links.
Exercises
Exercise 1: Think about apps you use that offer magic link login. Slack is a common example. What is the UX like?
Exercise 2: If you already built password reset in the Securing Your API course, compare the code. How much of the token generation, hashing, and verification logic could be shared?
What is the security assumption behind magic link login?