Summary of "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)
Category
Technology
Share this summary
Is the summary off?
If you think the summary is inaccurate, you can reprocess it with the latest model.
Preparing reprocess...