Browser Authentication

Browser authentication assigns an application request to a user or workload identity. The application must define where credentials reside, which requests carry them, how the browser restricts them, and how the server invalidates them.

Sessions and Cookies #

For a browser application with a same-site backend, an opaque session identifier in a cookie keeps the credential out of JavaScript. Store session state server-side, rotate the identifier after authentication and privilege changes, and expire it on logout and inactivity.

Set Secure, HttpOnly, and an appropriate SameSite value. Secure requires HTTPS, HttpOnly prevents JavaScript access, and SameSite reduces cross-site request forgery exposure. SameSite is not a replacement for CSRF defenses: state-changing cookie-authenticated endpoints should validate a CSRF token or require an origin that the application explicitly trusts.

OAuth 2.0 and OpenID Connect #

OAuth 2.0 delegates authorization to an authorization server; it does not by itself standardize user authentication. OpenID Connect adds an identity layer and an ID token. Browser-based public clients should use Authorization Code with PKCE, validate state, nonce when using OpenID Connect, exact redirect URIs, issuer, audience, expiry, and signature.

Do not put access tokens in URL query strings or fragments that can reach logs, referrers, and browser history. A backend-for-frontend can keep tokens on the server and expose an application session cookie to the browser.

SAML #

SAML exchanges signed XML assertions between an identity provider and a service provider. Validate the assertion signature against configured metadata, issuer, audience, recipient, time conditions, and request correlation. XML signature validation must use a maintained library and hardened parser; handwritten XML or signature processing is unsafe.

Bearer Tokens #

JWT is a token format, not a session protocol. A resource server must verify the signature or obtain trusted introspection results, then validate issuer, audience, expiry, not-before time, and any authorization claims. Treat an unexpired bearer token as a credential: use short access-token lifetimes, scope-based authorization, key rotation, and a revocation design for the application’s risk profile.

Do not use token contents as an authorization decision without verification. Encrypting a token does not remove the need to validate the claims.