Sitemap
Anton Luckshman

Anton Luckshman

How I Built a Passwordless Magic Link Login System

3 min readMar 11, 2026

--

Press enter or click to view image in full size

Let’s face it: passwords are a hassle. Users forget them, hackers steal them, and managing them is a headache.

Recently, I decided to fix this for an admin panel I was building. Instead of a clunky email and password screen, I built a Magic Link system.

If you’ve ever used Slack, you know how this works: you type your email, receive a secure link in your inbox, and click it to instantly log in. Here is the simple, non-technical breakdown of how I built it.

Press enter or click to view image in full size

1. The Setup (The Database)

To make this work, I needed a secure way to remember when a user asks to log in.

I created a specific table in my database just for “magic links”. This table keeps track of three important things:

  1. The Token: A long, unguessable string of random letters and numbers.
  2. The Expiration: A strict 15-minute timer.
  3. The Lock: A marker that records the exact second the link is clicked, ensuring it can only be used once.

2. The Request (The “Send Link” Button)

When a user types their email into the login screen and clicks “Send Link”, the server springs into action.

Get Anton Luckshman’s stories in your inbox

Join Medium for free to get updates from this writer.

First, it checks if the user exists. (For security, the server always replies “Check your email!” whether the account exists or not this stops hackers from guessing valid emails).

Next, the server generates the secure token, saves it to the database with a 15-minute timer, and combines it with a website link. It takes this final link and uses an email service (like Mailjet) to deliver an email directly to the user’s inbox.

3. The Click (Logging In)

When the user opens the email and clicks the “Sign In” button, they are redirected back to the website. Hidden inside the web address is the secure token.

The website immediately spots the token and sends it to the server for verification.

4. The Verification (The Final Security Check)

When the server receives the token, it does a rigorous check:

  • Is this token real?
  • Has it been less than 15 minutes since it was created?
  • Most importantly: Has anyone clicked this before?

If everything looks perfect, the server immediately “locks” the token so it can never be used again. Finally, the server issues a standard login pass (called a JWT cookie) to the user’s browser, officially logging them into their dashboard!

By removing passwords, we eliminate the risk of stolen credentials and make logging in a breeze. Have you ever built a passwordless login? Let me know in the comments!

--

--