Authentication & Authorization

Authentication and authorization are easy to say in one breath. Treating them as one thing is the most common security bug on the internet. Both OWASP A01 Broken Access Control and A07 Identification & Authentication Failures exist because someone wrote a check that conflated logged in with allowed.

Authentication — Proving Identity

Authentication asks who are you? and demands evidence. Evidence comes in factors:

• Something you know — password, PIN.
• Something you have — phone, hardware key (YubiKey), trusted device.
• Something you are — fingerprint, face, voice.

True multi-factor authentication mixes different factors — password + hardware key, not password + security question. SMS one-time codes count as "something you have," but are weak: SIM-swap attacks have stolen tens of millions of dollars in the past five years. NIST 800-63B has effectively deprecated SMS for high-assurance use.

Sessions — The Workhorse

The simplest scheme: after login, the server issues a random opaque token, sets a cookie, and stores the session record. Every request, the cookie comes back; the server looks it up. Logging out invalidates the session row — instantly.

Cookie attributes are non-negotiable in 2025:

Set-Cookie: sid=...; Secure; HttpOnly; SameSite=Lax;
            Path=/; Max-Age=86400

• Secure — only over TLS.
• HttpOnly — invisible to JavaScript (mitigates XSS theft).
• SameSite=Lax (or Strict) — blocks cross-site requests from carrying it (CSRF defense).
• __Host- prefix for sensitive cookies — forces Secure + Path=/ + no Domain.

JWTs — Useful, Routinely Misused

A JWT is three base64 parts: header, payload, signature. The signature is over the first two with either HMAC (HS256, shared secret) or a public-key signature (RS256, ES256, EdDSA). The payload is readable — JWTs encode, they do not encrypt.

eyJhbGciOiJFUzI1NiIsImtpZCI6IjE0In0.eyJzdWIiOiJ1XzQyIiwic2NvcGUiOiJyZWFkOm9yZGVycyIsImV4cCI6MTcwOTI4MDAwMH0.MEUCIQDk…
# header              payload                                                signature

When to Pick Which

OAuth 2.0 — Delegated Access

OAuth answers a different question: how does an app act on a user's behalf at another service, without handling the user's password? Authorization Code with PKCE is the only flow you should reach for in 2025 (yes, even for SPAs).

OIDC — Authentication on Top of OAuth

OAuth 2.0 grants an access token; it doesn't tell you who the user is. OpenID Connect (OIDC) layers on top: the token endpoint also returns an id_token — a signed JWT with the user's identity (sub, email, name). Always validate iss, aud, exp, and the signature against the IdP's JWKS.

Authorization — The Hard Half

Now the user is identified. What may they actually do? Two dominant models, plus a third for cross-cutting policy.

RBAC — Role-Based

Users get one or more roles; roles are bundles of permissions. Simple to reason about. Right answer for most apps.

# roles → permissions
role viewer  → orders:read
role manager → orders:read, orders:refund
role admin   → orders:*, users:*

ABAC — Attribute-Based

Permissions are computed from attributes of the user, the resource, and the context. Necessary when policy depends on data values, not just on who you are.

allow if user.dept == order.dept
   and order.amount < 50000
   and request.time.hour < 22

ReBAC — Relationship-Based

Permissions follow graph edges ("X is in folder Y, which is shared with team Z"). Google's Zanzibar paper popularised it; engines like SpiceDB, OpenFGA, and AuthZed implement it. Right answer for collaborative apps (Drive, GitHub, Notion).

The Most Common AuthN/AuthZ Mistakes

• No object-level authorization. The cause of nearly every IDOR.
• Trusting client-side checks. "Hide the admin button if not admin" — useful UX, useless security. Always re-check on the server.
• Mass assignment. Updating UserUpdate{...} with req.body directly. Attacker adds "role": "admin" in the JSON. Use allow-lists.
• JWTs without revocation. A leaked token is valid until expiry. Keep TTLs short; track a denylist for forced logout.
• Open redirect on callback. Allowing arbitrary redirect_uri values turns OAuth into a phishing primitive. Strict allow-list of registered URIs.