Authentication & Authorization

Authn vs Authz & Session-Based Auth

Authentication (authn) answers "who are you?" -- it verifies a claimed identity. Authorization (authz) answers "what are you allowed to do?" -- it enforces permissions after identity is established. Every secure system needs both, and they are separate concerns even when frameworks bundle them together.

Session-Based Authentication

The classic server-side pattern: after verifying credentials, the server creates a session object, stores it (in memory, Redis, or a database), and sends a Set-Cookie header with a random session ID. Every subsequent request includes this cookie, and the server looks up the session to identify the user.

JSON Web Tokens (JWT)

A JWT is a compact, URL-safe token consisting of three Base64url-encoded parts separated by dots: header.payload.signature. The server does not need to store state -- it verifies the signature and reads claims directly from the token.

// Header
{ "alg": "RS256", "typ": "JWT" }

// Payload (claims)
{
  "sub": "user_42",
  "iss": "auth.example.com",
  "exp": 1717200000,
  "roles": ["admin"]
}

// Signature
RSASHA256(base64url(header) + "." + base64url(payload), privateKey)

Signing Algorithms

Access + Refresh Tokens

A common pattern pairs a short-lived access token (5-15 min) with a longer-lived refresh token (days/weeks). When the access token expires, the client presents the refresh token to get a new pair. The refresh token is stored securely (httpOnly cookie or secure storage) and can be revoked server-side.

OAuth 2.0

OAuth 2.0 is a delegation framework -- it lets a user grant a third-party app limited access to their resources on another service, without sharing their password. It defines several grant types for different scenarios.

Authorization Code + PKCE

The most common and secure flow for web and mobile apps. PKCE (Proof Key for Code Exchange) prevents authorization code interception attacks, which is why it is now required even for server-side apps in best-practice guidance.

Other Grant Types

Scopes

Scopes limit what an access token can do. They are strings like read:user, write:repos, openid profile email. The authorization server includes granted scopes in the token response. Clients should always request the minimum scopes needed.

OpenID Connect & SAML 2.0

OpenID Connect (OIDC)

OIDC is a thin identity layer built on top of OAuth 2.0. It adds a standardized way to get user identity information. When you request the openid scope, the authorization server returns an ID Token (a JWT) alongside the access token.

SAML 2.0

Security Assertion Markup Language (SAML) is an older XML-based standard widely used in enterprise SSO. It involves two parties:

A SAML Assertion is an XML document containing authentication statements (when/how the user authenticated), attribute statements (user metadata), and authorization decision statements. Assertions are digitally signed and often encrypted.

WebAuthn & FIDO2

WebAuthn (Web Authentication API) enables passwordless authentication using public-key cryptography. Together with CTAP (Client to Authenticator Protocol), it forms the FIDO2 standard. The private key never leaves the authenticator device -- the server only stores the public key.

Authenticator Types

API Security, Access Control & Password Hashing

API Authentication Methods

Rate Limiting

Essential for API security. Common algorithms include token bucket (smooth bursts), sliding window (precise counts), and leaky bucket (constant drain). Typically enforced per API key, per IP, or per user. Return 429 Too Many Requests with a Retry-After header.

RBAC vs ABAC

Password Hashing

Never store passwords in plaintext or with fast hashes (MD5, SHA-256). Use purpose-built password hashing functions that are deliberately slow and memory-hard.