Authentication Strategies: Sessions, Tokens, OAuth & MFA

Q: Where should I store tokens in a browser?

Refresh tokens in HttpOnly cookies; access tokens short-lived in memory. Avoid localStorage for anything sensitive — it's exposed to XSS.

Authentication Strategies

Authentication answers one question: who is the caller? It's distinct from authorization (what may they do?), but the strategy you choose shapes your security posture, your UX, and your architecture.

There's no single "best" approach — a server-rendered web app, a single-page app talking to an API, and a mobile client each have a different right answer. This guide covers the main strategies and when to reach for each.

TL;DR

Browser app with a backend: session cookies (HttpOnly, Secure, SameSite) — simple, revocable.
APIs and mobile: OAuth 2.0 / OIDC (Authorization Code + PKCE) with short-lived access tokens.
JWTs are great for stateless APIs but hard to revoke — keep them short-lived.
Build account recovery and MFA in from day one, and rate-limit every auth endpoint.

Quick Example

A hardened session cookie issued on login — the safest default for first-party web apps:

Core Concepts

Authentication vs authorization

Authentication establishes identity (which user/service).
Authorization enforces permissions on resources and actions.

You can authenticate perfectly and still be insecure if authorization is weak — see API Security.

The Main Approaches

Session-based (cookies)

The server creates a session record and sets a cookie; the browser sends it automatically. Easy logout and revocation (delete the session), but needs a session store and CSRF protection.

Token-based (bearer)

The client stores an access token and sends Authorization: Bearer <token>. Works well across services and avoids cookie/CSRF coupling, but token theft is costly until expiry — keep access tokens short-lived. See JWT.

OAuth 2.0 + OpenID Connect

The modern default for delegated access and "Login with X." OIDC adds identity on top of OAuth. See OAuth 2.0 & OpenID Connect.

Passwordless & passkeys

Magic links and OTPs work for consumer apps; passkeys (WebAuthn) are increasingly the strongest, phishing-resistant option. Rate-limit verification and keep tokens short-lived.

Multi-factor authentication (MFA)

Layered strongest to weakest: passkeys / security keys → TOTP apps → push approvals → SMS (weakest, SIM-swap risk).

Choosing a Strategy

Best Practices

Password handling

Never store plaintext; hash with bcrypt/Argon2 and screen against breaches. See Password Security.

Account recovery

Auth isn't done without recovery: email reset with short-lived tokens, invalidate existing sessions on password reset, and require re-auth (and MFA) for high-risk actions.

Session & token management

Rotate the session ID on login; set idle and absolute expiry.
Keep access tokens short-lived; rotate refresh tokens and bind them to a device.
Offer users a visible device/session list.

Common Mistakes

Leaking whether an account exists

No rate limiting on auth endpoints

Storing long-lived tokens in localStorage

Any XSS can read localStorage. Prefer HttpOnly cookies for refresh tokens and keep access tokens short-lived in memory. See XSS.

FAQ

Sessions or JWTs — which should I use?

For first-party browser apps, session cookies are simpler and revocable. For stateless APIs and cross-service calls, short-lived JWTs shine. Many apps use both: cookies for the browser, tokens for service-to-service.

Where should I store tokens in a browser?

Refresh tokens in HttpOnly cookies; access tokens short-lived in memory. Avoid localStorage for anything sensitive — it's exposed to XSS.

Do I really need MFA?

For anything protecting real user data, yes. Passkeys or TOTP dramatically reduce account takeover from stolen or phished passwords. Offer it early, even if optional at first.

What are passkeys?

Passkeys are WebAuthn credentials backed by device biometrics/security keys. They're phishing-resistant (no shared secret to steal) and are becoming the preferred passwordless option.