Skip to content
AI360Xpert

OAuth2 & JWT

OAuth2 & JWT architecture
OAuth2 & JWT architecture

Overview

OAuth 2.0 is an authorization framework that lets a third-party application access a user's resources without knowing their password. JSON Web Tokens (JWT) are a compact, cryptographically signed format for transmitting those access claims securely between parties. Together, they form the backbone of modern API security.

🧠 Mental model: OAuth2 is the process of getting a valet key. You give the valet a special key that only opens the doors and starts the engine, but doesn't open the trunk or glovebox (scope). JWT is the physical valet key itself - it has a stamp on it (signature) proving it is authentic.

Key Concepts

OAuth 2.0

OAuth separates the role of the client (the app wanting access) from the resource owner (the user). Instead of giving the app their password, the user authenticates with an Authorization Server (e.g., Google), which issues an Access Token to the app. The app presents this token to the Resource Server (the API) to prove it has permission.

JWT (JSON Web Token)

An Access Token is often implemented as a JWT. A JWT is a Base64-encoded string with three parts separated by dots (header.payload.signature):

  • Header: Specifies the algorithm used to sign the token (e.g., HMAC or RSA).
  • Payload (Claims): Contains the actual data, such as user ID, roles, and expiration time. It is readable by anyone who intercepts it.
  • Signature: Created using a secret key held by the server. It guarantees that the payload hasn't been tampered with.

Stateless Auth

Because the JWT contains its own signature, the backend API does not need to query a database to verify if the token is valid - it only needs to check the cryptographic signature using a public key. This makes JWTs stateless and highly scalable.

Aspect Session Cookies (Stateful) JWTs (Stateless)
Storage Server memory/DB + Client cookie Client only (localStorage or secure cookie)
Verification Database/Redis lookup per request CPU-bound crypto verification
Scalability Requires shared session store across instances Trivially scales across instances without a DB
Revocation Easy (delete from DB) Hard (requires blacklists or short expirations)

Trade-offs

JWTs are excellent for distributed systems because they eliminate the database lookup for authentication. However, their statelessness is their biggest flaw: you cannot easily revoke a JWT before it expires. If a user logs out or is banned, their valid JWT will still work until its expiration time. The solution is to use short-lived Access Tokens (e.g., 15 minutes) paired with long-lived Refresh Tokens that are checked against a database.

Interview Tips

  • If asked how to secure an API in a microservices architecture, propose an API Gateway that validates the JWT signature and forwards the payload claims to downstream services.
  • Never store sensitive data (like passwords or PII) in a JWT payload; it is Base64 encoded, not encrypted, and can be easily decoded by anyone.
  • Address the revocation problem explicitly: "We will use short-lived JWTs (15 min) for access and a database-backed refresh token to allow secure logouts/bans."

Summary

  • OAuth2 is a framework for delegated authorization without sharing passwords.
  • JWT is a standard format for signed tokens containing claims.
  • JWTs are stateless: they are verified via cryptography, avoiding database lookups on every request.
  • Because they are stateless, JWTs are very difficult to revoke before they expire.
  • The standard pattern uses short-lived JWT Access Tokens and database-backed Refresh Tokens.