Passkeys, MFA, Sessions: Modern Authentication Done Right

Quickstart

If you want the fastest security improvement per minute, do these in order. Each item is designed to reduce account takeover risk without turning your login into a support nightmare.

Overview

“Modern authentication” isn’t one feature — it’s a system. Users authenticate once, but attackers probe every edge: sign-up, password reset, “remember me”, OAuth callbacks, and long-lived sessions. This post walks through a practical stack that holds up in production:

Throughout the guide, “done right” means: secure by default, observable (auditable), and predictable under attack. You don’t need a complex identity platform to get these benefits — you need clear rules and consistent implementation.

Core concepts

Before implementation details, you want the right mental model. Most auth bugs happen when a team mixes up authentication (“who are you?”) with sessions (“you already proved it — here’s your ticket”), or when recovery shortcuts bypass the stronger controls.

Authentication vs sessions vs authorization

MFA isn’t one thing: pick the right factors

“MFA” means “more than one factor” — but not all factors are equal. For example, SMS can be better than nothing, but it’s also vulnerable to SIM swaps and social engineering. Prefer phishing-resistant factors when possible.

Session types: cookies, opaque tokens, and JWTs

Sessions come in a few common flavors. The important thing is not the buzzword — it’s whether you can expire, rotate, and revoke them reliably.

Step-by-step

This is a pragmatic build order for “Passkeys, MFA, Sessions: Modern Authentication Done Right”. You can adopt it incrementally: ship a secure baseline, then add passkeys + step-up, then harden recovery and operations.

Step 1 — Define your threat model and “high-risk” actions

Step 2 — Implement passkeys (WebAuthn) as the preferred login

The cleanest roll-out is: keep your existing login, then add a post-login prompt to “Create a passkey”. Once users have a passkey, you can offer “Sign in with passkey” as the default button.

The key rule: WebAuthn needs careful binary encoding/decoding (base64url), and every challenge should be one-time and short-lived. This client snippet shows the shape of a passkey registration call.

/**
 * Browser-side passkey (WebAuthn) registration (shape + safety notes)
 * - Your server must provide options, including a one-time challenge.
 * - Use base64url for binary fields (challenge, user.id, credential IDs).
 */
function b64urlToBytes(b64url) {
  const pad = "=".repeat((4 - (b64url.length % 4)) % 4);
  const b64 = (b64url + pad).replace(/-/g, "+").replace(/_/g, "/");
  const raw = atob(b64);
  return Uint8Array.from([...raw].map((c) => c.charCodeAt(0)));
}

async function createPasskey() {
  // 1) Fetch WebAuthn options from your server
  const opts = await fetch("/webauthn/register/options", { credentials: "include" }).then(r => r.json());

  // 2) Convert base64url fields to ArrayBuffers
  opts.publicKey.challenge = b64urlToBytes(opts.publicKey.challenge);
  opts.publicKey.user.id = b64urlToBytes(opts.publicKey.user.id);

  // 3) Create credential
  const cred = await navigator.credentials.create({ publicKey: opts.publicKey });

  // 4) Send attestation back to server for verification + storage
  await fetch("/webauthn/register/verify", {
    method: "POST",
    credentials: "include",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      id: cred.id,
      rawId: Array.from(new Uint8Array(cred.rawId)),
      type: cred.type,
      response: {
        attestationObject: Array.from(new Uint8Array(cred.response.attestationObject)),
        clientDataJSON: Array.from(new Uint8Array(cred.response.clientDataJSON))
      }
    })
  });
}

Step 3 — Add MFA as “step-up” (and protect sensitive changes)

MFA is most effective when it’s targeted: high-risk sign-ins and high-impact actions. If a user logs in with a passkey (phishing-resistant), you can often reduce prompts while keeping strong security.

Step 4 — Sessions: choose defaults that are safe in the browser

For browser apps, the best default is a server-side session keyed by a cookie that is HttpOnly (not readable by JavaScript), Secure (HTTPS only), and SameSite (reduces CSRF). Rotate session IDs on login and privilege elevation.

Here’s a minimal Express example that sets safe cookie defaults and rotates sessions on login. (You can mirror the same ideas in any framework.)

import express from "express";
import session from "express-session";

const app = express();

// If behind a reverse proxy (common in production), trust it so Secure cookies work correctly.
app.set("trust proxy", 1);

app.use(session({
  name: "__Host-sid",           // __Host- prefix helps enforce safer cookie scope in modern browsers
  secret: process.env.SESSION_SECRET,
  resave: false,
  saveUninitialized: false,
  cookie: {
    httpOnly: true,
    secure: true,               // HTTPS only
    sameSite: "lax",            // mitigate CSRF in most common patterns
    path: "/",
    maxAge: 1000 * 60 * 60 * 8  // 8 hours (adjust to your risk tolerance)
  }
}));

app.post("/login", async (req, res) => {
  // ... verify passkey/password/MFA here ...

  // Prevent session fixation: issue a fresh session ID on successful login.
  req.session.regenerate((err) => {
    if (err) return res.status(500).send("session error");
    req.session.userId = "user_123";  // set minimal identity + auth metadata
    req.session.authTime = Date.now();
    res.status(204).end();
  });
});

Step 5 — Refresh tokens: store safely, rotate, and revoke

If you need API access tokens (mobile, SPA calling APIs, integrations), treat refresh tokens as high-value secrets. Use rotation (each refresh invalidates the previous token) and store only a hash server-side. That way, a database leak doesn’t instantly become “everyone is logged in forever”.

This Python example demonstrates the core pattern: generate a refresh token, store only a hash, rotate it on use, and make “revoke all” feasible.

import hashlib
import hmac
import secrets
from datetime import datetime, timedelta, timezone

# Server secret used as a pepper for token hashing (keep it out of the DB).
TOKEN_PEPPER = b"replace-with-env-secret"

def token_hash(raw_token: str) -> str:
  # HMAC makes hashes resistant to rainbow tables and ties validity to your server secret.
  mac = hmac.new(TOKEN_PEPPER, raw_token.encode("utf-8"), hashlib.sha256).hexdigest()
  return mac

def issue_refresh_token(user_id: str) -> dict:
  raw = secrets.token_urlsafe(48)  # send this to the client ONCE
  now = datetime.now(timezone.utc)
  record = {
    "user_id": user_id,
    "token_hash": token_hash(raw),
    "issued_at": now.isoformat(),
    "expires_at": (now + timedelta(days=30)).isoformat(),
    "revoked": False
  }
  # Save record in DB (token_hash only). Never store `raw`.
  return {"refresh_token": raw, "record": record}

def rotate_refresh_token(old_raw: str, user_id: str) -> dict:
  # 1) Look up old token by hash
  old_h = token_hash(old_raw)
  db_row = db_find_refresh_token(user_id=user_id, token_hash=old_h)  # your DB function
  if not db_row or db_row["revoked"]:
    raise ValueError("invalid token")

  # 2) Enforce expiration
  if datetime.fromisoformat(db_row["expires_at"]) < datetime.now(timezone.utc):
    raise ValueError("expired token")

  # 3) Revoke old token and issue a new one (rotation)
  db_revoke_refresh_token(db_row["id"])
  return issue_refresh_token(user_id)

# Tip: if you detect the same old token used twice, revoke the entire "family"
# (all refresh tokens for that user/session) and force re-authentication.

Step 6 — Recovery and “account change” rules

Your recovery policy should be explicit and conservative. A user who can change their email without re-auth essentially hands ownership to anyone with a stolen session. Treat security-critical settings as privileged: require recent auth and/or step-up.

Common mistakes

These are the real reasons “we added MFA” still ends up with account takeovers. The fixes are usually simple — but only if you name the failure mode clearly.

FAQ

Are passkeys really better than passwords + MFA?

Yes, for most consumer and SaaS apps. Passkeys are designed to be phishing-resistant and remove password reuse. You can still keep MFA for step-up actions, but many users will experience fewer prompts and better security at the same time.

Should I remove passwords completely if I support passkeys?

Not immediately. A common strategy is “passkeys first” with a fallback (password or magic link) until adoption is high and your support team is comfortable with recovery flows. Removing passwords is possible, but only after you’ve hardened recovery and device onboarding.

What MFA method should I choose as a default?

Use TOTP (authenticator app) as the default, and offer security keys for high-value accounts. Treat SMS as a fallback for users who can’t use other methods, and add extra monitoring and rate limiting around it.

How long should sessions last?

Short enough that stolen sessions are limited, long enough that users aren’t angry. A typical pattern is an 8–24 hour web session (rolling) with explicit re-auth/step-up for sensitive actions. For APIs, use short-lived access tokens (minutes) with refresh token rotation.

Do I need CSRF protection if I use SameSite cookies?

Often, SameSite=Lax reduces CSRF risk for common flows — but don’t rely on it blindly. If you support cross-site POSTs, embedded contexts, or unusual auth flows, add CSRF tokens for state-changing actions. SameSite is a helpful default, not a complete strategy.

What’s the safest way to implement “Log out of all devices”?

Server-side session records. Keep a session table (or refresh token table) and mark all records revoked for the user. If you use JWTs without server-side state, you’ll need a revocation list or a short TTL plus rotation.

How do I stop credential stuffing?

Rate limit + detect + reduce password value. Add per-IP and per-account rate limiting, monitor failed logins, use breached-password checks if applicable, and shift users to passkeys so passwords become less relevant over time.

Cheatsheet

A scan-fast checklist for modern authentication: passkeys, MFA, and sessions. Use this for reviews, PR checklists, and “are we missing anything?” moments.

Wrap-up

“Modern authentication done right” is a set of defaults you can defend under attack: passkeys for the happy path, MFA for step-up and risky sign-ins, and sessions you can rotate and revoke. If you implement the Quickstart items and keep recovery tight, you’ll remove most takeover paths attackers rely on.

Want to go deeper? The related posts below cover practical exploitation patterns, lightweight threat modeling, and security checklists that pair well with an auth hardening sprint.

Related posts

• OWASP Top 10 in Real Life: How Apps Actually Get Hacked
• Threat Modeling in 45 Minutes: A Lightweight Template
• API Security Checklist: Auth, Rate Limits, and Abuse Cases
• DevSecOps Basics: Add Security to CI/CD Without Chaos
• Dependency Attacks: How One Package Can Burn Your App
• Linux Hardening 80/20: SSH, Updates, Firewall, Logs