8. Authentication and authorization for backend engineers

Overview

Authentication = “who are you” (identity). Authorization = “what can you do” (permissions).

This is a high-level technical guide for backend engineers covering history, mechanisms, protocols, trade-offs and practical recommendations for authentication and authorization.

Historical context (short)

• Early systems relied on implicit identity (local trust, seals). As systems scaled, explicit proofs of identity became necessary.
• Industrial-era telegraph systems used shared passphrases — an early form of passwords.
• 1960s: MIT CTSS introduced passwords for multi-user systems. Early implementations stored plaintext passwords, which drove work on secure password storage and hashing.
• 1970s: Cryptography advances (Diffie–Hellman, asymmetric crypto, PKI) provided foundational primitives for modern authentication.
• Kerberos introduced ticket-based authentication; token-based systems later evolved from similar ideas.
• 1990s onward: Web scale and brute-force threats led to MFA, biometrics, and designs focused on cloud/mobile/API use cases.
• 21st century: OAuth/OIDC, JWTs, zero-trust, passwordless methods, and emerging areas (decentralized identity, post-quantum crypto, behavioral biometrics).

Core components introduced

• Session (server-side state)
  • Server stores session data (files → DB → Redis/cache); a session ID is sent to the client (usually in a cookie).
• JWT (JSON Web Token)
  • Stateless, self-contained token (header, payload, signature) used to carry claims.
• Cookies
  • Browser storage mechanism. HTTP-only cookies prevent JavaScript access and are commonly used to carry session IDs or tokens.

Technical details — Sessions vs JWTs (stateful vs stateless)

Sessions (stateful)

• How it works: server stores session data (DB/Redis); client receives a session ID in a cookie.
• Pros:
  • Centralized control and easy revocation
  • Real-time session insight and fine-grained session management
  • Recommended for web apps that need strict session control
• Cons:
  • Scaling and replication complexity in distributed systems
  • Storage and operational overhead

JWTs (stateless)

• How it works: self-contained tokens signed/encoded (base64). Typical fields: sub (user id), iat (issued at), roles, etc.
• Pros:
  • Scalable with no need for a server session store
  • Portable and suitable for distributed microservices and mobile apps
• Cons:
  • Revocation is hard — tokens are valid until expiry
  • Risk of impersonation if a token is leaked
  • Requires careful secret/key management and rotation

Hybrid approach

• Use JWTs but maintain a server-side blacklist/allowlist (e.g., in Redis) for revocation — trades some statelessness for control.
• Consider stateful sessions for browser clients and stateless tokens for machine/mobile clients.

JWT structure & verification

• Three parts: header (signing algorithm), payload (claims), signature (integrity using a secret or asymmetric key).
• Signed JWTs let servers verify integrity without database lookups; tampering invalidates the signature.
• Best practices:
  • Protect signing secrets/private keys
  • Limit sensitive data in the payload
  • Keep token lifetimes reasonable

Other auth types & when to use them

• API keys
  • Single-purpose secret tokens for machine-to-machine or programmatic access
  • Easy to generate; best for programmatic integration with limited scopes/quotas
• OAuth 2.0
  • Designed for delegation: allow one app to access another’s resources without sharing passwords
  • Introduced access tokens and refresh tokens; has multiple flows for different client types (authorization code, implicit — now discouraged, client credentials, device code)
• OpenID Connect (OIDC)
  • Built on OAuth 2.0 to add authentication (ID token, usually a JWT) so apps can “Sign in with …”
  • Typical flow: redirect → user consent → authorization code → exchange for access token + ID token
• Heuristics for choice:
  • Stateful sessions: web apps needing strict session control
  • Stateless/JWT: APIs, distributed systems, mobile-first apps
  • OAuth/OIDC: third-party integrations, social login, delegated access
  • API keys: service-to-service integrations

Authorization

• Purpose: restrict what authenticated users can do. It is distinct from authentication.
• Common model: RBAC (Role-Based Access Control)
  • Define roles (e.g., user, admin, moderator) and assign permissions per resource or action
  • On each request: determine identity/role (from token/session) and enforce permission checks; return 403 Forbidden when permissions are insufficient
• Implement authorization checks early in the request lifecycle so downstream code receives role/permission context

Security guidance / best practices

• Passwords
  • Never store plaintext passwords — use salted hashing and secure algorithms
• Error messages
  • Avoid overly-specific auth error messages; return generic responses (e.g., “Authentication failed”) to deny attackers reconnaissance data
• Timing attacks
  • Use constant-time comparisons for secrets/hashes
  • Consider uniform response delays or simulated processing time to avoid leaking which step failed
• Token management
  • Keep token lifetimes reasonable and provide refresh mechanisms
  • Plan for secret/key rotation and its effect on active sessions
  • For JWT revocation: use short lifetimes or a revocation blacklist/allowlist when necessary
• Cookies
  • Use HTTP-only and Secure flags for browser session cookies to reduce XSS-exposed tokens
• Operational guidance
  • In production, consider delegating authentication to specialized providers (Auth0, Clerk, etc.) unless you have the expertise and reason to build your own

Emerging & advanced topics

• Passwordless authentication (WebAuthn, hardware-backed keys)
• Zero Trust architectures
• Decentralized identity (blockchain-based DID models)
• Post-quantum cryptography (preparing for quantum-resilient algorithms)
• Behavioral biometrics (continuous authentication through pattern recognition)

Practical recommendations from the video

• For production systems, strongly consider using a reputable external auth provider unless you fully understand cryptographic and operational trade-offs.
• As a learning exercise, implement auth flows yourself to understand trade-offs, then migrate to providers in production.
• Use hybrid approaches where appropriate: stateful sessions for browser clients, stateless tokens for APIs and machine clients.

Resources mentioned

• jwt.io — inspect JWT structure
• Historical references: MIT Project MAC (CTSS), Diffie & Hellman, Kerberos, OAuth authors/engineering teams (e.g., Google/Twitter contributors)

Main speakers / sources

• Presenter: an unnamed instructor / backend engineer (single-speaker lecture)
• Historical and protocol authors referenced: MIT Project MAC (CTSS), Whitfield Diffie & Martin Hellman, designers of Kerberos, and engineers involved in OAuth/OIDC-era development (Google/Twitter contributors)