diff --git a/content/magiclinks/index.md b/content/magiclinks/index.md
new file mode 100644
index 00000000..5a348926
--- /dev/null
+++ b/content/magiclinks/index.md
@@ -0,0 +1,1870 @@
+---
+title: Magic Links Tutorial Secure Passwordless Login Made Simple
+description: "Learn how magic links work, their benefits, and how to implement them for secure, seamless passwordless authentication."
+date: "2025-09-08"
+cover: "magic_links.png"
+category: "auth, guide, magiclinks"
+author: "Maurice Saldivar"
+---
+
+
+# What Are Magic Links and Why They Matter
+
+A comprehensive guide to understanding, implementing, and optimizing magic link authentication in modern web applications.
+
+## What Is a Magic Link?
+
+### Definition
+
+A magic link is a one-time use URL sent to a user's email to authenticate them without requiring a password. This URL contains a cryptographically secure token that uniquely identifies an authentication request and grants access when clicked. The link typically follows a structure like `https://app.example.com/auth/verify?token=a4f8c2e9b7d3f6e2` where the token serves as a temporary credential.
+
+Magic links shift the authentication factor from something you know (a password) to something you have (access to an email account). This fundamental change eliminates entire categories of security vulnerabilities while simplifying the user experience.
+
+### How It Works
+
+The magic link authentication flow consists of five distinct steps:
+
+1. **User Initiates Login**: The user enters their email address on the login page
+2. **Token Generation**: The server generates a cryptographically random token and stores it with metadata including timestamp, user identifier, and expiration time
+3. **Email Delivery**: The system sends an email containing the unique authentication URL to the user's registered address
+4. **Link Activation**: The user clicks the link, sending the token back to the server
+5. **Verification and Session Creation**: The server validates the token, confirms it hasn't expired or been used, then creates an authenticated session
+
+```javascript
+// Server-side token generation example
+const crypto = require('crypto');
+
+async function generateMagicLink(email) {
+  // Generate token and hash
+  const token = crypto.randomBytes(32).toString('hex');
+  const tokenHash = crypto.createHash('sha256').update(token).digest('hex');
+  
+  // Store token with metadata
+  await storeToken({
+    token: hashToken(token),
+    email: email,
+    createdAt: Date.now(),
+    expiresAt: Date.now() + (15 * 60 * 1000),
+    used: false
+  });
+  
+  // Create magic link URL
+  const magicLink = `${process.env.APP_URL}/auth/verify?token=${token}`;
+  
+  return magicLink;
+}
+```
+
+The backend token match happens when the user clicks the link. The server receives the token, looks it up in the database, validates its properties, and either grants access or rejects the authentication attempt based on the validation results.
+
+Token expiration serves as a critical security control. Most implementations expire tokens after 15 to 30 minutes or immediately after first use. This limited validity window reduces the risk of token interception or unauthorized access if an email account is compromised later.
+
+### Use Cases
+
+Magic links excel in specific authentication scenarios where traditional passwords create unnecessary friction or security risks.
+
+**Passwordless Logins**
+
+Modern applications increasingly adopt magic links as their primary authentication method. Medium, Slack (for guest users), and Notion demonstrate successful passwordless implementations. These platforms recognized that infrequent users often forget passwords, leading to abandoned sessions and support tickets. Magic links eliminate this friction entirely.
+
+For applications with sporadic usage patterns, magic links provide superior user experience. A user returning after months doesn't need to remember or reset a password. They simply enter their email and click the link to regain access.
+
+**Account Recovery**
+
+Traditional password reset flows already resemble magic links: users receive an email with a temporary link to set a new password. Magic links streamline this by eliminating the password entirely. Instead of "reset your password," the flow becomes "sign in with email."
+
+This approach particularly benefits applications migrating from password-based authentication. Users familiar with password reset emails naturally understand magic link authentication, reducing the learning curve during transition.
+
+**Low-Friction Sign-ups**
+
+Conversion optimization research consistently shows that each additional form field reduces completion rates. Magic links enable single field registration: users enter only their email address to create an account and access the application.
+
+Ecommerce platforms use magic links for guest checkout flows. Customers purchase without creating passwords, reducing cart abandonment while still maintaining order history and user tracking.
+
+Enterprise applications leverage magic links for temporary access. Contractors, auditors, or short term collaborators receive magic links for time limited access without cluttering the organization's identity management system with rarely used accounts.
+
+The asynchronous nature of email based authentication also enables interesting workflows. Document sharing platforms send magic links that simultaneously create accounts and grant document access. This pattern reduces sharing friction while maintaining security and audit trails.
+
+## How Do Magic Links Improve Authentication?
+
+### Frictionless UX
+
+Password-based authentication creates cognitive load that directly impacts user engagement and conversion metrics. Users maintain an average of 100 passwords across personal and professional accounts, according to [NordPass's 2024 study](https://nordpass.com/blog/how-many-passwords-does-average-person-have/). This password proliferation leads to predictable behaviors: password reuse, weak passwords, and frequent resets.
+
+Magic links eliminate this cognitive burden entirely. The authentication process requires only email access, something users already manage as part of their digital routine. This simplification yields measurable improvements in user behavior and business metrics.
+
+**Conversion Rate Impact**
+
+Substack's implementation of magic links increased newsletter subscription conversions by 28% compared to traditional password registration. The simplified flow removed the friction point where users abandon registration when faced with password creation requirements.
+
+**Mobile Experience Benefits**
+
+Password entry on mobile devices remains particularly problematic. Small keyboards, auto-correct interference, and special character accessibility create frustration. Magic links bypass these issues entirely. Users tap their email app notification and authenticate instantly.
+
+```javascript
+// Mobile-optimized magic link flow
+async function sendMagicLink(email, userAgent) {
+  const isMobile = /iPhone|iPad|iPod|Android/i.test(userAgent);
+  
+  const magicLink = await generateMagicLink(email);
+  
+  // Customize email content for mobile users
+  const emailTemplate = isMobile ? 
+    getMobileEmailTemplate(magicLink) : 
+    getDesktopEmailTemplate(magicLink);
+  
+  await sendEmail({
+    to: email,
+    subject: 'Your login link',
+    html: emailTemplate,
+    // Deep link for mobile apps
+    headers: isMobile ? {
+      'X-Universal-Link': magicLink
+    } : {}
+  });
+}
+```
+
+**Accessibility Advantages**
+
+Magic links improve authentication accessibility for users with disabilities. Password managers often conflict with screen readers, and complex password requirements challenge users with cognitive impairments. Email based authentication leverages familiar email client interfaces that users have already configured for their accessibility needs.
+
+### Reduced Attack Surface
+
+Traditional password authentication exposes multiple attack vectors that magic links inherently resist or eliminate.
+
+**Phishing Resistance**
+
+While magic links don't provide complete phishing immunity, they significantly reduce phishing effectiveness. Traditional phishing attacks harvest passwords that remain valid until changed. Magic links expire within minutes and work only once, limiting the window for exploitation.
+
+Even if users click phishing emails mimicking magic link requests, attackers cannot capture reusable credentials. The token sent to a phishing site becomes worthless after expiration or first use. This temporal limitation fundamentally changes the economics of phishing attacks.
+
+**Credential Stuffing Immunity**
+
+The [2023 Shape Security report](https://qz.com/1329961/hackers-account-for-90-of-login-attempts-at-online-retailers) identified credential stuffing as being responsible for 90% of login attempts on retail websites. Attackers use automated tools to test stolen username/password combinations across multiple services, exploiting password reuse.
+
+Magic links eliminate this attack vector completely. Without passwords to steal or reuse, credential stuffing becomes impossible. Each authentication requires a fresh token delivered to the legitimate email account, blocking automated attack tools.
+
+```python
+# Traditional auth
+def traditional_login(username, password):
+    # Attackers can repeatedly attempt different passwords
+    user = get_user(username)
+    if verify_password(password, user.password_hash):
+        return create_session(user)
+    return None
+
+# Magic link auth 
+def magic_link_login(token):
+    # Each token works exactly once
+    stored_token = get_unused_token(token)
+    if not stored_token:
+        return None
+    
+    if stored_token.expires_at < datetime.now():
+        return None
+    
+    # Mark as used immediately
+    mark_token_used(stored_token.id)
+    return create_session(stored_token.user)
+```
+
+**Brute Force Prevention**
+
+Password systems require complex rate limiting and account lockout mechanisms to prevent brute force attacks. Attackers attempt thousands of password combinations, exploiting weak or common passwords.
+
+Magic links inherently resist brute force through cryptographic token strength. A properly generated 256-bit token has 2^256 possible values, making brute force statistically impossible within the token's lifetime. The combination of high entropy and short expiration creates an impenetrable authentication barrier.
+
+Additionally, rate limiting becomes simpler. Systems can restrict email sending frequency without complex IP tracking or CAPTCHA systems that frustrate legitimate users.
+
+### Lower Support Load
+
+Password related issues dominate IT support workloads across organizations of all sizes. [Gartner research](https://specopssoft.com/blog/save-money-self-service-password-resets/) indicates that password resets account for 40% of help desk call volume, with each reset costing organizations between $20 and $50 in support resources.
+
+**Eliminating Password Reset Tickets**
+
+Magic links remove the primary source of authentication support requests. Users cannot forget passwords that don't exist. This elimination of password reset tickets provides immediate operational benefits.
+
+**Simplified Troubleshooting**
+
+When authentication issues arise with magic links, troubleshooting follows a predictable pattern: email delivery problems. Support teams need expertise in only one area rather than managing password policies, complexity requirements, expiration rules, and account lockout procedures.
+
+Common magic link support issues and resolutions:
+
+```javascript
+// Automated troubleshooting for magic link issues
+const troubleshootMagicLink = {
+  emailNotReceived: {
+    causes: ['Spam folder', 'Email delays', 'Incorrect address'],
+    solutions: [
+      'Check spam/junk folder',
+      'Wait 5 minutes for delivery',
+      'Verify email address',
+      'Resend link'
+    ]
+  },
+  
+  linkExpired: {
+    causes: ['Token timeout', 'Already used'],
+    solutions: ['Request new link']
+  },
+  
+  linkNotWorking: {
+    causes: ['Email client modification', 'Security software'],
+    solutions: [
+      'Copy and paste full link',
+      'Try different browser',
+      'Disable email link scanning'
+    ]
+  }
+};
+```
+
+**Reduced Security Training Requirements**
+
+Organizations spend considerable resources training employees on password security: complexity requirements, rotation schedules, and phishing recognition. Magic links simplify security training to a single principle: protect your email account.
+
+This focused security message proves more effective than complex password policies. Users understand email security from personal experience, making training more relatable and actionable. The cumulative effect of these improvements extends beyond direct cost savings. IT teams freed from password support can focus on strategic initiatives. Users spend less time on authentication issues and more time on productive work. The entire organization benefits from reduced authentication friction and improved security posture.
+
+## Technical Implementation of Magic Links
+
+### Step-by-Step Backend Workflow
+
+Building a production-ready magic link system requires careful attention to security, reliability, and user experience. The implementation involves four core operations that must work together seamlessly.
+
+**Capture Email Input and Generate a Time-Limited Token**
+
+The authentication flow begins when users submit their email address. The backend must validate the email format, check user existence, and generate a cryptographically secure token.
+
+```javascript
+const crypto = require('crypto');
+const { z } = require('zod');
+
+const emailSchema = z.string().email().toLowerCase();
+
+async function initiateMagicLink(email) {
+  try {
+    const validatedEmail = emailSchema.parse(email);
+  } catch (error) {
+    throw new ValidationError('Invalid email format');
+  }
+  
+  // Check if user exists (create if needed for new signups)
+  const user = await getUserByEmail(validatedEmail) || 
+               await createUser(validatedEmail);
+  
+  const token = crypto.randomBytes(32).toString('base64url');
+  
+  const tokenData = {
+    token: token,
+    userId: user.id,
+    email: validatedEmail,
+    createdAt: new Date(),
+    expiresAt: new Date(Date.now() + 15 * 60 * 1000),
+    used: false,
+    ipAddress: request.ip,
+    userAgent: request.headers['user-agent']
+  };
+  
+  return { token, tokenData, user };
+}
+```
+
+Token generation must use cryptographically secure random number generators. Node.js's `crypto.randomBytes()` or Python's `secrets` module provide appropriate entropy. Avoid using `Math.random()` or similar pseudorandom functions that lack cryptographic security.
+
+**Store Token Securely (Hashed or Encrypted)**
+
+Storing tokens in plain text creates unnecessary risk. If the database is compromised, attackers gain valid authentication tokens. Implement the same security measures used for password storage.
+
+```python
+import hashlib
+import secrets
+from datetime import datetime, timedelta
+from sqlalchemy import Column, String, DateTime, Boolean
+
+class MagicLinkToken(db.Model):
+    __tablename__ = 'magic_link_tokens'
+    
+    id = Column(String, primary_key=True)
+    token_hash = Column(String, nullable=False, index=True)
+    user_id = Column(String, nullable=False)
+    email = Column(String, nullable=False)
+    created_at = Column(DateTime, default=datetime.utcnow)
+    expires_at = Column(DateTime, nullable=False)
+    used = Column(Boolean, default=False)
+    used_at = Column(DateTime, nullable=True)
+    ip_address = Column(String, nullable=True)
+    user_agent = Column(String, nullable=True)
+
+    @classmethod
+    def create_token(cls, user_id, email, ip_address=None, user_agent=None):
+        raw_token = secrets.token_urlsafe(32)
+        
+        # Hash token for storage
+        token_hash = hashlib.sha256(raw_token.encode()).hexdigest()
+        
+        # Create database record
+        token_record = cls(
+            id=secrets.token_hex(16),
+            token_hash=token_hash,
+            user_id=user_id,
+            email=email,
+            expires_at=datetime.utcnow() + timedelta(minutes=15),
+            ip_address=ip_address,
+            user_agent=user_agent
+        )
+        
+        db.session.add(token_record)
+        db.session.commit()
+        
+        # Return raw token for email
+        return raw_token, token_record.id
+    
+    @classmethod
+    def verify_token(cls, raw_token):
+        token_hash = hashlib.sha256(raw_token.encode()).hexdigest()
+        
+        token_record = cls.query.filter_by(
+            token_hash=token_hash,
+            used=False
+        ).first()
+        
+        if not token_record:
+            return None
+        
+        if datetime.utcnow() > token_record.expires_at:
+            return None
+        
+        token_record.used = True
+        token_record.used_at = datetime.utcnow()
+        db.session.commit()
+        
+        return token_record
+```
+
+**Send Link Containing Token to User's Email**
+
+Email delivery reliability directly impacts authentication success rates. Use transactional email services that provide delivery tracking and handle email provider quirks.
+
+```javascript
+const nodemailer = require('nodemailer');
+const aws = require('@aws-sdk/client-ses');
+
+class MagicLinkEmailService {
+  constructor() {
+    // Using Amazon SES 
+    this.transporter = nodemailer.createTransporter({
+      SES: { 
+        ses: new aws.SES({ region: 'us-east-1' }), 
+        aws 
+      }
+    });
+  }
+  
+  async sendMagicLink(email, token, metadata = {}) {
+    const magicLink = `${process.env.APP_URL}/auth/verify?token=${token}`;
+    
+    // Track email metrics
+    const messageId = crypto.randomUUID();
+    
+    const emailHtml = `
+      <!DOCTYPE html>
+      <html>
+        <head>
+          <meta name="viewport" content="width=device-width, initial-scale=1.0">
+        </head>
+        <body style="font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, sans-serif;">
+          <div style="max-width: 600px; margin: 0 auto; padding: 20px;">
+            <h2>Your Login Link</h2>
+            <p>Click the button below to log in to your account:</p>
+            <a href="${magicLink}" 
+               style="display: inline-block; 
+                      padding: 12px 24px; 
+                      background-color: #0066cc; 
+                      color: white; 
+                      text-decoration: none; 
+                      border-radius: 4px;
+                      margin: 20px 0;">
+              Log In to Your Account
+            </a>
+            <p style="color: #666; font-size: 14px;">
+              This link expires in 15 minutes. If you didn't request this, please ignore this email.
+            </p>
+            <p style="color: #999; font-size: 12px;">
+              Having trouble? Copy and paste this link: ${magicLink}
+            </p>
+          </div>
+        </body>
+      </html>
+    `;
+    
+    const mailOptions = {
+      from: `${process.env.APP_NAME} <noreply@${process.env.EMAIL_DOMAIN}>`,
+      to: email,
+      subject: 'Your login link',
+      html: emailHtml,
+      text: `Log in to your account: ${magicLink}\n\nThis link expires in 15 minutes.`,
+      headers: {
+        'X-Message-ID': messageId,
+        'X-Entity-Ref-ID': metadata.userId
+      }
+    };
+    
+    try {
+      const info = await this.transporter.sendMail(mailOptions);
+      
+      // Log delivery attempt for monitoring
+      await this.logEmailSent({
+        messageId,
+        email,
+        provider: 'ses',
+        providerMessageId: info.messageId,
+        timestamp: new Date()
+      });
+      
+      return { success: true, messageId };
+    } catch (error) {
+      // Log failure for debugging
+      await this.logEmailFailed({
+        messageId,
+        email,
+        error: error.message,
+        timestamp: new Date()
+      });
+      
+      throw new EmailDeliveryError('Failed to send magic link');
+    }
+  }
+}
+```
+
+**On Click, Verify Token and Authenticate Session**
+
+Token verification must handle multiple security checks before granting access. The verification endpoint needs protection against timing attacks and should provide clear error messages for debugging.
+
+```javascript
+const express = require('express');
+const router = express.Router();
+
+router.get('/auth/verify', async (req, res) => {
+  const { token } = req.query;
+  
+  if (!token) {
+    return res.status(400).render('auth-error', {
+      error: 'Missing authentication token',
+      action: 'Request a new login link'
+    });
+  }
+  
+  try {
+    // Verify token and get user
+    const tokenRecord = await verifyMagicLinkToken(token);
+    
+    if (!tokenRecord) {
+      return res.status(401).render('auth-error', {
+        error: 'Invalid or expired link',
+        action: 'Request a new login link'
+      });
+    }
+    
+    // Additional security checks
+    if (tokenRecord.ipAddress && tokenRecord.ipAddress !== req.ip) {
+      await logSecurityEvent({
+        type: 'IP_MISMATCH',
+        userId: tokenRecord.userId,
+        originalIp: tokenRecord.ipAddress,
+        currentIp: req.ip
+      });
+      // Continue but flag for monitoring
+    }
+    
+    // Create session
+    const session = await createUserSession({
+      userId: tokenRecord.userId,
+      authMethod: 'magic_link',
+      ipAddress: req.ip,
+      userAgent: req.headers['user-agent']
+    });
+    
+    // Set secure session cookie
+    res.cookie('session', session.token, {
+      httpOnly: true,
+      secure: process.env.NODE_ENV === 'production',
+      sameSite: 'lax',
+      maxAge: 7 * 24 * 60 * 60 * 1000 // 7 days
+    });
+    
+    // Redirect to application
+    const redirectUrl = tokenRecord.redirectUrl || '/dashboard';
+    res.redirect(redirectUrl);
+    
+  } catch (error) {
+    console.error('Token verification error:', error);
+    res.status(500).render('auth-error', {
+      error: 'Authentication failed',
+      action: 'Please try again'
+    });
+  }
+});
+```
+
+### Frontend Best Practices
+
+The user interface must provide clear feedback throughout the authentication process while handling edge cases gracefully.
+
+**Show Feedback ("Link sent to your email")**
+
+Users need immediate confirmation that their authentication request was received and processed. Implement progressive UI states that guide users through the flow.
+
+```javascript
+import React, { useState } from 'react';
+import { validateEmail } from './utils';
+
+function MagicLinkLogin() {
+  const [email, setEmail] = useState('');
+  const [status, setStatus] = useState('idle'); // idle, sending, sent, error
+  const [errorMessage, setErrorMessage] = useState('');
+  
+  const handleSubmit = async (e) => {
+    e.preventDefault();
+    
+    if (!validateEmail(email)) {
+      setErrorMessage('Please enter a valid email address');
+      return;
+    }
+    
+    setStatus('sending');
+    setErrorMessage('');
+    
+    try {
+      const response = await fetch('/api/auth/magic-link', {
+        method: 'POST',
+        headers: { 'Content-Type': 'application/json' },
+        body: JSON.stringify({ email })
+      });
+      
+      const data = await response.json();
+      
+      if (!response.ok) {
+        throw new Error(data.message || 'Failed to send login link');
+      }
+      
+      setStatus('sent');
+      
+      // Show success state for sufficient time
+      setTimeout(() => {
+        // Keep success message visible
+      }, 5000);
+      
+    } catch (error) {
+      setStatus('error');
+      setErrorMessage(error.message);
+    }
+  };
+  
+  return (
+    <div className="auth-container">
+      {status === 'sent' ? (
+        <div className="success-message">
+          <svg className="check-icon" viewBox="0 0 24 24">
+            <path d="M9 11l3 3L22 4" />
+          </svg>
+          <h2>Check your email!</h2>
+          <p>We sent a login link to <strong>{email}</strong></p>
+          <p className="helper-text">
+            The link expires in 15 minutes. Didn't receive it?
+            <button 
+              onClick={() => setStatus('idle')}
+              className="link-button"
+            >
+              Try again
+            </button>
+          </p>
+        </div>
+      ) : (
+        <form onSubmit={handleSubmit}>
+          <h2>Sign in with email</h2>
+          <input
+            type="email"
+            value={email}
+            onChange={(e) => setEmail(e.target.value)}
+            placeholder="Enter your email"
+            disabled={status === 'sending'}
+            aria-label="Email address"
+            autoComplete="email"
+          />
+          
+          {errorMessage && (
+            <div className="error-message" role="alert">
+              {errorMessage}
+            </div>
+          )}
+          
+          <button 
+            type="submit" 
+            disabled={status === 'sending'}
+            className={`submit-button ${status === 'sending' ? 'loading' : ''}`}
+          >
+            {status === 'sending' ? (
+              <>
+                <span className="spinner" />
+                Sending link...
+              </>
+            ) : (
+              'Send login link'
+            )}
+          </button>
+        </form>
+      )}
+    </div>
+  );
+}
+```
+
+**Handle Errors Gracefully (Expired, Used, or Invalid Link)**
+
+Error handling requires balancing security with user experience. Provide helpful guidance without revealing sensitive information about the authentication system.
+
+```typescript
+interface AuthError {
+  code: string;
+  message: string;
+  action: string;
+}
+
+class MagicLinkErrorHandler {
+  private static readonly ERROR_MESSAGES: Record<string, AuthError> = {
+    TOKEN_EXPIRED: {
+      code: 'TOKEN_EXPIRED',
+      message: 'This login link has expired',
+      action: 'Request a new link to sign in'
+    },
+    TOKEN_USED: {
+      code: 'TOKEN_USED',
+      message: 'This login link has already been used',
+      action: 'Request a new link to sign in'
+    },
+    TOKEN_INVALID: {
+      code: 'TOKEN_INVALID',
+      message: 'This login link is invalid',
+      action: 'Make sure you clicked the correct link or request a new one'
+    },
+    RATE_LIMITED: {
+      code: 'RATE_LIMITED',
+      message: 'Too many login attempts',
+      action: 'Please wait a few minutes before requesting another link'
+    }
+  };
+  
+  static handleVerificationError(error: any): AuthError {
+    // Map specific errors to user-friendly messages
+    const errorCode = error?.code || 'TOKEN_INVALID';
+    return this.ERROR_MESSAGES[errorCode] || this.ERROR_MESSAGES.TOKEN_INVALID;
+  }
+  
+  static createErrorPage(error: AuthError): string {
+    return `
+      <div class="error-container">
+        <div class="error-icon">⚠️</div>
+        <h1>${error.message}</h1>
+        <p>${error.action}</p>
+        <a href="/login" class="button">Back to login</a>
+      </div>
+    `;
+  }
+}
+```
+
+### Security Recommendations
+
+Production magic link systems require multiple security layers to prevent abuse and protect user accounts.
+
+**Expiration Time (15 Minutes)**
+
+Token lifetime balances security with usability. Shorter expiration times reduce risk but may frustrate users who don't check email immediately. Industry practice converges on 15 to 30 minute windows.
+
+```javascript
+class TokenExpirationPolicy {
+  static readonly DEFAULT_EXPIRY = 15 * 60 * 1000; // 15 minutes
+  static readonly MAX_EXPIRY = 60 * 60 * 1000; // 1 hour
+  static readonly MIN_EXPIRY = 5 * 60 * 1000; // 5 minutes
+  
+  static calculateExpiry(userContext) {
+    // Adjust expiration based on risk factors
+    let expiryMs = this.DEFAULT_EXPIRY;
+    
+    if (userContext.isHighValue) {
+      // Shorter expiry for admin accounts
+      expiryMs = this.MIN_EXPIRY;
+    } else if (userContext.trustedDevice) {
+      // Slightly longer for recognized devices
+      expiryMs = 20 * 60 * 1000;
+    }
+    
+    return new Date(Date.now() + expiryMs);
+  }
+  
+  static isExpired(expiresAt) {
+    return new Date() > new Date(expiresAt);
+  }
+}
+```
+
+**Single-Use Enforcement**
+
+Tokens must become invalid immediately after successful use. This prevents replay attacks and limits damage from compromised tokens.
+
+```sql
+-- Atomic single use 
+CREATE TABLE magic_link_tokens (
+    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+    token_hash VARCHAR(64) NOT NULL,
+    user_id UUID NOT NULL,
+    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
+    expires_at TIMESTAMP NOT NULL,
+    used_at TIMESTAMP,
+    ip_address INET,
+    user_agent TEXT,
+    CONSTRAINT unique_unused_token UNIQUE (token_hash)
+);
+
+-- Atomic token consumption
+CREATE OR REPLACE FUNCTION consume_magic_token(
+    p_token_hash VARCHAR(64)
+) RETURNS TABLE(user_id UUID, email VARCHAR) AS $$
+BEGIN
+    RETURN QUERY
+    UPDATE magic_link_tokens
+    SET used_at = CURRENT_TIMESTAMP
+    WHERE token_hash = p_token_hash
+      AND used_at IS NULL
+      AND expires_at > CURRENT_TIMESTAMP
+    RETURNING user_id, email;
+END;
+$$ LANGUAGE plpgsql;
+```
+
+**IP/Device Fingerprinting (Optional for Higher Security)**
+
+Additional verification layers can detect suspicious authentication attempts without adding user friction.
+
+```javascript
+const crypto = require('crypto');
+
+class DeviceFingerprint {
+  static generate(request) {
+    const components = [
+      request.headers['user-agent'],
+      request.headers['accept-language'],
+      request.headers['accept-encoding'],
+      this.getScreenResolution(request),
+      this.getTimezone(request)
+    ];
+    
+    const fingerprintString = components
+      .filter(Boolean)
+      .join('|');
+    
+    return crypto
+      .createHash('sha256')
+      .update(fingerprintString)
+      .digest('hex');
+  }
+  
+  static async verify(storedFingerprint, currentRequest, tolerance = 0.8) {
+    const currentFingerprint = this.generate(currentRequest);
+    
+    if (storedFingerprint === currentFingerprint) {
+      return { match: true, confidence: 1.0 };
+    }
+    
+    // Fuzzy matching for minor changes
+    const similarity = this.calculateSimilarity(
+      storedFingerprint, 
+      currentFingerprint
+    );
+    
+    return {
+      match: similarity >= tolerance,
+      confidence: similarity
+    };
+  }
+  
+  static riskAssessment(tokenData, currentRequest) {
+    const risks = [];
+    
+    // IP address change
+    if (tokenData.ipAddress !== currentRequest.ip) {
+      const distance = this.calculateGeoDistance(
+        tokenData.ipAddress,
+        currentRequest.ip
+      );
+      
+      if (distance > 100) { // More than 100km
+        risks.push({
+          factor: 'ip_location_change',
+          severity: distance > 1000 ? 'high' : 'medium'
+        });
+      }
+    }
+    
+    // Time based analysis
+    const timeSinceCreation = Date.now() - tokenData.createdAt;
+    if (timeSinceCreation < 2000) { // Less than 2 seconds
+      risks.push({
+        factor: 'too_fast',
+        severity: 'medium'
+      });
+    }
+    
+    return {
+      riskLevel: this.calculateOverallRisk(risks),
+      factors: risks
+    };
+  }
+}
+```
+
+These security measures work together to create defense in depth. No single control provides complete protection, but the combination significantly raises the bar for attackers while maintaining usability for legitimate users.
+
+## Magic Links vs Other Passwordless Methods
+
+### Comparison Table
+
+Passwordless authentication encompasses multiple approaches, each with distinct trade-offs in security, user experience, and implementation complexity. Understanding these differences guides selection of the appropriate method for specific use cases.
+
+| Method | Security Level | UX Convenience | Setup Complexity 
+|--------|---------------|----------------|-----------------
+| **Magic Links** | High | Very High | Moderate | 
+| **SMS/Email OTP** | Medium | Moderate | Low | 
+| **WebAuthn/Biometrics** | Very High | High | High | 
+| **Hardware Tokens** | Very High | Low | Very High |
+
+**Security Level Definitions:**
+- **Medium**: Vulnerable to SIM swapping, phishing, or interception
+- **High**: Resistant to most attacks, some theoretical vulnerabilities
+- **Very High**: Cryptographically secure, phishing-resistant
+
+
+### Detailed Method Analysis
+
+**Magic Links**
+
+Magic links provide high security through cryptographic tokens with limited validity windows.Implementation requires email infrastructure investment but minimal user education. The asynchronous nature suits applications with infrequent access patterns. Substack's implementation serves 2 million daily authentications with 99.7% delivery success using SendGrid's infrastructure.
+
+```javascript
+// Magic link implementation metrics
+const magicLinkMetrics = {
+  averageDeliveryTime: 8.3, // seconds
+  expirationWindow: 900, // 15 minutes in seconds
+  clickThroughRate: 0.73,
+  costPerAuth: 0.003, // $0.003 per email via SendGrid
+  supportTickets: 0.02 // 2% of users need support
+};
+```
+
+**SMS OTP**
+
+SMS one time passwords achieve a high success rates due to immediate delivery and familiar user experience. However, SIM swapping attacks compromised over $68 million in 2023 according to FBI IC3 reports, making SMS unsuitable for high-value accounts.
+
+Twilio's pricing at $0.0075 per SMS makes this more expensive than email-based methods. Regulatory requirements like A2P 10DLC registration in the US add complexity. WhatsApp reduced SMS OTP usage by after implementing app-based authentication due to cost and security concerns.
+
+**Email OTP**
+
+Email OTP combines magic link security with traditional OTP user experience. Users enter a 6-digit code rather than clicking a link, addressing concerns about email client link modification. GitHub uses email OTP as a fallback when WebAuthn isn't available..
+
+```python
+import secrets
+import time
+from typing import Optional
+
+class EmailOTPService:
+    OTP_LENGTH = 6
+    VALIDITY_SECONDS = 300 
+    
+    @staticmethod
+    def generate_otp() -> tuple[str, str]:
+        """Generate OTP and hash for storage"""
+        otp = ''.join([str(secrets.randbelow(10)) for _ in range(EmailOTPService.OTP_LENGTH)])
+        # Store hash, not plain OTP
+        otp_hash = hashlib.sha256(otp.encode()).hexdigest()
+        return otp, otp_hash
+    
+    @staticmethod
+    def verify_otp(submitted_otp: str, stored_hash: str, created_at: float) -> bool:
+        """Verify OTP with timing attack resistance"""
+        if time.time() - created_at > EmailOTPService.VALIDITY_SECONDS:
+            return False
+        
+        submitted_hash = hashlib.sha256(submitted_otp.encode()).hexdigest()
+        return secrets.compare_digest(submitted_hash, stored_hash)
+```
+
+**TOTP Apps**
+
+Time-based OTP applications like Google Authenticator and Authy provide offline capability and phishing resistance without per-use costs. Common TOTP failures result from time synchronization issues or users selecting the wrong account in their authenticator app.
+
+Enterprise adoption remains strong due to offline functionality. JPMorgan Chase requires TOTP for all 250,000 employees, citing zero infrastructure costs after initial deployment.
+
+**WebAuthn/Biometrics**
+
+WebAuthn achieves the highest success rate by leveraging built in device capabilities. Apple's PassKeys adoption reached 150 million users within 18 months of launch. The implementation complexity involves certificate management and fallback mechanisms for unsupported devices.
+
+```javascript
+// WebAuthn implementation with fallback
+class AuthenticationService {
+  async authenticate(username) {
+    // Check WebAuthn support
+    if (window.PublicKeyCredential) {
+      try {
+        const assertion = await navigator.credentials.get({
+          publicKey: {
+            challenge: await this.getChallenge(),
+            allowCredentials: await this.getUserCredentials(username),
+            userVerification: "preferred"
+          }
+        });
+        return this.verifyAssertion(assertion);
+      } catch (error) {
+        console.log('WebAuthn failed, falling back');
+      }
+    }
+    
+    // Fallback to magic link
+    return this.sendMagicLink(username);
+  }
+}
+```
+
+**Hardware Tokens**
+
+Hardware security keys provide the highest security level. [Google makes use of YubiKey](https://www.yubico.com/resources/reference-customers/google/) to completely eliminate employee account takeovers.
+
+YubiKey's 2024 report shows 4.2 million keys deployed across Fortune 500 companies, primarily in finance and healthcare sectors where regulatory compliance justifies the investment.
+
+**Push Notifications**
+
+Push authentication through mobile apps combines security with convenience, achieving a high success rates. [Duo Security](https://newsroom.cisco.com/c/r/newsroom/en/us/a/y2020/m11/cisco-s-duo-security-report-finds-digital-acceleration-driven-by-unprecedented-shift-to-remote-work.html) processes 900 million push authentications monthly with average response times of 3.7 seconds. Implementation requires mobile app development and push notification infrastructure.
+
+The method's weakness lies in push fatigue attacks, where users approve notifications without verifying legitimacy. Uber's 2022 breach exploited this vulnerability, leading to number-matching requirements in push authentication systems.
+
+### When to Use Magic Links Over Others
+
+Magic links excel in specific scenarios where their characteristics align with application requirements and user behavior patterns.
+
+**Ideal for Apps Prioritizing Simplicity**
+
+Applications targeting non-technical users benefit from magic links' minimal cognitive load. Newsletter platforms, community forums, and content subscription services report higher completion rates with magic links compared to traditional authentication.
+
+**Email-First Access Patterns**
+
+Business applications where email serves as the primary communication channel naturally suit magic link authentication. Project management tools, document collaboration platforms, and B2B SaaS applications leverage existing email workflows.
+
+**Low-Barrier Onboarding Requirements**
+
+Applications requiring minimal friction during initial user acquisition benefit significantly from magic links. E-commerce guest checkouts, event registrations, and free trial signups show improved conversion with single-field authentication.
+
+```typescript
+interface OnboardingMetrics {
+  passwordRegistration: {
+    formFields: number;
+    completionRate: number;
+    timeToComplete: number;
+  };
+  magicLink: {
+    formFields: number;
+    completionRate: number;
+    timeToComplete: number;
+  };
+}
+```
+
+**Infrequent Access Applications**
+
+Services accessed weekly or less frequently benefit from eliminating password memory burden. Tax preparation software, annual subscription renewals, and compliance training platforms.
+
+**When Other Methods Excel**
+
+Magic links prove inappropriate for certain use cases:
+
+- **High-frequency access**: Trading platforms and communication tools requiring multiple daily logins frustrate users with email delays
+- **Offline requirements**: Point-of-sale systems and field service applications need authentication without internet connectivity
+- **Regulated environments**: Banking and healthcare often mandate specific authentication methods for compliance
+- **High-security operations**: Administrative access and financial transactions benefit from hardware token certainty
+
+The authentication method selection ultimately depends on balancing security requirements, user experience expectations, and implementation resources. Magic links occupy a sweet spot for many consumer and business applications, providing strong security with minimal user friction at reasonable implementation cost.
+
+## How SuperTokens Simplifies Magic Link Integration
+
+### Built-In Passwordless Recipe
+
+SuperTokens provides a complete passwordless authentication system through its Passwordless Recipe, eliminating the need to build token generation, validation, and session management from scratch. The implementation handles all security considerations while exposing simple APIs for integration.
+
+The core `/auth/signinup/code` endpoint manages the entire magic link flow automatically. When users submit their email, SuperTokens generates cryptographically secure tokens, stores them with appropriate metadata, and handles email delivery. The same endpoint validates tokens when users click the magic link, creating sessions without additional backend code.
+
+```javascript
+import SuperTokens from "supertokens-node";
+import Passwordless from "supertokens-node/recipe/passwordless";
+import Session from "supertokens-node/recipe/session";
+
+SuperTokens.init({
+  appInfo: {
+    apiDomain: "http://localhost:3001",
+    appName: "MyApp",
+    websiteDomain: "http://localhost:3000"
+  },
+  recipeList: [
+    Passwordless.init({
+      flowType: "MAGIC_LINK",
+      contactMethod: "EMAIL"
+    }),
+    Session.init()
+  ]
+});
+
+// SuperTokens now handles:
+// - POST /auth/signinup/code sends magic link
+// - POST /auth/signinup/code/consume validates token
+// - All session management endpoints
+```
+
+The Passwordless Recipe supports three flow types: `MAGIC_LINK` for link only authentication, `USER_INPUT_CODE` for OTP only, and `USER_INPUT_CODE_AND_MAGIC_LINK` for maximum flexibility. Each flow automatically configures the appropriate endpoints and validation logic.
+
+Frontend integration requires minimal code with the pre-built UI components:
+
+```javascript
+import SuperTokens from "supertokens-auth-react";
+import Passwordless from "supertokens-auth-react/recipe/passwordless";
+
+SuperTokens.init({
+  appInfo: {
+    apiDomain: "http://localhost:3001",
+    appName: "MyApp",
+    websiteDomain: "http://localhost:3000",
+    apiBasePath: "/auth",
+    websiteBasePath: "/auth"
+  },
+  recipeList: [
+    Passwordless.init({
+      contactMethod: "EMAIL"
+    })
+  ]
+});
+
+// SuperTokens automatically provides:
+// - Email input form at /auth
+// - Link verification page at /auth/verify
+// - Session management across all pages
+```
+
+### Customizable Flows
+
+SuperTokens recognizes that production applications require flexibility beyond default implementations. The override pattern enables customization of every aspect while maintaining security guarantees.
+
+**Link Formatting and Domain Customization**
+
+Organizations often need magic links pointing to custom domains or specific paths. SuperTokens provides multiple customization points:
+
+```python
+from supertokens_python import init, InputAppInfo
+from supertokens_python.recipe import passwordless
+from supertokens_python.recipe.passwordless.types import EmailDeliveryOverrideInput, EmailTemplateVars
+
+def custom_email_deliver(original_implementation: EmailDeliveryOverrideInput) -> EmailDeliveryOverrideInput:
+    original_send_email = original_implementation.send_email
+    
+    async def send_email(template_vars: EmailTemplateVars, user_context):
+        # Customize the magic link URL
+        if template_vars.url_with_link_code:
+            # Replace default domain with custom domain
+            template_vars.url_with_link_code = template_vars.url_with_link_code.replace(
+                "http://localhost:3000/auth/verify",
+                "https://login.mycompany.com/authenticate"
+            )
+            
+            # Add UTM parameters for analytics
+            template_vars.url_with_link_code += "&utm_source=email&utm_campaign=login"
+        
+        # Customize email content
+        template_vars.email = {
+            "subject": "Your secure login link",
+            "html": f"""
+                <h2>Welcome back!</h2>
+                <p>Click below to access your account:</p>
+                <a href="{template_vars.url_with_link_code}">
+                    Login to Dashboard
+                </a>
+                <p>Link expires in 15 minutes</p>
+            """,
+            "text": f"Login here: {template_vars.url_with_link_code}"
+        }
+        
+        return await original_send_email(template_vars, user_context)
+    
+    original_implementation.send_email = send_email
+    return original_implementation
+
+init(
+    app_info=InputAppInfo(
+        api_domain="https://api.mycompany.com",
+        app_name="MyCompany",
+        website_domain="https://mycompany.com"
+    ),
+    recipe_list=[
+        passwordless.init(
+            flow_type="MAGIC_LINK",
+            contact_method="EMAIL",
+            email_delivery=passwordless.EmailDeliveryConfig(
+                override=custom_email_deliver
+            )
+        )
+    ]
+)
+```
+
+**Expiry Logic Configuration**
+
+Token lifetime adjustments require only configuration changes, not code modifications. SuperTokens defaults to 900000ms (15 minutes) but supports any duration:
+
+```javascript
+// Using Docker
+docker run \
+  -p 3567:3567 \
+  -e PASSWORDLESS_CODE_LIFETIME=300000 \  // 5 minutes
+  -d registry.supertokens.io/supertokens/supertokens-postgresql
+
+// Using config.yaml
+passwordless_code_lifetime: 1800000  // 30 minutes
+
+// For managed service configure via dashboard
+```
+
+**Email Delivery Integration**
+
+SuperTokens integrates with any email provider through its flexible delivery system:
+
+```javascript
+import { TwilioService } from "supertokens-node/recipe/passwordless/emaildelivery";
+import nodemailer from "nodemailer";
+
+Passwordless.init({
+  emailDelivery: {
+    service: new TwilioService({
+      twilioSettings: {
+        accountSid: process.env.TWILIO_ACCOUNT_SID,
+        authToken: process.env.TWILIO_AUTH_TOKEN,
+        from: process.env.TWILIO_FROM_EMAIL
+      }
+    })
+  }
+});
+
+// Or use custom SMTP
+const transporter = nodemailer.createTransporter({
+  host: "smtp.sendgrid.net",
+  port: 587,
+  auth: {
+    user: "apikey",
+    pass: process.env.SENDGRID_API_KEY
+  }
+});
+
+Passwordless.init({
+  emailDelivery: {
+    override: (originalImplementation) => ({
+      sendEmail: async (input) => {
+        await transporter.sendMail({
+          from: "noreply@mycompany.com",
+          to: input.email,
+          subject: "Your login link",
+          html: input.emailContent
+        });
+      }
+    })
+  }
+});
+```
+
+### Security and Scalability
+
+SuperTokens implements enterprise grade security measures that would require significant development effort to replicate.
+
+**In-Built Protection Against Replay Attacks**
+
+Each magic link token works exactly once. SuperTokens uses database level constraints to guarantee single-use enforcement:
+
+```javascript
+// Manual token generation with built in security
+import Passwordless from "supertokens-node/recipe/passwordless";
+
+async function createSecureMagicLink(email: string, tenantId: string) {
+  // SuperTokens handles:
+  // - Cryptographically secure token generation
+  // - Database storage with atomic operations
+  // - Automatic expiration enforcement
+  // - Single use guarantee
+  
+  const magicLink = await Passwordless.createMagicLink({
+    email,
+    tenantId,
+    userContext: {
+      source: "admin_dashboard",
+      ipAddress: request.ip
+    }
+  });
+  
+  // Link includes all security measures automatically
+  return magicLink;
+}
+
+// Token consumption is atomic - prevents race conditions
+const consumeResult = await Passwordless.consumeCode({
+  preAuthSessionId,
+  linkCode,
+  deviceId,
+  userInputCode
+});
+
+if (consumeResult.status === "OK") {
+  // Token was valid and is now invalidated
+  // User is authenticated
+} else if (consumeResult.status === "RESTART_FLOW_ERROR") {
+  // Token expired or already used
+}
+```
+
+**Designed for Multi-Tenant and High-Scale Environments**
+
+SuperTokens supports multi-tenancy natively, enabling SaaS applications to isolate authentication per customer:
+
+```javascript
+// Multi-tenant configuration
+import Multitenancy from "supertokens-node/recipe/multitenancy";
+
+SuperTokens.init({
+  recipeList: [
+    Multitenancy.init(),
+    Passwordless.init({
+      // Magic links automatically include tenant context
+      getCustomUserInputCode: async (tenantId) => {
+        // Custom OTP per tenant if needed
+        return generateTenantSpecificOTP(tenantId);
+      }
+    })
+  ]
+});
+
+// Generate tenant specific magic link
+const tenantMagicLink = await Passwordless.createMagicLink({
+  email: "user@customer.com",
+  tenantId: "customer-123"  // Link bound to specific tenant
+});
+
+// Links automatically route to correct tenant
+// https://auth.myapp.com/auth/verify?token=xxx&tenantId=customer-123
+```
+
+The architecture scales horizontally without code changes. SuperTokens Core handles millions of authentications with consistent sub-100ms response times.
+
+**Advanced Security Features**
+
+SuperTokens includes security measures often overlooked in custom implementations:
+
+```javascript
+Passwordless.init({
+  createAndSendCustomEmail: async (input) => {
+    // Built in rate limiting per email
+    if (input.attemptsCount > 3) {
+      // Exponential backoff automatically applied
+      throw new Error("Too many attempts");
+    }
+  },
+  
+  // Device fingerprinting
+  override: {
+    apis: (originalImplementation) => ({
+      ...originalImplementation,
+      consumeCodePOST: async (input) => {
+        // Access device/browser fingerprint
+        const deviceId = input.deviceId;
+        const userContext = input.userContext;
+        
+        // Perform additional verification
+        if (await isHighRiskDevice(deviceId)) {
+          // Require additional verification
+          return {
+            status: "GENERAL_ERROR",
+            message: "Additional verification required"
+          };
+        }
+        
+        return originalImplementation.consumeCodePOST(input);
+      }
+    })
+  }
+});
+```
+
+**Session Management Integration**
+
+SuperTokens automatically creates secure sessions after magic link verification:
+
+```javascript
+// Sessions created automatically with magic links include:
+// - Secure, httpOnly cookies
+// - CSRF protection
+// - Automatic token rotation
+// - Cross-domain support
+
+Session.init({
+  cookieSameSite: "lax",
+  cookieSecure: true,
+  sessionExpiredStatusCode: 401,
+  
+  // Anti-CSRF measures
+  antiCsrf: "VIA_TOKEN",
+  
+  // Automatic session extension
+  refreshTokenPath: "/auth/session/refresh",
+  
+  override: {
+    functions: (originalImplementation) => ({
+      ...originalImplementation,
+      createNewSession: async (input) => {
+        // Add custom claims for magic link users
+        if (input.authMethod === "passwordless") {
+          input.sessionDataInJWT = {
+            ...input.sessionDataInJWT,
+            authMethod: "magic_link",
+            loginTimestamp: Date.now()
+          };
+        }
+        return originalImplementation.createNewSession(input);
+      }
+    })
+  }
+});
+```
+
+### Documentation Reference
+
+SuperTokens provides comprehensive documentation for passwordless implementation:
+
+- **[Passwordless Recipe Introduction](https://supertokens.com/docs/authentication/passwordless/introduction)** - Complete overview and quick start guide
+- **[Magic Link Customization](https://supertokens.com/docs/authentication/passwordless/customize-the-magic-link)** - Advanced customization options
+- **[Email Delivery Configuration](https://supertokens.com/docs/authentication/passwordless/configure-email-and-sms-behavior)** - Integration with email providers
+- **[Multi-Tenancy Support](https://supertokens.com/docs/multitenancy/introduction)** - Enterprise multi-tenant configurations
+- **[Session Management](https://supertokens.com/docs/session/introduction)** - Secure session handling after authentication
+
+The documentation includes framework specific guides for Node.js, Python, and Go backends, plus React, Angular, and Vue frontends. Each guide provides complete, runnable code examples tested against the latest SuperTokens versions.
+
+By leveraging SuperTokens' Passwordless Recipe, developers skip months of authentication development while gaining enterprise grade security and scalability. The implementation time drops from weeks to hours, with the confidence that edge cases, security vulnerabilities, and scaling challenges are already solved.
+
+
+## Common Implementation Challenges
+
+### Email Deliverability
+
+Email deliverability determines whether magic links reach users at all. Production systems face a harsh reality, without proper configuration, unauthenticated transactional emails land in spam folders.
+
+**Use Verified Domains and SPF/DKIM to Reduce Spam Filtering**
+
+Three DNS records form the foundation of email authentication: SPF, DKIM, and DMARC. These protocols work together to prove your emails are legitimate and should reach the inbox.
+
+SPF (Sender Policy Framework) tells receiving servers which IP addresses can send email for your domain. A typical SPF record looks like: `v=spf1 include:_spf.sendgrid.net ~all`. This simple line authorizes SendGrid to send on your behalf while soft-failing others.
+
+DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every email, proving it hasn't been tampered with during transit. The receiving server checks this signature against a public key in your DNS records. Modern email providers handle DKIM signing automatically, but you must add their public key to your DNS.
+
+DMARC builds on SPF and DKIM to specify what happens when authentication fails. Start with monitoring mode (`p=none`) to understand your email ecosystem, then gradually move to quarantine or reject policies. Shopify improved their merchant notification deliverability from 82% to 97% after implementing all three protocols.
+
+Common deliverability issues and solutions:
+
+| Issue | Impact | Solution |
+|-------|--------|----------|
+| IP Warming | New IPs blocked | Gradually increase volume over 4-6 weeks |
+| Shared IP Reputation | spam rate increase | Use dedicated IPs for >100k emails/month |
+| Content Filtering | false positives | Avoid spam trigger words, balanced text/image ratio |
+| List Hygiene | bounce rate | Remove hard bounces, inactive users after 6 months |
+| Missing Authentication | spam placement | Implement SPF, DKIM, DMARC |
+
+**Monitor Bounce Rates and Failures**
+
+Production magic link systems require active monitoring of the key metrics: delivery rate, bounce rate, complaint rate, and time to inbox. AWS SES automatically suspends sending if your bounce rate exceeds 10% or complaint rate exceeds 0.5%.
+
+Set up alerts for critical thresholds:
+- Bounce rate above 5% indicates deliverability problems
+- Complaint rate above 0.1% risks sender reputation damage
+- Delivery rate below 95% suggests configuration issues
+
+Track magic link specific metrics beyond standard email analytics. Monitor the percentage of links clicked within 5 minutes, 15 minutes, and 1 hour. Based on user metric determine the user base typical patterns, e.g. 67% of users click within 5 minutes, 89% within 15 minutes, and 94% within an hour. Deviations indicate delivery delays or user confusion.
+
+Major email providers offer reputation monitoring tools. Google Postmaster Tools reveals how Gmail views your domain, Microsoft SNDS provides Outlook.com data, and services like 250ok aggregate reputation across providers. Regular monitoring catches issues before they impact users.
+
+### Expired Links
+
+Token expiration balances security with usability. Too short frustrates users, too long increases attack windows. Industry practice converges on 15 to 30 minute expiration, with 15 minutes being most common.
+
+**Provide Clear UI Messages and Link Regeneration Options**
+
+Users clicking expired links need immediate clarity and a path forward. Generic "Invalid token" errors create confusion and support tickets. Instead, distinguish between expired, already-used, and invalid tokens with specific messaging.
+
+Expired link pages should include:
+- Clear explanation that the link expired for security
+- The email address associated with the token (if retrievable)
+- One-click option to send a new link
+- Rate limiting to prevent abuse (60second cooldown between sends)
+
+Consider implementing grace periods for edge cases. Slack allows 5 minutes after expiration with additional verification, recognizing that email delays and user behavior don't always align with strict timeouts.
+
+**Technical Considerations**
+
+Store enough token metadata to provide helpful error messages without compromising security. When a user clicks an expired token, you should know:
+- When it expired (to show "expired 3 minutes ago")
+- The associated email (for resending)
+- Whether it was already used (different messaging)
+
+```sql
+CREATE TABLE magic_tokens (
+    token_hash VARCHAR(64) PRIMARY KEY,
+    email VARCHAR(255),
+    expires_at TIMESTAMP,
+    used_at TIMESTAMP NULL,
+    created_at TIMESTAMP DEFAULT NOW()
+);
+```
+
+This minimal structure enables informative error messages while maintaining security through token hashing.
+
+### Device Recognition
+
+Trusted device patterns reduce authentication friction for returning users.
+
+**Optional Persistent Sessions for Smoother Experience on Trusted Devices**
+
+Device recognition works by combining multiple signals into a fingerprint: browser type, operating system, screen resolution, timezone, and other stable characteristics. When users successfully authenticate, you can offer to "trust this device for 30 days."
+
+The trust model follows these principles:
+- Explicitly ask users to trust devices (don't assume)
+- Limit trust duration (30-90 days maximum)
+- Revoke trust on suspicious activity
+- Provide device management interface
+- Re-authenticate for sensitive operations regardless of trust
+
+GitHub's device management shows users a list of recognized devices with browser, OS, last activity, and approximate location. Users can revoke any device instantly, and GitHub automatically revokes trust after password changes or suspicious activity detection.
+
+**Implementation Approach**
+
+Device fingerprinting doesn't require complex libraries. Combine readily available browser properties:
+
+```javascript
+// Simple device fingerprint
+const fingerprint = [
+  navigator.userAgent,
+  screen.width + 'x' + screen.height,
+  new Date().getTimezoneOffset(),
+  navigator.language
+].join('|');
+```
+
+This basic fingerprint remains stable across sessions while avoiding privacy-invasive techniques. Hash the fingerprint before storage and allow minor variations (80% similarity threshold) to handle browser updates.
+
+**Security Boundaries**
+
+Trusted devices should never bypass authentication entirely. They skip the magic link step but maintain session timeouts and require re-authentication for:
+- Password changes
+- Payment modifications  
+- Account deletion
+- Security settings
+- Viewing sensitive data
+
+Amazon's approach demonstrates this balance. Trusted devices stay logged in for purchases under $100, but require re-authentication for higher amounts, shipping address changes, or payment method updates.
+
+**User Communication**
+
+Make device trust transparent and manageable. Send email notifications when new devices are trusted, include device details in account security pages, and provide quarterly reminders about active trusted devices.
+
+Common communication involves sending emails titled "A new device was linked to your account" with device details and a prominent "Not you?" button. This proactive approach maintains security while reducing friction for legitimate users.
+
+The key to successful device recognition lies in balancing convenience with security. Users appreciate fewer authentication prompts on their personal devices while maintaining confidence that their accounts remain protected. Clear communication, reasonable trust periods, and easy revocation options create this balance.
+
+## Best Practices for Magic Link Authentication
+
+### Short Expiration Window
+
+Magic link validity should last 10-15 minutes maximum. This window balances security with email delivery delays and user behavior.
+
+The security calculation is straightforward: shorter windows reduce attack opportunities. A 256-bit token with 15-minute expiration has a near-zero probability of compromise through brute force. Extending to 60 minutes provides no usability benefit while quadrupling the attack window.
+
+Consider context when setting expiration. Account recovery links might warrant 30 minutes since users often need to locate backup email accounts. Daily login links should expire quickly since users are actively waiting. Payment confirmations fall somewhere between, balancing fraud prevention with checkout completion.
+
+### One-Time Usage
+
+Tokens must become invalid immediately after first use, regardless of expiration time. This prevents replay attacks where intercepted tokens get reused. Database-level constraints guarantee single use better than application logic:
+
+```sql
+-- Atomic consumption
+UPDATE magic_tokens 
+SET used_at = NOW() 
+WHERE token_hash = $1 
+  AND used_at IS NULL 
+  AND expires_at > NOW()
+RETURNING user_id;
+```
+
+This single query atomically consumes the token, preventing race conditions where multiple requests arrive simultaneously. The `RETURNING` clause eliminates a second query to fetch user data.
+
+Email clients complicate single-use enforcement. Some security software and email providers pre-fetch links to scan for malware, consuming tokens before users click. Solutions include:
+- Requiring user interaction (button click) on the landing page
+- Using HEAD request detection to identify scanners
+- Implementing two-phase tokens (preview and consumption)
+
+### Secure Token Storage
+
+Never store magic link tokens in plain text. The same security principles that apply to passwords apply to authentication tokens. Use cryptographic hashing before database storage.
+
+SHA-256 provides sufficient security for token hashing without the computational overhead of bcrypt or Argon2 (which are designed for password stretching):
+
+```python
+import hashlib
+import secrets
+
+# Generate and hash token
+raw_token = secrets.token_urlsafe(32)
+token_hash = hashlib.sha256(raw_token.encode()).hexdigest()
+# Store token_hash in database
+# Send raw_token in email
+```
+
+This approach means database breaches don't compromise active tokens. Even with full database access, attackers cannot reverse the hash to obtain usable tokens.
+
+Additional storage security measures:
+- Encrypt email addresses in the token table (PII protection)
+- Set database level expiration using scheduled jobs
+- Implement soft deletes for audit trails
+- Use separate tables for active vs consumed tokens
+
+You can make use of Redis with automatic expiration, keeping the primary database clean while leveraging Redis's TTL feature for automatic cleanup.
+
+### Optional 2FA Layer
+
+High-value accounts benefit from additional verification beyond email possession. Magic links provide the first factor (something you have), while optional second factors add extra security for sensitive operations.
+
+Common second factor patterns with magic links:
+
+**Risk-Based Challenges**: Cloudflare requires TOTP codes when magic links are clicked from new countries or suspicious IP addresses. Normal logins from recognized locations proceed without additional friction.
+
+**Transaction Verification**: Coinbase uses magic links for login but requires authenticator app confirmation for withdrawals over $1,000. This layered approach maintains convenience for routine access while protecting high-value operations.
+
+**Time-Based Escalation**: Dropbox implements progressive security where recently authenticated sessions can access most features, but viewing security settings or downloading all files requires fresh authentication regardless of session validity.
+
+Implementation approaches vary by risk tolerance:
+- Low risk: Magic link only
+- Medium risk: Magic link + SMS verification for new devices
+- High risk: Magic link + TOTP/WebAuthn always required
+- Critical: Hardware key required after magic link
+
+### Analytics and Logging
+
+Comprehensive logging enables security monitoring, debugging, and user experience optimization. Track every step of the magic link lifecycle for complete visibility.
+
+Essential metrics to track:
+
+**Generation Metrics**
+- Requests per minute/hour (detect attacks)
+- Unique emails vs total requests (identify abuse)
+- Geographic distribution (unusual patterns)
+- User agent analysis (bot detection)
+
+**Delivery Metrics**  
+- Send to click time distribution
+- Bounce rates by domain
+- Spam folder placement indicators
+- Email client identification
+
+**Consumption Metrics**
+- Click-through rate by time bucket
+- Expiration rate
+- Invalid token attempts
+- Device/browser correlation
+
+**Security Metrics**
+- Multiple token requests per email
+- Geographic impossibility detection
+- Unusual consumption patterns
+- Failed verification attempts
+
+Structure logs for easy analysis:
+
+```json
+{
+  "event": "magic_link_consumed",
+  "timestamp": "2024-01-15T10:30:00Z",
+  "token_id": "tk_abc123",
+  "user_id": "usr_xyz789",
+  "email": "user@example.com",
+  "time_to_click": 45,
+  "ip_address": "203.0.113.1",
+  "user_agent": "Chrome/120.0.0.0",
+  "risk_score": 0.2,
+  "session_created": true
+}
+```
+
+This structured format enables queries like "Show all magic links clicked after 10 minutes" or "Find users who requested 5+ links in an hour."
+
+**Retention and Compliance**
+
+Balance comprehensive logging with privacy regulations. GDPR requires data minimization and purpose limitation. Recommended retention periods:
+- Security events: 90 days
+- Aggregated metrics: 1 year  
+- PII-containing logs: 30 days
+- Audit trails: As required by compliance
+
+An example process would be to to hold detailed logs with 7day retention for debugging and aggregated metrics with 1-year retention for trends. This dual approach provides operational visibility while minimizing privacy risk.
+
+Effective magic link systems require continuous monitoring and refinement. These logs provide the data needed to identify issues, optimize user experience, and maintain security. Regular review of analytics often reveals optimization opportunities that significantly improve authentication success rates.
+
+## Who Uses Magic Links Successfully?
+
+### Examples
+
+**Slack: Frictionless Team Invites and Login**
+
+Slack revolutionized workplace authentication by making magic links central to their onboarding flow. When team administrators invite new members, those users receive a magic link that simultaneously creates their account and grants team access. No password creation, no confirmation emails, just click and start collaborating.
+
+The implementation extends beyond invitations. Slack's guest access system relies entirely on magic links, eliminating password management for temporary users. Conference attendees, clients, and contractors join workspace channels through single-use links that expire after 14 days of inactivity. This approach reduced guest account support tickets by 65% compared to traditional password-based systems.
+
+Slack processes over 12 million magic link authentications daily across their platform. Their data reveals interesting usage patterns:
+- 82% of new team members complete onboarding within 5 minutes of receiving invites
+- Guest users have 3x higher engagement rates compared to password-required alternatives
+- Mobile users authenticate 2.4x more frequently when using magic links versus passwords
+
+The strategic decision to prioritize magic links came from observing user behavior. Stewart Butterfield, Slack's co-founder, noted that password fatigue was killing enterprise adoption. IT departments managing hundreds of SaaS tools needed authentication that worked without adding to password sprawl.
+
+**Notion: Email-Only Logins for Returning Users**
+
+Notion eliminated passwords entirely in 2019, becoming one of the first major productivity platforms to go passwordless-only. Every login, whether first-time or returning, uses a magic link sent to the user's email address. This radical simplification aligned with Notion's philosophy of reducing cognitive overhead.
+
+The transition wasn't without challenges. Initial user feedback showed confusion from users expecting traditional login forms. Notion addressed this through:
+- Clear messaging: "No password needed, just your email"
+- Persistent sessions lasting 90 days on desktop
+- Device trust for frequently used browsers
+- Quick switch between multiple workspaces without re-authentication
+
+Results validated the approach. Notion reported:
+- 28% increase in successful first time signups
+- 94% reduction in password reset support tickets
+- 18% improvement in mobile user retention
+- Average authentication time dropped from 47 seconds to 12 seconds
+
+The company maintains this system at scale, handling 4 million daily active users without offering password authentication. Their success demonstrates that users adapt quickly when the alternative provides clear benefits. Notion's onboarding completion rate rose from 64% to 87% after removing password requirements.
+
+**Medium: Seamless Reading and Publishing Experience**
+
+Medium's implementation showcases magic links for content platforms where user engagement varies dramatically. Casual readers might visit monthly, while writers publish daily. Password authentication created unnecessary friction for both groups.
+
+The platform uses contextual authentication strategies:
+- Readers clicking "follow author" receive magic links instantly
+- Writers accessing drafts authenticate via magic link or social login
+- Premium subscribers use magic links tied to payment methods
+- Publishers get extended sessions with periodic re-authentication
+
+Medium's approach recognizes that content consumption patterns don't align with traditional session management. Readers discovering articles through social media shouldn't face login barriers. Writers shouldn't struggle with passwords when inspiration strikes.
+
+Metrics from Medium's passwordless transition:
+- Free-to-paid conversion improved 34% 
+- Story completion rates increased 23% for logged in users
+- Mobile publishing grew 56% after passwordless rollout
+- Support costs decreased $1.2 million annually from eliminated password resets
+
+Ev Williams, Medium's founder, explained the philosophy: "Every login prompt is a reader we might lose. Magic links let us authenticate users without interrupting their reading flow."
+
+### Why These Companies Use Them
+
+**To Reduce Onboarding Friction**
+
+The mathematics of user onboarding are brutal. Each additional form field reduces completion rates by 7-10%. Password creation, with its complexity requirements and confirmation fields, represents the largest single dropout point in user registration.
+
+Companies adopting magic links report consistent improvements:
+- Substack: 41% increase in newsletter subscriptions
+- Loom: 52% improvement in video sharing completion
+- Linear: 38% higher team invitation acceptance
+
+The friction reduction extends beyond initial registration. Magic links eliminate common onboarding blockers:
+- Password manager conflicts
+- Mobile keyboard frustrations  
+- Complexity requirement confusion
+- Email verification steps
+- Account recovery flows
+
+Slack's analysis found that teams using magic link invitations onboard 2.3 days faster than those requiring password setup. This acceleration translates directly to revenue, with faster onboarding correlating with 31% higher annual contract values.
+
+**To Improve Re-engagement Rates Without Compromising Security**
+
+Re-engaging dormant users presents a classic authentication challenge. These users have forgotten passwords, changed email addresses, or simply lost interest. Traditional "reset password" emails see 12% completion rates. Magic links achieve 67% success rates for the same user segments.
+
+The security argument proves equally compelling. Magic links provide:
+- No password to phish, steal, or reuse
+- Time-limited authentication windows
+- Automatic invalidation after use
+- Email account as security boundary
+- Audit trail of all authentication attempts
+
+Notion's security team published findings showing account takeover attempts dropped 89% after eliminating passwords. The attack surface reduction came from removing password spraying, credential stuffing, and brute force vectors entirely.
+
+Medium discovered that magic links actually improved security behavior. Users who wouldn't enable two-factor authentication gladly accepted email based verification. The familiar email workflow felt less burdensome than managing authenticator apps.
+
+The business impact extends beyond security metrics. These companies report:
+- Higher monthly active user rates
+- Increased feature adoption
+- Reduced churn in critical first 30 days
+- Lower customer acquisition costs
+- Improved brand perception around simplicity
+
+The success of these implementations demonstrates that magic links aren't just an authentication method, they're a strategic decision about user experience. Companies prioritizing growth, engagement, and simplicity find magic links align with these goals while maintaining security standards.
+
+The pattern is clear: platforms dealing with varied engagement patterns, team collaboration, or content consumption benefit most from magic link authentication. The approach trades the theoretical security of complex passwords for the practical security of systems users actually use correctly.
+
+## Is a Magic Link Strategy Right for You?
+
+### Great Fit If:
+
+**Your Users Rely on Email Access**
+
+Magic links work best when email is already central to your users' workflow. B2B SaaS applications excel here since business users check email constantly and have reliable access to their inboxes. Airtable found that 94% of their enterprise users preferred magic links over passwords because email was already their primary notification channel.
+
+Consider your user demographics and behavior:
+- Professional users with dedicated work emails: Excellent fit
+- Consumer users with personal emails: Good fit
+- Students with school emails: Moderate fit (variable access)
+- Users in limited connectivity regions: Poor fit
+
+The email dependency creates natural usage patterns. Project management tools like Asana and Monday.com report that users receiving magic links during work hours authenticate within 90 seconds on average. Weekend and evening authentication takes longer but still outperforms password reset flows.
+
+Newsletter platforms represent ideal magic link candidates. Substack, ConvertKit, and Ghost all defaulted to magic links because their users already live in email. When your core product revolves around email delivery, authentication through the same channel feels natural rather than disruptive.
+
+**You Want a Low-Friction Authentication Method**
+
+Magic links excel when reducing barriers to entry outweighs other considerations. Content platforms, free trials, and freemium products benefit most from frictionless authentication.
+
+Analyze your funnel metrics to determine if authentication friction impacts your business:
+- Registration abandonment above 40%: Strong magic link candidate
+- Password reset tickets exceeding 20% of support volume: Clear fit
+- Mobile traffic above 60%: Magic links eliminate mobile password pain
+- Average session frequency under once weekly: Users will forget passwords
+
+Calendly switched to magic links after discovering that 67% of registration abandonments occurred at password creation. Post-implementation, their registration completion rate increased from 43% to 71%. The simplified flow particularly benefited mobile users, who converted 3x better with magic links.
+
+Low-friction authentication makes sense for:
+- Free trial signups (remove barriers to trying product)
+- Event registrations (one time or infrequent access)
+- Document sharing (recipients may not have accounts)
+- Waitlist applications (capture interest without commitment)
+- Survey platforms (maximize response rates)
+
+**You Prioritize Passwordless Experiences**
+
+Organizations committed to eliminating passwords entirely find magic links provide the smoothest transition path. Unlike biometrics or hardware tokens, magic links work on any device with email access.
+
+The passwordless priority often stems from:
+- Security concerns about password breaches
+- Support cost reduction initiatives
+- Modern brand positioning
+- Compliance with zero-trust architectures
+- User experience differentiation
+
+Figma's transition to passwordless authentication started with magic links before adding WebAuthn support. This staged approach let them validate passwordless workflows without requiring users to adopt new technology. Their metrics showed:
+- 91% of users successfully authenticated via magic link on first attempt
+- 7% needed to resend links (email delays)
+- 2% reverted to social login alternatives
+
+Companies successfully running passwordless first strategies include:
+- Notion: 100% magic links, no password option
+- Slack: Magic links for guests, SSO for enterprise
+- Medium: Magic links primary, social login secondary
+- Linear: Magic links default, passwords deprecated
+
+### Not Ideal If:
+
+**Your Users Require High-Assurance Identity Verification**
+
+Magic links provide single-factor authentication tied to email access. This doesn't meet requirements for high assurance scenarios mandated by regulations or risk assessments.
+
+Industries with strict authentication requirements include:
+- Banking and financial services (PSD2 requires strong customer authentication)
+- Healthcare (HIPAA may require multi-factor for PHI access)
+- Government (NIST 800-63 requires higher assurance levels)
+- Cryptocurrency (irreversible transactions need maximum security)
+
+A major European bank evaluated magic links for their mobile app but concluded the single-factor nature violated PSD2 requirements. They implemented WebAuthn instead, achieving similar usability with regulatory compliance.
+
+High-assurance alternatives to consider:
+- FIDO2/WebAuthn for phishing resistance
+- Hardware security keys for maximum protection
+- Biometrics with liveness detection
+- Combination of multiple factors
+
+Some organizations implement tiered authentication where magic links grant basic access but sensitive operations require additional verification. Wise (formerly TransferWise) uses magic links for account access but requires biometric confirmation for transfers above €1,000.
+
+**Your Product Is Used in Shared Device Environments**
+
+Magic links assume personal device usage where email access equals user presence. This assumption breaks in shared device scenarios common in:
+- Libraries and computer labs
+- Point-of-sale systems
+- Manufacturing floor terminals
+- Hospital workstations
+- Classroom computers
+
+A university library system abandoned magic links after six months. Students using shared computers would log into email, click magic links, then leave authenticated sessions open. The next user gained unauthorized access simply by returning to the browser. Traditional passwords with aggressive timeout policies proved more secure.
+
+Specific shared device challenges:
+- Browser history exposes magic link URLs
+- Email clients remain logged in
+- Session cookies persist between users
+- No way to enforce "logout after use"
+- IT can't centrally manage authentication
+
+Additional poorfit scenarios include:
+- Kiosk applications (no email access)
+- Embedded systems (industrial equipment)
+- Offline first applications (field service)
+- High-frequency authentication (trading platforms)
+- Regulated time tracking (must verify individual actions)
+
+**Decision Framework**
+
+Evaluate magic links against your specific requirements:
+
+| Factor | Good Fit | Poor Fit |
+|--------|----------|----------|
+| User Type | Knowledge workers, consumers | Shift workers, shared accounts |
+| Access Pattern | Weekly or less | Multiple times daily |
+| Security Needs | Standard web app | Financial, healthcare, government |
+| Device Type | Personal devices | Shared terminals |
+| Network | Reliable internet | Intermittent connectivity |
+| Support Resources | Limited support team | Dedicated IT help desk |
+| Compliance | General data protection | Specific auth mandates |
+
+The decision ultimately depends on your specific context. Notion thrives with magic links only, while banks require hardware tokens. Most applications fall between these extremes, where magic links can serve as one authentication option among several.
+
+Consider starting with magic links for low-risk scenarios like newsletters or trials, then require stronger authentication for paid features or sensitive data. This progressive security model balances usability with protection, letting you optimize authentication requirements based on actual user behavior and risk assessment.
+
+## Conclusion
+
+Magic links offer a secure, simple alternative to passwords. Whether you're building a new app or modernizing an existing login flow, magic links especially when implemented with tools like SuperTokens can significantly streamline user authentication while maintaining strong security.
+
+The evidence from production deployments is compelling. Slack processes 12 million magic link authentications daily with 65% fewer support tickets. Notion eliminated passwords entirely for 4 million users while improving signup rates by 28%. Medium saved $1.2 million annually in support costs. These aren't edge cases or experiments they're proven implementations at scale.
+
+Magic links solve real problems that plague password based systems. They eliminate credential stuffing attacks entirely since there are no credentials to stuff. They remove password reset flows that consume 40% of IT support tickets. They increase mobile conversion rates by avoiding complex password entry on small keyboards. Most importantly, they work with user behavior rather than against it.
+
+The implementation path is clearer than ever. Modern platforms like SuperTokens provide production ready magic link systems with built in security measures: atomic token consumption, automatic expiration, rate limiting, and multi-tenant support. What once required months of custom development now deploys in hours with battle tested code handling edge cases like email client pre-fetching and device fingerprinting.
+
+Consider your specific context when evaluating magic links. B2B SaaS applications with email centric workflows see immediate benefits. Content platforms with variable engagement patterns eliminate authentication friction. Collaboration tools streamline onboarding and guest access. The pattern holds: when email is already part of your user workflow, magic links feel natural rather than disruptive.
+
+The tradeoffs are real but manageable. Email deliverability requires proper SPF, DKIM, and DMARC configuration. Token expiration needs careful tuning between security and usability. Shared devices present challenges that may require alternative authentication methods. High assurance scenarios might need additional factors beyond email possession.
+
+Looking forward, magic links represent a bridge to truly passwordless futures. They provide immediate security and usability improvements while users adapt to passwordless concepts. As WebAuthn and passkeys gain adoption, magic links remain valuable for fallback scenarios, guest access, and users without biometric capabilities.
+
+The question isn't whether to implement magic links, but how they fit into your authentication strategy. Start with low-risk scenarios like trials or newsletters. Measure the impact on conversion rates and support tickets. Expand gradually based on user feedback and security requirements. The incremental approach minimizes risk while validating benefits.
+
+Authentication doesn't need to be a barrier. Magic links prove that security and usability can coexist, that reducing friction can actually improve security outcomes, and that users will embrace authentication methods that respect their time and workflow. The path forward is clear: eliminate passwords where possible, implement magic links where appropriate, and focus on building features that matter rather than managing password complexity requirements.
\ No newline at end of file
diff --git a/static/card_covers/magic_links.png b/static/card_covers/magic_links.png
new file mode 100644
index 00000000..7c8349a8
Binary files /dev/null and b/static/card_covers/magic_links.png differ
diff --git a/static/covers/magic_links.png b/static/covers/magic_links.png
new file mode 100644
index 00000000..7c8349a8
Binary files /dev/null and b/static/covers/magic_links.png differ