Magic link authentication sends a one-time login URL instead of a password. Learn how it works, where it fits, and how it compares to OTPs and passkeys.
How Apple broke "Sign in with Apple" with an unannounced and silent redirect
A magic link is a one-time login URL sent to a user’s email instead of a password. The user clicks it, the server checks that the link is valid and unused, and the click itself becomes the proof of identity. No password to type, no password to remember, no password to leak in the next breach dump.
That is the appeal in one sentence. The interesting part is where the trust actually lives. Magic links shift trust from a memorized password to control of an email account. That single shift removes whole categories of attack and introduces a few new failure modes you have to design around.
This article walks through how magic links work, where they fit, how they compare to one-time passwords and passkeys, and what it takes to ship them securely. For the broader set of login methods and where each belongs, our overview of login, password, passkey, WebAuthn, TOTP, SSO, and Face ID maps the entire landscape.
Magic link authentication is a passwordless method in which the user receives a unique, time-sensitive URL via email instead of entering a password. Clicking the link proves that the user controls that email address, and that proof serves as identity verification. The password disappears from the login flow entirely.
The link carries a cryptographically secure token generated for that one login attempt. When the user clicks, the server validates the token and immediately invalidates it, preventing it from being used again. Most implementations expire the link within 5 to 15 minutes.
What separates magic links from password login is where the trust anchor sits:
If you are weighing this against keeping passwords around, it helps to understand what attackers actually do with stolen credentials. The breakdown of common authentication attack vectors explains why removing the reusable secret matters so much.
The flow looks simple from the outside. The security lives in the details underneath. Here is what happens end-to-end.
The user types their email on the login screen. There is no password field, just an email input and a submit button. The application validates the format and decides how to handle unknown addresses. To prevent account enumeration, many systems accept the request silently, whether or not the address exists, and then send nothing if it does not. Others show an explicit error. The choice is a tradeoff between user clarity and leaking which emails are registered.
The server creates a high-entropy token with at least 128 bits of randomness and signs it. The token is embedded in a URL and stored server-side alongside the user’s email and an expiry timestamp. The email then goes out through your transactional email infrastructure. Delivery speed matters here: if the message is slow, users get frustrated or the token expires before they click. The same session and flow concerns show up in any self-service login flow, which is worth reading if you are building this yourself.
On click, the server checks three things: if the signature is valid, if the token has not expired, and if it has not already been used. Pass all three and the user is authenticated; then a session begins. The token is marked as consumed immediately. From the user’s side, the whole thing takes about thirty seconds. From a security standpoint, the window of exposure is exactly as long as the token stays valid, which is why short expiry windows do real work. How you issue and manage that session afterward is its own design problem, covered in Ory’s session management overview.
Magic links shine in some scenarios and fall flat in others. Knowing the difference keeps you from bolting them onto a flow that needs a passkey.
Consumer apps benefit from less friction at sign-up and sign-in. No new password to invent means fewer abandoned flows and better conversion. SaaS products, media sites, and mobile apps tend to do well with magic links because their users log in infrequently and value convenience over raw speed. If you are building one of these on a modern stack, the Next.js authentication walkthrough and the React Native login example show how passwordless flows wire into real frontends.
Plenty of apps already run a magic-link-style flow for “forgot password.” The same mechanism can replace the password outright or act as a fallback when another method fails. If you have ever clicked a reset link, you have used something almost identical to magic link authentication. The account recovery and password reset flow documents how Ory handles the recovery process.
Magic links can grant one-time or short-lived access to a document, dashboard, or order-tracking page without requiring the user to create an account. E-commerce and logistics apps lean on this constantly. The “track your package” link in a confirmation email is a magic link wearing a different hat.
External collaborators who occasionally access your system, such as partners, vendors, or customers checking invoices, usually do not want to manage another credential. Magic links cut onboarding friction for infrequent users while still leaving an audit trail of who accessed what and when. This pattern often sits within a broader customer identity and access management setup.
A user can request a link on a laptop and open it on a phone. Whether that is a feature or a hole depends on your threat model. Some implementations deliberately bind the token to the originating device or session so a link opened elsewhere does nothing useful.
The case for magic links comes down to three things: less friction for users, a better posture against common attacks, and lower operational load for your team.
No password to create or recall lowers the barrier to entry, and mobile keyboards pre-fill email addresses, so the flow gets even faster:
Magic links delete entire classes of password attacks. A single-use token cannot be guessed, reused, or stuffed from a breach database:
Password resets generate real help-desk volume. Magic links remove the “forgot password” loop because there is no password to forget. The user just requests a new link. For teams thinking about where this fits in a passwordless roadmap, auth and modern software frame the broader shift.
Magic links can stand alone or combine with passkeys, WebAuthn, or one-time passwords for step-up MFA. For teams moving toward passwordless but not ready to deploy passkeys everywhere, they are a sensible intermediate step. The deeper dive into WebAuthn and passkeys shows what the endgame looks like.
Magic links are not a silver bullet. Their security is bounded by factors outside your direct control, and being honest about the trade-offs helps you decide whether they fit your threat model.
Anyone with access to the user’s inbox can click the link. If an attacker already owns the email account through phishing, malware, or password reuse, they can authenticate as that user. Magic links are only as strong as the user’s email provider. For high-risk applications, pairing the link with a second factor closes the gap: the link proves email access, and a TOTP code or biometric proves something more.
Attackers can craft look-alike emails that point to malicious sites or intercept links sent over unencrypted channels. Branded, recognizable sender addresses and TLS-enforced delivery reduce exposure, but phishing remains a live concern for any email-based method. This is precisely where passkeys pull ahead, since they are cryptographically bound to the real domain.
Enterprise email security tools sometimes pre-click links to scan for malware. That click can consume the single-use token before the user ever opens the message, leaving them with a dead link and a confusing error. Two fixes are common: a confirmation step where the link loads a page with a “confirm login” button, or a very short reuse window (say, 60 seconds) before the token locks.
If the email lands in spam or arrives several minutes late, the token can expire before the user acts. Reliable transactional email and active deliverability monitoring are not optional. A “resend link” option handles delivery failures gracefully.
One-time passwords are the most common alternative passwordless method, so comparing the two clarifies when each makes sense.
| Aspect | Magic Link | One-Time Password (OTP) |
|---|---|---|
| Delivery channel | Email (sometimes SMS) | SMS, authenticator app, or email |
| User action | Click a link | Copy and paste a code |
| Phishing risk | Link can be spoofed | Code can be socially engineered |
| Expiration | Typically 10–15 minutes | Typically 30–60 seconds |
| Offline use | Requires network | TOTP apps work offline |
Magic links feel smoother because clicking beats copying a code, but they depend entirely on email deliverability. OTPs have shorter validity windows and work offline with authenticator apps, at the cost of greater user effort. Ory’s TOTP MFA support covers the code-based side if you want both options in one flow.
Passkeys, built on WebAuthn, are the most phishing-resistant method available today. Magic links sit between passwords and passkeys on both security and user experience.
| Factor | Password | Magic Link | Passkey (WebAuthn) |
|---|---|---|---|
| Credential storage | Server-side hash | None (ephemeral token) | Device-bound private key |
| Phishing resistance | Low | Medium | High |
| User friction | High | Low | Low |
| Device dependency | None | Email access required | Enrolled device required |
Passkeys are the stronger choice when phishing resistance is the priority. Magic links work well as a stepping stone for teams moving toward passwordless but not yet ready to deploy WebAuthn across the whole user base. If you want the full passkey picture, the overview of login methods lays out where each one belongs.
A handful of implementation details separate a secure magic link flow from a vulnerable one.
Generate tokens with at least 128 bits of randomness and sign them with HMAC or asymmetric keys to prevent forgery. Invalidate the token the instant it is used. A token that can be replayed is a token that can be stolen and reused.
Keep validity under 15 minutes to shrink the attack window. If your email pipeline is fast and reliable, go shorter. Plenty of systems run 5-minute expirations without meaningful user complaints.
Store a session cookie or browser fingerprint when the user requests the link, then verify it on click. This prevents cross-device hijacking, in which an attacker intercepts the link and opens it on their own device.
For sensitive actions like changing account settings or touching financial data, require a second factor after the link authenticates the email. Layering methods provide defense-in-depth and limit the blast radius if email is compromised. Risk-driven step-ups, covered in adaptive authentication, are a clean way to apply this only when the risk warrants it.
Track bounce rates, spam classification, and scanner-induced token invalidation. Add a “resend link” fallback for delivery failures. Users who cannot receive the email cannot log in, so deliverability is an authentication metric, not just a marketing one.
Add passwordless login to your app with Ory Kratos
Ory Kratos ships built-in passwordless flows, including magic links, with API-first configuration and flexible email templating. The headless architecture means you own the user experience end-to-end: Ory handles the security logic, while you design the interface. You can combine magic links with passkeys or additional MFA factors inside a single authentication flow. The custom email templates docs cover the delivery side, and the Ory Kratos quickstart gets you a working flow up and running fast.
Deployment scales with you. Start with open-source for proof-of-concept work and self-hosted control, or run on the fully managed Ory Network for a global identity service with built-in compliance and support. The breakdown of Ory Network versus self-hosting walks through which fits which use case. Magic links are an authentication primitive; pairing them with fine-grained authorization through Ory Keto gives you the full picture of who can do what after login.
For many consumer and B2B applications, yes, when implemented with short expiration windows, single-use tokens, and TLS-protected email delivery. For high-risk environments handling sensitive data, pair them with a second factor for stronger assurance.
By default the session starts on whichever device opens the link, which can confuse users or create a gap if an attacker intercepts the link. Binding the token to the originating session, or requiring confirmation on the original device, closes that.
Most implementations land between 5 and 15 minutes. Shorter windows reduce risk but demand fast, reliable delivery. The right number depends on your email infrastructure and your users’ tolerance for expired links.
Yes. After the user clicks the link, the app can prompt for a second factor, like a TOTP code, passkey, or biometric, to raise assurance for sensitive operations. The link proves email access; the second factor proves identity.
See Ory Kratos for passwordless authentication
Magic links are not a marginal tweak to password login. They move the trust anchor from a secret the user memorizes to an inbox the user controls, and in doing so they kill credential stuffing, offline cracking, and the entire “forgot password” support loop. They are not the strongest option on the board: passkeys are more phishing-resistant, and high-risk flows still want a second factor. But for teams that want off passwords today while they roll passkeys out tomorrow, magic links are the pragmatic move. Build them on signed, single-use, short-lived tokens, watch your deliverability, and treat them as one layer in a customer identity and access management stack rather than the whole thing.
