Security, Gateways & Intermediaries

Navigating the zero-trust reality, AuthN vs. AuthZ, JSON Web Tokens (JWT), and the architectural role of API Gateways.

v1.0.0 Updated: September 08, 2026

The Zero-Trust Reality

Historically, network security relied on a “castle-and-moat” architecture: firewalls protected the perimeter, and any service inside the network was inherently trusted. In modern, distributed engineering, the perimeter is dead.

Every API, even internal microservices communicating within the same virtual private cloud (VPC), must operate under a Zero-Trust model. Every single request must be explicitly authenticated, authorized, and validated before execution.

Authentication (AuthN) vs. Authorization (AuthZ)

A critical distinction in system design is separating identity from permissions.

Authentication (AuthN): Proving who the client is (e.g., logging in via OIDC or providing an API key).
Authorization (AuthZ): Determining what the authenticated identity is allowed to do (e.g., checking if the user has the admin role required to execute DELETE /users/123).

JSON Web Tokens (JWT)

To maintain the statelessness required by REST, modern APIs frequently use JSON Web Tokens (JWT) for authorization. A JWT is a Base64-encoded string containing a JSON payload and a cryptographic signature.

Because the token is cryptographically signed (usually via HMAC or RSA) by the issuing authorization server, the receiving API can independently verify the token’s authenticity by checking the signature, completely eliminating the need to query a central database for every single request.

🛑

Security Warning: A standard JWT is signed, but not encrypted. Anyone who intercepts a JWT can easily decode the Base64 payload and read its contents. Never place sensitive information (like passwords, social security numbers, or internal routing IPs) inside a JWT payload.

The API Gateway Pattern

As a system scales from a monolith to dozens of microservices, exposing each service directly to the public internet creates a massive attack surface and forces every service to implement its own security logic.

An API Gateway acts as a singular, unified entry point (a reverse proxy) for all incoming client requests.

The Gateway offloads critical, non-business logic from the downstream microservices:

TLS Termination: Decrypting HTTPS traffic at the edge.
Rate Limiting & Throttling: Preventing DDoS attacks or abusive clients by capping requests (e.g., 100 requests per minute per IP).
Authentication Enforcement: Rejecting requests lacking a valid JWT before they ever reach the internal network.
Routing & Load Balancing: Directing traffic to the appropriate service based on the URI path.

Test Your Understanding

Q:An API uses stateless JWTs for authorization. An administrator discovers a malicious user and deletes their account in the central database. However, the malicious user's JWT does not expire for another 12 hours, and they continue making successful API requests. Why is this happening, and how do you fix it? Reveal ▾

This is the fundamental architectural tradeoff of stateless tokens. Because the downstream APIs verify the JWT mathematically via its signature rather than checking the database, they do not know the user was deleted. To fix this while preserving performance, engineers implement a Token Revocation List (Blacklist) at the API Gateway level (often backed by an ultra-fast in-memory datastore like Redis). The Gateway briefly checks the Redis cache to ensure the token hasn’t been revoked before allowing it through to the stateless APIs.

Further Exploration

← Previous

API Design Principles & Evolution