Test Magic Link Login Checklist
Use this three-layer checklist to test magic-link generation, delivery, redirects, sessions, replay, and expiry without recording a live credential.
Test a magic-link login in three layers. A UI demo proves only screen and copy. An email sandbox proves message generation and link shape. A real staging flow with a controlled mailbox proves delivery, redirect behavior, session creation, and configured one-time-use behavior. The test passes only when the intended user reaches an authenticated state, reloads it successfully, and gets the expected result on reuse.
You can open the simulated MagicLess demo to inspect the MagicLess interface. The demo does not connect to your app, send email, consume a token, or test authentication.
Use the matrix to choose a test layer. Keep the redacted record with the release so another reviewer can repeat it.
Start with the right test layer
| Test layer | What it can prove | What it cannot prove |
|---|---|---|
| UI demo | Form copy, loading states, and the visible "check your email" handoff | Message generation, delivery, redirects, or a session |
| Email sandbox | Template output, recipient, subject, link host, and provider handoff to the sandbox | Delivery to Gmail or a work mailbox, spam filtering, or final authentication |
| Real staging flow | Delivery to a controlled mailbox, redirects, session creation, protected-page access, and configured replay behavior | Production delivery for every user or mail-security system |
Use a synthetic test user in a labeled environment. Record redirect and session expectations before testing so every result has a baseline.
Run the happy path
- Record the date, build, environment, auth provider, browser, expected final page, and configured expiry or replay behavior.
- Start with a new synthetic address or an empty test inbox. Record the request time.
- Request one link. Do not resend while you wait; another credential can make the result ambiguous.
- Confirm the recipient, sender, subject, and environment label. Inspect the expected origin and a redacted route template. Remove credentials from the path, query, and fragment before storing or sharing evidence.
- Open the link in the browser context named in the test. Record the expected auth host, app host, and final page. Do not save the credential.
- Confirm authentication on a protected page or with the app's signed-in indicator. Reload once and confirm the session persists.
- Sign out, then test reuse only if your product or provider promises a single-use link.
Firebase separates sending from completion and requires the completion email to match the recipient. Supabase documents one-time links and configured redirect destinations. These are provider-specific facts.
Test negative cases that match your design
| Case | Safe test | Evidence |
|---|---|---|
| Reuse | Open a successful link again after sign-out, if single use is expected | Rejected state and recovery action |
| Expiry | Use a supported test setting or wait for the configured staging expiry | Configured expiry and resulting message |
| Wrong context | Open in a second browser only when the design has a documented expectation | Expected and actual result |
| Scanner prefetch | Use provider logs to see whether a work-mail scanner fetched the link first | First-hit time and user-visible result |
| Link rewriting | Compare the generated destination with the delivered destination | Expected host, delivered host, and redirect result |
Do not invent an expiry or assume every link must stay on one device. Auth0 documents a same-browser rule for one session-bound Classic Universal Login flow. Treat it as an Auth0 test case, not a universal rule.
Supabase warns that security prefetch can consume a confirmation URL and email tracking can rewrite authentication links. If a link arrives already invalid in a work inbox, use the mail-scanner diagnosis before blaming the callback.
Keep a redacted test record
Record the date, build, environment, provider, synthetic recipient, request and delivery times, redacted message ID, origin and redacted route template, final page, authenticated-state proof, reload result, and replay result. Classify a failure as generation, provider handoff, delivery, redirect, token exchange, or session. Strip credentials from the path, query, and fragment. Never store the full URL or token.
Illustrative example, 2026-10-22: staging build 418 sent one message to a synthetic address. It reached the expected auth origin, returned to the account page, survived one reload, and showed the expected used-link state after sign-out. The record stored timestamps and origin, not the credential.
"Email received" is not an end-to-end pass. "Dashboard visible" is also incomplete if the session disappears on reload.
Know where this checklist ends
This checklist tests application and provider configuration. It does not certify the design. Use the passwordless security checklist for broader controls. Send users with failed links to the magic-link recovery guide, not through QA steps.
MagicLess does not test message generation, delivery, redirects, sessions, replay protection, or expiry. Its demo is simulated. Do not cite it as authentication evidence.
FAQ
Does a UI demo test magic-link authentication?
No. It proves visible states and copy, not that a real message was delivered or exchanged for a session.
Can an email sandbox prove real delivery?
It proves delivery to that sandbox and helps inspect the message. It cannot prove delivery to Gmail, a managed work inbox, or every spam-filter setup.
Should a magic link work in another browser or device?
That depends on the provider and design. Record the expected behavior first. Auth0's documented same-browser rule applies to a specific session-bound flow.
How do I test one-time use without exposing the token?
Open the controlled link. Record only its origin, redacted route template, message ID, and result, then retry after sign-out. Remove credentials from the path, query, and fragment, and never paste the full URL into logs or tickets.
Can MagicLess test my application's authentication flow?
No. Its demo does not validate your app, provider, mailbox delivery, token, or session.
Claim ledger
| Claim | Primary source | Checked | Confidence |
|---|---|---|---|
| Firebase separates link sending from completion, uses authorized domains, and requires the completion email to match the recipient. | Firebase email-link authentication | 2026-10-22 | High |
| Supabase magic links are one-time use and use configured Site URL or allowed redirect URLs. | Supabase passwordless email sign-in | 2026-10-22 | High |
| Prefetch can consume confirmation URLs, and tracking can rewrite authentication links. | Supabase email templates | 2026-10-22 | High |
| Supabase recommends an email sandbox and Auth logs for initial handoff errors. | Supabase auth-email troubleshooting | 2026-10-22 | High |
| Auth0's documented Classic Universal Login flow can require the original browser because its temporary token is session-bound. | Auth0 support | 2026-10-22 | High |