Authentication & Authorization

Authentication verifies who someone is. Authorization determines what they're allowed to do. Together, they form the access control layer of any system that serves more than one user.

Authentication

Authentication answers a single question: is this entity who they claim to be?

Password-based authentication remains common but is rarely used alone. Passwords are typically paired with a second factor — a time-based code, a hardware key, or a push notification — to form multi-factor authentication (MFA). This significantly reduces the risk of credential compromise.

Token-based authentication is the standard for APIs and modern web applications. After initial login, the server issues a token — typically a JWT (JSON Web Token) — that the client includes with subsequent requests. The server validates the token without maintaining session state, which simplifies horizontal scaling.

OAuth 2.0 delegates authentication to a trusted third party. Rather than managing credentials directly, your application redirects users to an identity provider (Google, GitHub, or an internal service) that handles the login flow and returns an access token. OAuth defines several grant types: authorization code flow for web apps, client credentials for service-to-service communication, and device flow for hardware with limited input. PKCE (Proof Key for Code Exchange) is now recommended for all public clients to prevent authorization code interception.

OpenID Connect (OIDC) builds on OAuth 2.0 to add a standardized identity layer. Where OAuth provides only an access token, OIDC also returns an ID token containing claims about the user — name, email, and other profile data. This is what enables single sign-on (SSO) across multiple applications.

Authorization

Once identity is established, authorization governs what that identity can access.

Role-Based Access Control (RBAC) is the most common model. Users are assigned roles (admin, editor, viewer), and each role carries a set of permissions. Roles can form hierarchies — an admin inherits all editor permissions, which in turn inherit viewer permissions. RBAC is straightforward to reason about and works well for most applications.

For more granular control, Attribute-Based Access Control (ABAC) evaluates policies against attributes of the user, the resource, and the environment. "Editors can modify documents in their own department during business hours" is an ABAC policy. More flexible than RBAC, but harder to audit and debug.

Practical Considerations

Stateless vs. stateful sessions. JWTs enable stateless authentication — the server doesn't store session data. The tradeoff: tokens can't be easily revoked before expiry. If immediate revocation matters, use short-lived access tokens paired with longer-lived refresh tokens, or maintain a server-side deny list.

Token storage. In browsers, store tokens in HTTP-only cookies rather than localStorage. Cookies with the Secure, HttpOnly, and SameSite attributes provide built-in protection against XSS and CSRF attacks that localStorage cannot offer.

Service-to-service authentication. Internal services authenticate to each other using mutual TLS (mTLS) or signed JWTs. The principle: even within a private network, services should verify each other's identity rather than trusting network position alone. See networking for the TLS and certificate foundations, and network-isolation for how authentication fits into a defense-in-depth network architecture.