Authentication & authorization

01Sessions vs tokens

After login the server must recognise you on the next request. With sessions, the server stores your login state (in Redis or a database) and gives the browser a random session id in a cookie, like a cloakroom ticket. The ticket means nothing on its own; the server looks it up. Logging out is easy: delete the session. With tokens, the server gives the client a signed token that itself contains claims such as user id and expiry, and the server verifies the signature instead of looking anything up. Sessions are the best default for websites on your own domain. Tokens suit mobile apps, third-party clients and service-to-service calls. Many products use both.

• Session cookie: HttpOnly, Secure, SameSite=Lax (or Strict), short idle timeout.
• Regenerate the session id at login to prevent session fixation.
• Cookies need CSRF protection; bearer tokens in headers need XSS protection.

02JWT: access tokens, refresh tokens and revocation

A JWT (JSON Web Token) has three parts: header, payload with claims, and signature. Anyone can read the payload, so never put secrets in it; the signature only proves it was not changed. Use a short-lived access token (5 to 15 minutes) for API calls and a long-lived refresh token, stored securely, to get new access tokens. Rotate refresh tokens: each use issues a new one and invalidates the old. If an old refresh token is ever used again, assume theft and revoke the whole token family. Because JWTs are valid until they expire, revocation needs extra work: a denylist of token ids (jti) in Redis, a token version on the user, or re-checking the user on each request. Prefer asymmetric signing (RS256 or EdDSA) when several services verify tokens, and always check alg, iss, aud and exp.

1// Verify an access token (jose library)
2import { jwtVerify, createRemoteJWKSet } from 'jose';
3 
4const jwks = createRemoteJWKSet(new URL('https://auth.example.com/.well-known/jwks.json'));
5 
6export async function verifyAccessToken(token: string) {
7  const { payload } = await jwtVerify(token, jwks, {
8    issuer: 'https://auth.example.com',
9    audience: 'api.example.com',
10    algorithms: ['RS256'],
11  });
12  if (await denylist.has(payload.jti as string)) throw new Error('Token revoked');
13  return payload;
14}

03OAuth2, OpenID Connect and social login

OAuth2 is a standard for delegated access: a user lets an app act on their behalf without giving it their password. OpenID Connect (OIDC) is a layer on top that adds identity, an ID token that says who the user is. 'Sign in with Google' or 'Sign in with Apple' is OIDC. For web and mobile apps use the Authorization Code flow with PKCE (Proof Key for Code Exchange), which protects the code from interception; the old Implicit flow is deprecated. Always validate the state parameter against CSRF, verify the ID token signature, issuer, audience and nonce, and link social accounts by the provider's stable subject id, not by email alone. iOS apps that offer third-party social login must also offer a privacy-focused option such as Sign in with Apple (App Store guideline 4.8).

04Passwords, OTP and 2FA

Never store passwords, store hashes. Use Argon2id (OWASP minimum: 19 MiB memory, 2 iterations, parallelism 1) or bcrypt with cost 10 or more; note bcrypt only uses the first 72 bytes. Frameworks do this for you: Laravel's Hash facade, or the argon2 package in Node. Check new passwords against known breached lists and rate limit login attempts. One-time passwords by SMS or email are convenient for phone-first markets: generate a random 6-digit code, store only its hash with a short expiry (about 5 minutes), allow a few attempts, and rate limit sends per phone and per IP to stop SMS cost abuse. Two-factor authentication adds a second proof: TOTP apps, passkeys (WebAuthn) or SMS as a weaker fallback. Require 2FA for staff and admins.

1// Laravel: OTP verification with rate limiting
2$key = 'otp:'.$request->phone;
3if (RateLimiter::tooManyAttempts($key, 5)) {
4    abort(429, 'Too many attempts, try again later.');
5}
6RateLimiter::hit($key, 600);
7 
8$otp = OtpCode::where('phone', $request->phone)
9    ->where('expires_at', '>', now())
10    ->latest()->first();
11 
12if (! $otp || ! Hash::check($request->code, $otp->code_hash)) {
13    throw ValidationException::withMessages(['code' => 'Invalid or expired code.']);
14}
15$otp->delete();
16RateLimiter::clear($key);

05Roles, permissions and API keys

RBAC, role-based access control, gives users roles (owner, manager, cashier) and roles carry permissions (orders.refund, menu.edit). Check permissions, not role names, in code: 'can refund' survives new roles, 'is manager' does not. Keep checks on the server in one place, such as Laravel policies and gates or NestJS guards, and hide buttons in the UI only as a convenience. In multi-tenant apps every check also includes the tenant: a manager of company A has no rights in company B. For machine clients, issue API keys with scopes: generate a long random key, show it once, store only its hash, add a visible prefix to identify it (for example live_ or test_), and support expiry, rotation and per-key rate limits. Log who used which key.

06Secure defaults checklist

Most auth bugs come from details. Set cookies with HttpOnly so JavaScript cannot read them, Secure so they only travel over HTTPS, SameSite=Lax or Strict against CSRF, and a narrow Path. Use the __Host- cookie prefix for session cookies when possible. Return the same error for 'unknown user' and 'wrong password' to avoid account enumeration. Rate limit login, OTP and password reset. Make reset links single-use and short-lived. Log security events (logins, failed attempts, role changes, impersonation) and alert on spikes. For support impersonation, make it time-boxed, require a reason and audit it.

1Set-Cookie: __Host-session=9f8c...; Path=/; Secure; HttpOnly; SameSite=Lax; Max-Age=7200

07Where tokens live: browsers, the BFF pattern and mobile storage

Any token JavaScript can read, an XSS bug can steal. That is why storing access and refresh tokens in localStorage is risky for a single-page app. The Backend-for-Frontend (BFF) pattern removes tokens from the browser entirely: a thin server on your domain runs the OAuth flow, keeps tokens server-side, and gives the browser only an HttpOnly, Secure, SameSite session cookie. API calls go through the BFF, which attaches the access token. On mobile there is no cookie jar to lean on, so store refresh tokens in the platform's secure storage, Keychain on iOS and Keystore-backed storage on Android, never in plain preferences. The OAuth 2.0 Security Best Current Practice (RFC 9700, January 2025) also recommends sender-constrained tokens where possible, such as DPoP (RFC 9449), which binds a token to a key the client holds, so a stolen token alone is useless.

• SPA on your own domain: session cookie or BFF, not localStorage.
• Mobile: secure storage plus refresh token rotation, bound to the device.
• Service to service: client credentials or mTLS, short-lived tokens.

08Passkeys and WebAuthn under the hood

A passkey is a key pair created by the user's device for one website. The private key never leaves the device or the user's password manager; the server stores only the public key. To sign in, the server sends a random challenge, the device asks for a fingerprint, face or PIN, and signs the challenge. The server verifies the signature with the stored public key. Crucially, the browser includes the origin in what is signed, so a fake site on a look-alike domain cannot get a valid signature: passkeys are phishing-resistant in a way that SMS codes and TOTP are not. Your site is the relying party, identified by an RP ID such as example.com. Use a maintained library on both sides, keep at least one recovery path, and let users register several passkeys.

1// Browser, using @simplewebauthn/browser
2import { startAuthentication } from '@simplewebauthn/browser';
3 
4const optionsJSON = await api.post('/webauthn/login/options'); // fresh, single-use challenge
5const assertion = await startAuthentication({ optionsJSON });
6await api.post('/webauthn/login/verify', assertion);
7 
8// Server (@simplewebauthn/server verifyAuthenticationResponse) must check:
9// expected challenge, expected origin and RP ID, the signature against the
10// stored public key, and user verification if your policy requires it.

09Timing attacks, enumeration and credential stuffing

Attackers learn from tiny differences. If 'unknown email' returns in 5 ms and 'wrong password' in 80 ms because only the second runs a hash, they can list which accounts exist. Run a dummy hash for unknown users and return the same message. Compare secrets such as API keys, reset tokens and webhook signatures with constant-time functions, hash_equals in PHP or crypto.timingSafeEqual in Node, never with ===. Credential stuffing, trying leaked email and password pairs from other sites, is the most common attack on login forms. Defend in layers: rate limits per account and per IP, a check against breached passwords (the Have I Been Pwned range API uses k-anonymity, so you send only the first five characters of a SHA-1 hash), CAPTCHA after suspicious patterns, and alerts on login failure spikes. Hard account lockouts can be abused to lock real users out, so prefer progressive delays.

1import { createHmac, timingSafeEqual } from 'node:crypto';
2 
3export function isValidSignature(rawBody: Buffer, headerHex: string, secret: string) {
4  const expected = createHmac('sha256', secret).update(rawBody).digest();
5  const received = Buffer.from(headerHex, 'hex');
6  // timingSafeEqual throws on different lengths, so check that first
7  return received.length === expected.length && timingSafeEqual(received, expected);
8}

10Authorization beyond roles: ABAC, ReBAC and list filtering

Roles answer 'what kind of user is this?', but real rules often depend on more. Attribute-based access control (ABAC) adds conditions: a manager may refund only orders from their own branch and only up to a limit. Relationship-based access control (ReBAC), popularised by Google's Zanzibar paper and implemented by OpenFGA and SpiceDB, models permissions as a graph: a user can edit a document because they belong to a team that owns its folder. Policy engines such as OPA or Cedar keep rules outside the code. The hardest part is lists: checking each row after loading it breaks pagination and leaks counts. Push authorization into the query instead, as a scope that adds tenant, branch or ownership conditions, so the database returns only rows the user may see. Test both directions: allowed users see data, everyone else gets 404.