Magic link sign-in is appealing: no password to remember, the user enters their email, gets a link, taps it, and they are in. For a mobile app the link usually opens the app through a universal link. It is a good experience, and it moves the security question rather than removing it. The link contains a token that is effectively a temporary credential, so its strength, its lifetime, and how the server verifies it are what matter, and the channel it travels over, email or SMS, becomes part of your security model. Here is how magic links work, where the risks are, and how to implement them securely.
Short answer
Magic link authentication signs a user in by sending a one-time link, usually by email, that contains a token; tapping it, which on mobile opens the app via a universal link, authenticates the user. Per OWASP, the token in the link is a temporary credential, so it must be high-entropy and unguessable, single-use, and short-lived, verified on the server, with the request rate-limited. The delivery channel, email or SMS, becomes part of the security model, since whoever can read it can sign in, and SMS adds SIM-swap risk. Avoid account enumeration, do not leak the token, and consider binding the link to the device or session that requested it. The link is a credential in transit, so treat it like one.
What you should know
- The link contains a token that is a credential: it logs the user in.
- Make tokens unguessable, single-use, short-lived: and verified server-side.
- The delivery channel is part of security: email or SMS access means access.
- Rate-limit requests and avoid enumeration: do not reveal which emails exist.
- Verify on the server: the client does not decide the token is valid.
How do magic links work, and where is the risk?
The server issues a token, delivers it in a link, and verifies it when tapped. When a user requests sign-in, the server generates a token, stores or signs it, and sends a link containing it to the user's email or phone; the user opens the link, which on mobile is typically a universal link that launches the app, and the app sends the token to the server, which verifies it and establishes a session. The convenience is that there is no password, and the security shifts to two places. First, the token itself: because possessing the link is what authenticates, the token is a temporary credential, so if it is guessable, long-lived, or reusable, it can be abused. Second, the delivery channel: the link travels over email or SMS, so the security of the account now depends partly on the security of that inbox or phone number, anyone who can read the message can sign in, and SMS specifically carries SIM-swap risk. So magic links do not remove the credential problem; they turn it into a short-lived token delivered over a channel, both of which you must secure.
How do you secure the magic link token?
By making it strong, single-use, short-lived, and server-verified. The table summarizes.
| Property | Why it matters |
|---|---|
| High entropy | Unguessable, so it cannot be brute-forced |
| Single-use | Invalidated after first use, so it cannot be replayed |
| Short expiry | A small window limits a leaked or forwarded link |
| Server-side verification | The server, not the client, decides validity |
| Rate-limited issuance | Limits abuse and enumeration of the request endpoint |
The token must be generated with enough entropy that it cannot be guessed or brute-forced, since it is the credential, and it must be single-use, invalidated as soon as it is redeemed so a captured or forwarded link cannot be used again. A short expiry bounds the window in which a leaked link is valid, so an old link in an inbox is not a standing key. Verification happens on the server: the app passes the token, and the server checks it is valid, unexpired, and unused before establishing a session, rather than the client deciding. And the request endpoint, where a user asks for a link, should be rate-limited and must not reveal whether an email is registered, both to prevent abuse and to avoid account enumeration. These properties together make the token safe to send through a channel you do not fully control.
How do you implement magic links securely?
Strengthen the token, secure the flow, and account for the channel. Generate high-entropy, single-use tokens with a short expiry, store or sign them so the server can verify and invalidate them, and verify on the server before creating a session, never trusting the client's claim that a token is valid. Deliver the link as a universal link so it opens your genuine app rather than a hijackable custom scheme, and treat the incoming token as untrusted until the server verifies it. Rate-limit the request-a-link endpoint and respond the same way whether or not the email exists, so you neither enable abuse nor reveal which accounts exist. Be mindful of the channel: email access means account access, so consider this in your threat model, and prefer email over SMS where SIM-swap risk matters, or pair magic links with another factor for sensitive accounts. Consider binding the link to the device or session that requested it, so a link opened elsewhere is rejected or requires confirmation, which limits forwarded-link and interception risks. And keep the token out of logs, analytics, and anywhere it could leak. The principle is that a magic link is a short-lived credential in transit, so make the token strong and single-use, verify it server-side, secure the request flow, and treat the delivery channel as part of the trust boundary.
What to watch out for
The first trap is a weak, long-lived, or reusable token, which turns a leaked or forwarded link into a standing key; make tokens high-entropy, single-use, and short-lived. The second is forgetting the delivery channel is part of security, email compromise or SIM swap means account compromise. The third is account enumeration on the request endpoint and leaking the token in logs or a hijackable custom scheme. Magic link verification is server-side, so a pre-submission scan such as PTKD.com (https://ptkd.com), which reads the binary against OWASP MASVS, surfaces how your app handles authentication and the deep links it accepts, while the token strength, single-use enforcement, and verification are yours to implement on the backend.
What to take away
- Magic link authentication sends a one-time link containing a token that signs the user in, opening your app via a universal link, so the token is a temporary credential.
- Make the token high-entropy, single-use, and short-lived, verify it on the server, rate-limit issuance, and avoid account enumeration.
- The delivery channel is part of the security model, since email or SMS access grants account access and SMS adds SIM-swap risk, so consider binding the link to the requesting device and pairing with another factor for sensitive accounts.
- Use a pre-submission scan such as PTKD.com to surface your authentication and deep-link handling, and enforce token strength and verification on the backend.
