Authentication and authorization for backend engineers

This video provides an in-depth exploration of authentication and authorization, covering their historical evolution, key technical components, common workflows, major authentication types, and best security practices. It is tailored for backend engineers seeking a deep understanding of modern authentication systems and their authorization counterparts, highlighting practical trade-offs and emerging trends.

1. Introduction to Authentication and Authorization

Authentication establishes who the subject is in a given context (e.g., platform, OS, or device).
Authorization answers what the authenticated subject can do—their permissions and capabilities within that context.

• Authentication answers "Who are you?"
• Authorization answers "What can you do?"

These processes together ensure secure and controlled access to systems.

2. Historical Evolution of Authentication

Authentication methods evolved from intrinsic, trust-based recognition in small societies to sophisticated cryptographic and programmatic systems today:

• Pre-industrial Society: Identity was implicit, based on community recognition and trust (e.g., village elder vouching for a person). Deals sealed by handshake symbolized trust.

• Scaling Challenge: As societies grew, this implicit trust failed to scale due to lack of universal recognition beyond personal acquaintance.

• Medieval Period: Introduction of wax seals as physical tokens of identity on documents, functioning as primitive authentication tokens based on the possession of unique seals. Vulnerable to forgery—a form of bypass attack.

• Industrial Revolution: Emergence of shared secrets/passphrases with advancements such as the telegraph required more secure validation via static passwords, transitioning the principle from something you have (seal) to something you know (passphrase).

• Mid 20th Century: Introduction of digital authentication with early multi-user computers like MIT’s CTSS (1961), where plaintext passwords were first used—a significant security vulnerability prompting secure password storage via cryptographic hashing and salting.

• 1970s Cryptographic Breakthroughs:

  • Diffie-Hellman key exchange introduced asymmetric cryptography, enabling shared secrets over untrusted channels.
  • Rise of Public Key Infrastructure (PKI) and ticket-based systems like Kerberos, the precursor to modern token-based authentication.

• 1990s Internet Expansion: Increased need for scalable authentication led to Multi-Factor Authentication (MFA), combining something you know (password), something you have (smart card or OTP), and something you are (biometrics).

• Modern Era: Rise of cloud, mobile, and API architectures necessitate advanced frameworks: OAuth 2.0, JWTs, zero trust models, passwordless authentication, and emerging concepts like decentralized identity and post-quantum cryptography.

3. Key Components in Authentication Systems

Sessions

• HTTP is stateless; each request is isolated with no memory between them.

• To support dynamic, stateful interactions (e.g., items in a shopping cart, logged-in status), sessions were introduced to maintain temporary server-side state per user.

• Workflow:

  1. On login, server creates a unique session ID and stores user data in a persistent store (file, database, Redis).
  2. Server sends the session ID to client as a cookie.
  3. Client sends cookie with each subsequent request; server retrieves user data via session ID.
  4. Sessions have expiration times (e.g., 15 minutes).

• Evolution: File-based → database-backed → distributed in-memory stores (Redis, Memcached) for scalability and performance.

JSON Web Tokens (JWTs)

• JWTs emerged mid-2000s to address session scalability issues in globally distributed systems.

• JWTs are stateless, self-contained tokens encoding user data (claims) and cryptographic signatures in a compact Base64 string.

• JWT structure:

  Part	Role
  Header	Metadata (e.g., signing algorithm)
  Payload	User claims (e.g., user ID in sub, issue time iat, role)
  Signature	Verifies issuer and ensures token integrity (non-tamper)

• Advantages:

  • No server-side session storage → scalability & portability
  • Works well in microservice architectures; any server with secret key can validate tokens.
  • Passable via authorization headers, cookies, or URLs.

• Challenges:

  • Token revocation is complex because tokens are not stored server-side.
  • To revoke tokens, either change server secret (logging out all users) or use blacklists (hybrid approach, introduces some statefulness).

• Hybrid techniques combine JWTs with server-side blacklists for better control but mitigate some scalability benefits.

Cookies

• Cookies store small pieces of data on the client browser set by the server.
• They automate sending authentication tokens (session IDs or JWTs) with every subsequent client request.
• Cookies are domain-scoped for security (one server cannot access another’s cookies).
• HTTP-only cookies prevent JavaScript access, improving security against certain attacks.

4. Major Types of Authentication

Stateful Authentication Detail

• Server validates user credentials → creates session ID → stores session with user data in Redis/database → sends session ID as cookie to client.
• Subsequent requests include cookie → server fetches session → user is authenticated and authorized.
• Centralized but limited scalability, especially in distributed or multi-region architectures.

Stateless Authentication Detail

• Server validates credentials → generates signed JWT → sends token to client.
• On each request, client sends JWT → server verifies signature → extracts user data from token and authenticates.
• Eliminates server storage but token revocation and blacklisting are challenging.

API Key Authentication

• Used primarily for machine-to-machine communication.
• Client generates API key on platform → key is used in headers or requests programmatically.
• Ideal for enabling third-party API usage without user credentials.

OAuth 2.0 and OpenID Connect (OIDC)

• OAuth 2.0 addresses authorization delegation: users permit one app to access resources of another app securely without sharing passwords.

• Initial solutions involved dangerous password sharing; OAuth introduced tokens with scoped permissions.

• Four main entities:

  • Resource Owner: User owning the data
  • Client: Application requesting access
  • Resource Server: Server hosting the resources
  • Authorization Server: Issues access tokens after authentication.

• OAuth 2.0 flows tailored to app types:

  • Authorization Code Flow (server-side apps)
  • Implicit Flow (now discouraged for browsers)
  • Client Credentials Flow (machine-to-machine)
  • Device Code Flow (limited input devices like smart TVs)

• OpenID Connect extends OAuth 2.0 by adding an ID token (JWT format) providing authentication information about the user, enabling secure third-party login flows ("Sign in with Google/Facebook").

5. Authorization: Controlling User Permissions

Authorization determines what an authenticated user can do:

• Users have different permissions (e.g., read-only vs. admin).
• Multi-tenant systems require fine-grained access control per user or role.

Role-Based Access Control (RBAC)

• Common pattern assigning roles with associated permissions.

• Roles examples: User, Admin, Moderator.

• Permissions assigned per resource type and operation:

  Role	Notes Permissions	Dead Zone Permissions
  User	Read, Write, Delete	None
  Admin	Read, Write, Delete	Access Allowed

• Workflow:

  • User signs up and is assigned a role.
  • Upon authentication, role info is retrieved from token or server.
  • Server checks role permissions before processing requests.
  • Access violation results in HTTP 403 Forbidden.

6. Security Best Practices in Authentication and Authorization

Error Messages

• Avoid detailed error messages during login (e.g., “user not found” or “incorrect password”).
• Use generic error messages like “authentication failed” to avoid information leakage that aids attackers.

Timing Attacks

• Attackers can infer valid/invalid usernames by measuring response time differences (password hashing takes longer).
• Mitigations:
  • Use constant-time comparison functions to ensure uniform execution time.
  • Insert artificial response delays for invalid usernames to mask timing differentials.

7. Summary: When to Use Which Authentication Type

Using hybrid approaches (stateful for web, stateless for APIs) can blend benefits of both.

8. Emerging and Future Trends

• Passwordless Authentication: Relying on hardware-backed credential storage (e.g., WebAuthn).
• Decentralized Identity: Blockchain-based identity management that offers user control.
• Behavioral Biometrics: Patterns like typing rhythm or mouse movement for continuous authentication.
• Post-Quantum Cryptography: Algorithms resistant to future quantum computing attacks.

This overview equips backend engineers with foundational and advanced understanding to confidently design, implement, and secure authentication and authorization systems in diverse modern environments.