Authentication establishes a principal from evidence supplied during a protocol exchange. Authorization decides what that principal may do. A complete design also defines credential enrollment, proof, session continuity, revocation, and recovery. Collapsing those responsibilities into one “authentication method” hides the boundary that failed.

For a server-rendered browser application, one sound design is OIDC Authorization Code with PKCE followed by an opaque application session. The callback validates state, redeems the code with the PKCE verifier, and validates the ID token’s signature, issuer, audience, expiry, and applicable nonce. A Secure; HttpOnly; SameSite=Lax cookie carries only the session identifier. Authorization still runs for every protected operation.

Authentication Factors, Credentials, and Protocols

Factors describe what the claimant proves. Credentials are the concrete secrets or keys used to prove it. Protocols define the messages and the verifier. Tokens normally carry a result or delegated authority. Possession of a bearer token authenticates the caller only as “whoever has this token.”

MFA needs independent factor types: two passwords remain one knowledge factor. A passkey ceremony can combine local user verification with public-key proof. Enrollment, device sync, and account recovery may still provide an easier takeover path than the primary ceremony.

Separate the Layers

These components combine. They are not alternatives on one ladder:

1. The credential and ceremony prove control of a password, key, certificate, or external identity.
2. Browser transport and storage carry state between requests, commonly with a cookie.
3. A server session maps an opaque handle to mutable server-side state, while a bearer token carries authority to whoever presents it.
4. JWT and PASETO are token formats, not login protocols. A JWT can be stored in a cookie, and an opaque session can coexist with OAuth access tokens.
5. Federation/SSO lets an application rely on an identity provider for authentication.
6. OAuth delegates authorization to a client. OIDC adds an interoperable authentication result.

The distinction changes incident response. Deleting an opaque session record can stop later uses of that handle as soon as every verifier observes the deletion. A self-contained bearer token normally remains usable until expiry unless the resource server consults an online control or validates sender binding.

Cookies and Browser Sessions

The server creates state with a response header such as:

Set-Cookie: __Host-session=J4p...; Path=/; Secure; HttpOnly; SameSite=Lax; Max-Age=1800

The browser stores the cookie and later sends it only when domain, path, expiry, and security rules match. Secure restricts transmission to HTTPS, HttpOnly blocks JavaScript reads, and SameSite limits cross-site sending. None of them encrypt the value or make a stolen session harmless. The __Host- prefix additionally requires Secure, Path=/, and no Domain, preventing a subdomain from setting a wider cookie.

An opaque random identifier should point to server-side state. Profile data and authorization decisions do not belong in an unsigned cookie. Identifier rotation after login and privilege changes stops session fixation. Expiry must exist in both the browser and session store. SameSite=Lax adds defense in depth, while state-changing requests still need CSRF protection wherever cross-site cookie delivery remains possible.

Diagram caveat

Cookies use the browser’s cookie store, not Web Storage. Omitting Domain creates a host-only cookie. A valid Domain can widen scope only to the current host’s parent domain, never to an unrelated site or public suffix. Path, Secure, HttpOnly, and SameSite constrain delivery and access but do not encrypt the value.

Opaque Sessions versus Bearer Tokens

Compare complete architectures, not cookies against JWTs:

Opaque sessions fit first-party browser applications that need mutable server-side state and prompt revocation. Short-lived OAuth access tokens fit API boundaries where resource servers need delegated authority issued by an authorization server. Both designs need expiry, audience restriction, rotation policy, and a response to replay after theft.

Token and HMAC API Authentication

A bearer token is sufficient evidence for whoever possesses it. It must travel over TLS, be restricted to its intended resource audience, carry the smallest useful scope, expire quickly, and remain out of URLs and logs.

Keyed request authentication instead proves possession of a shared secret for each request. The client and server must produce the same canonical byte string, for example:

POST
https://api.example.com/payments/42?currency=USD&expand=receipt
content-type:application/json
x-key-id:merchant-7
x-nonce:e1d0...
x-timestamp:2026-07-16T08:30:00Z
SHA-256(request-body)

The client computes HMAC-SHA-256(secret, canonical-request) and sends the key ID, timestamp, nonce, and MAC. The server resolves the secret by key ID, rebuilds the canonical request from received bytes, compares the MAC in constant time, rejects timestamps outside a short window, and records accepted nonces until that window closes. Without the nonce/timestamp checks, a captured valid request can be replayed. The canonical target must bind the HTTP method, authority, path, and normalized query—or one normalized absolute target URI—so an attacker cannot replay a valid MAC against another host or change a query argument. The signing profile must define URI normalization, query ordering and encoding, header selection, whitespace, and body hashing exactly. A reverse proxy must preserve or supply the original target components used by both parties.

The key ID is public metadata, not a public cryptographic key. Both HMAC parties share the same secret. Each key belongs to one API and environment even when another system accidentally holds the same bytes. Rotation can overlap old and new key IDs while clients move. New designs should use a standard signing profile where possible. RFC 9421 defines HTTP Message Signatures. RFC 6151 rules out HMAC-MD5 for new protocols.

Choosing an Auth Approach

SSO federates login, two-factor authentication strengthens the ceremony, and resource-based authorization applies authorization after the caller is known. None replaces the others.

References

• OWASP Authentication Cheat Sheet
• HTTP State Management Mechanism
• HTTP Message Signatures