Skip to content

Instantly share code, notes, and snippets.

@mrl22
Last active April 10, 2026 12:57
Show Gist options
  • Select an option

  • Save mrl22/4e28d0254505cabb8717c53a2c07313d to your computer and use it in GitHub Desktop.

Select an option

Save mrl22/4e28d0254505cabb8717c53a2c07313d to your computer and use it in GitHub Desktop.
How Webforward Implements Passwordless Login

How Webforward Implements Passwordless Login

Passwordless login removes the need for passwords entirely. Instead of remembering credentials, users log in using a secure, time-limited link sent to their email.

This improves both usability and security by removing one of the most common causes of breaches: weak or reused passwords.


How it works

  1. The user enters their email address
  2. A secure, time-limited login link is generated
  3. The link is sent to their email
  4. The user opens the link and is taken to a confirmation page
  5. Clicking “Continue login” securely signs them in

This extra confirmation step is intentional and prevents email security scanners or link previews from accidentally logging users in.


Security features (and why they matter)

1. Signed login links (tamper-proof)

Each login link is cryptographically signed and tied to the data within it (such as email, token, and expiry).

Why this matters:
If any part of the link is altered, the signature becomes invalid and access is denied. This prevents attackers from modifying or forging login links.


2. Secure token storage (hashed tokens)

Login tokens are never stored in plain text. Instead, a one-way hash (SHA-256) of the token is stored in the database.

Why this matters:
Even in the unlikely event of database access, the original login links cannot be reconstructed or used.


3. Strict expiry (dual-layer enforcement)

Each login link expires after 30 minutes. This is enforced both in the signed URL and in the database.

Why this matters:
Links become useless very quickly, even if intercepted. Dual enforcement ensures expiry cannot be bypassed.


4. Single-use tokens (atomic consumption)

Each token can only be used once. When the user confirms login, the system atomically marks the token as used.

Why this matters:
Prevents reuse, sharing, or replay attacks. Even if a link is opened multiple times, only the first successful attempt works.


5. Confirmation step (anti-prefetch protection)

Users must actively confirm login after opening the link.

Why this matters:
Many email providers and security tools automatically open links to scan them. Without this step, those systems could unintentionally log users in. This ensures only real user interaction completes authentication.


6. Rate limiting (per email and IP)

Login requests and verification attempts are strictly limited.

Why this matters:
Protects against:

  • Email spam and abuse
  • Automated token guessing
  • Brute-force attempts on login endpoints

7. Session security (regeneration on login)

A fresh session is created on every successful login.

Why this matters:
Prevents session fixation attacks and ensures sessions cannot be reused or predicted.


8. Token invalidation (latest link only)

Any previously issued login links are invalidated when a new one is requested.

Why this matters:
Only the most recent email link can be used, reducing risk from older emails being accessed later.


9. Audit logging and monitoring

Authentication events such as login attempts and token usage are recorded.

Why this matters:
Provides a clear audit trail for monitoring, troubleshooting, and identifying suspicious activity.


Security compared to passwords

Traditional password-based systems rely heavily on user behaviour, which introduces risk:

  • Weak or predictable passwords
  • Password reuse across multiple services
  • Credentials exposed in third-party breaches
  • Susceptibility to brute-force attacks

Passwordless login removes these risks entirely by eliminating passwords from the system.


Security compared to 2FA

Two-factor authentication (2FA) improves security by adding a second step, but still relies on passwords.

2FA strengths:

  • Adds protection if a password is compromised

Limitations:

  • Still vulnerable to phishing
  • Dependent on users enabling and maintaining it
  • Adds friction to the login process

Passwordless approach:

  • No password to steal, reuse, or phish
  • Consistent security for all users (no opt-in required)
  • Simpler user experience with fewer failure points

Access is instead based on control of the user’s email account — the same trust model already used by password reset systems.

In practice, this means the security of the account is directly tied to the security of the user’s email provider. When using modern platforms such as Google Mail or Office 365, which typically include strong protections like multi-factor authentication (MFA), device verification, and advanced threat detection, the login process becomes just as secure as those systems.

As a result, users benefit from enterprise-grade security without needing to manage passwords separately. If their email account is protected with strong authentication methods, the same level of protection naturally extends to their access here.


Summary

This implementation removes the most common and exploitable weaknesses found in traditional authentication systems, while maintaining a simple and reliable user experience.

By combining:

  • Cryptographically signed login links
  • Hashed, single-use tokens
  • Strict expiry enforcement
  • Confirmation-based login flow
  • Rate limiting and abuse protection
  • Secure session handling
  • Token invalidation
  • Full audit logging

…it delivers strong, real-world security without the complexity and risks associated with passwords.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment