How does an API Gateway offload authentication and authorization so that individual backend microservices don't each have to implement their own login/token-checking logic, and what does the gateway typically pass downstream once a request is verified?

## How the gateway proves who a caller is Authentication offloading means moving the work of proving who a caller is out of every individual microservice and into the single edge layer every request must pass through — the API Gateway. Mechanically this usually works one of two ways. - **With self-contained tokens (JWTs)**, the gateway holds the issuer's public key (or a JWKS endpoint it periodically fetches) and, on each request, verifies the token's cryptographic signature, checks the expiry (`exp`) claim, and checks the issuer/audience claims match what's expected — all without any network call, which keeps this fast (sub-millisecond, CPU-bound). - **With opaque tokens** (a random string that means nothing on its own, common with OAuth2 access tokens issued by systems like **Keycloak** or **Okta**), the gateway must call an introspection endpoint on the auth server to ask 'is this token still valid, and for whom' — this is a network round trip on the hot path, so it's often cached briefly (30-60 seconds) to avoid hammering the auth server on every request. Once verification succeeds, the gateway typically strips the raw `Authorization` header before forwarding and instead injects internal, trusted headers like `X-User-Id`, `X-Roles`, or `X-Tenant-Id` that the downstream service reads directly, skipping signature verification entirely because it trusts the gateway as the enforcement boundary. ## Why it exists This exists because re-verifying tokens in every service is both wasteful and risky. - **Wasteful** because ten services all parsing and validating the same JWT on the same request is pure duplicated CPU work and duplicated code to keep patched and correct. - **Risky** because security logic copy-pasted across a dozen codebases inevitably drifts — one service updates its JWT library to fix a vulnerability, another doesn't, and now there's an inconsistent security posture across the fleet. Centralizing at the gateway means there's exactly one place where the 'is this caller who they claim to be' logic lives, one place to patch, one place to audit. ## The trade-off: trust boundary and blast radius The trade-off is a shift in trust boundary and blast radius. - Every downstream service must now unconditionally trust the gateway's injected headers, which means the network path between the gateway and the backend services must be locked down (private network, mTLS, or at minimum non-spoofable — a service directly reachable from outside the gateway would let an attacker forge `X-User-Id` headers and impersonate any user). This is why gateway-fronted architectures usually also firewall backend services so they're unreachable except through the gateway. - There's also a **coupling cost**: if the gateway's auth logic has a bug or an outage, authentication for the entire system is down, even though every backend service is individually healthy — the classic single-point-of-failure trade against the benefit of centralization. - And **coarse vs. fine-grained authorization** has a real split: the gateway can cheaply enforce 'does this role have any access to `/admin/*`' but it usually cannot enforce 'can user 42 edit order 917' because that requires domain data (who owns order 917) that only the order service has — pushing that logic into the gateway would leak business knowledge into infrastructure and recreate a monolith at the edge. ## Failure modes in production Failure modes in production include: 1. **Clock skew** between the token issuer and the gateway causing valid tokens to be rejected as expired or not-yet-valid; 2. **A JWKS key rotation** that the gateway hasn't refreshed yet, causing a spike of false 401s right after the auth server rotates signing keys; 3. **The introspection-cache-staleness problem**, where a token that was just revoked (user logged out, or was suspended) is still accepted by the gateway for up to the cache TTL because it hasn't re-checked with the auth server yet — a real security/UX trade-off that teams tune deliberately. ## Where you have seen it A concrete real-world example: **Kong Gateway's** JWT and OAuth2 plugins do exactly this — they validate the incoming token at the plugin layer before the request is proxied to the upstream service, and inject consumer identity as headers/context that the upstream can read. **AWS API Gateway** offers the equivalent via Lambda authorizers or built-in Cognito/JWT authorizers in front of API routes, so a Lambda function serving business logic never has to parse a JWT itself — API Gateway has already validated it and passed the claims through in the event payload.