Authentication and Authorization

Key features

• Authentication answers "who are you" — login, session, token, certificate, API key are all authentication mechanisms
• Authorization answers "what are you allowed to do" — a role, a permission, an ownership check, evaluated after identity is already known
• Authorization always runs after authentication logically, even when both happen inside one middleware call — you cannot decide what an unknown caller may do
• A request can be fully authenticated (a valid, unexpired token from a real user) and still be correctly rejected by authorization (that real user has no permission for this specific action)
• Mixing the two up is a common source of security bugs: code that checks "is this token valid" and treats that as equivalent to "is this action allowed" skips the authorization step entirely

Command

# Authentication: establishes identity
user = authenticate(request.token)   # -> User(id=482) or reject (401)

# Authorization: checks what that identity may do
if not authorize(user, action='delete', resource=invoice):
    return 403  # known caller, disallowed action

Key features

• Session-cookie auth: server stores session state (usually in Redis or a database) keyed by a session ID; the cookie holds only that ID, which is meaningless without the server-side lookup
• Token auth (JWT): the token itself contains the claims (user ID, roles, expiry) and a signature; any service holding the signing key or public key can verify it without a database round trip
• Revocation is the sharpest trade-off: deleting a session server-side takes effect on the next request; a JWT is valid until it expires no matter what the server "wants" — revoking one early needs an extra denylist, defeating some of the statelessness
• Cookies are automatically sent by the browser on same-site requests and can be marked HttpOnly (unreadable by JavaScript) and Secure (HTTPS-only), which blocks a large class of token-theft-via-XSS that a JWT stored in localStorage does not get for free
• Token auth scales horizontally without a shared session store, which is why it dominates for stateless APIs and service-to-service calls, while session cookies remain common for traditional server-rendered web apps talking to one backend

Command

# Session/cookie: cookie carries only an opaque ID
Set-Cookie: sid=9f8c...; HttpOnly; Secure; SameSite=Lax
# server: session_store[sid] -> { user_id: 482, roles: [...] }

# Token (JWT): client carries the claims themselves
Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiI0ODIi...
# decoded payload: { "sub": "482", "roles": ["admin"], "exp": 1893456000 }

Key features

• OAuth 2.0's core output is an access token scoped to specific permissions ("read this user's calendar") — it was never designed to prove who the user is to the app that receives the token
• OpenID Connect adds an ID token (a JWT with standardized identity claims: sub, email, name) alongside the OAuth access token — this is what actually authenticates the user to your app
• "Sign in with Google/GitHub" is OIDC, not plain OAuth — an app using only OAuth's access token to decide who is logged in is misusing a protocol not built for that purpose
• The authorization code flow (RFC 6749 §4.1) is the standard flow for a server-side app: the browser is redirected to the provider, the provider redirects back with a short-lived code, and the app's backend exchanges that code for tokens directly with the provider — the access token never passes through the browser
• PKCE (Proof Key for Code Exchange, RFC 7636) is now recommended even for confidential clients, not just mobile/SPA apps — it binds the code exchange to the app that started the flow, closing an interception risk on the redirect step

Command

# Authorization code flow, HTTP-shaped

GET https://provider.com/authorize
    ?response_type=code
    &client_id=<app_id>
    &redirect_uri=<callback_url>
    &scope=openid email profile   # "openid" scope -> this is OIDC
    &state=<csrf_token>
    &code_challenge=<pkce_hash>

# ... user logs in and consents at the provider ...
# provider redirects to: <callback_url>?code=<auth_code>&state=<csrf_token>

POST https://provider.com/token
    grant_type=authorization_code
    &code=<auth_code>
    &code_verifier=<pkce_secret>
    &client_id=<app_id>&client_secret=<app_secret>

# response: { "access_token": "...", "id_token": "<jwt>", "expires_in": 3600 }

Key features

• An API key is a static shared secret sent with each request (a header or query param) — simple to implement, but it does not expire on its own, is often over-shared across a team, and grants whatever it grants to anyone who has the string
• mTLS (mutual TLS) has both the client and the server present certificates during the TLS handshake, so identity is verified at the connection layer before any application data moves — this is common between services inside a trusted network or mesh
• Long-lived static credentials (API keys, service account passwords) are a bigger blast radius when leaked than short-lived ones, because there is often no automatic expiry forcing rotation — a leaked key in a log file or a public repo can stay valid indefinitely if nobody notices
• A service mesh (e.g. Istio) or workload-identity system typically issues short-lived certificates automatically per service instance and rotates them continuously, removing the need for any human-managed secret at all for internal service-to-service calls
• Choosing between these is about trust boundary, not preference: API keys are common for external third-party integrations where a full mTLS setup is impractical for the caller; mTLS and workload identity dominate for internal service-to-service traffic where both ends are under the same organization's control

Command

# API key: a shared secret sent per request
GET /api/orders
X-API-Key: sk_live_9f8c2a1b7e4d...

# mTLS: both sides present certificates during the TLS
# handshake itself -- no secret travels in the request body
# (conceptually, both directions verified before HTTP starts)
client_cert = load_cert("service-a.crt")
server_requires_client_cert = True  # server rejects handshake without one

# OAuth 2.0 client credentials grant: service authenticates
# as itself, not on behalf of any user
POST /token
    grant_type=client_credentials
    &client_id=service-a
    &client_secret=<secret>
# response: { "access_token": "...", "expires_in": 3600 }

Key features

• RBAC (Role-Based Access Control) assigns permissions to roles, and roles to users — simple to reason about and audit, but coarse: it answers "can an editor delete posts" as a blanket yes/no, not "can THIS editor delete THIS post"
• ABAC (Attribute-Based Access Control) evaluates a policy against attributes of the subject (user role, department), the resource (owner, sensitivity, status) and the context (time, IP, device) together — more expressive than RBAC, at the cost of policies that are harder to audit at a glance
• Tenant isolation ensures one customer/organization's data is never reachable by another tenant, in a multi-tenant system — usually enforced by a tenant ID present on every row and checked on every query, not merely assumed from the URL or a role
• Object-level authorization is the check that the specific resource instance in THIS request belongs to (or is otherwise permitted for) THIS caller — role or attribute checks alone confirm a category of access, never a specific instance
• OWASP's API Security Top 10 lists Broken Object Level Authorization as its #1 API risk — because a role check that never verifies resource ownership lets any authenticated user reach any other user's data just by changing an ID in the request, often with no error anywhere in the logs

Command

# RBAC: role -> permission, blanket
if 'editor' in user.roles:
    allow('edit', any_post)   # true for ANY post, not just theirs

# ABAC: policy over attributes
allow = (
    'editor' in user.roles
    and post.author_id == user.id       # resource attribute
    and current_hour in business_hours  # context attribute
)

# Object-level authorization: the specific-instance check
def can_edit(user, post):
    return post.author_id == user.id or 'admin' in user.roles