API Gateway Authentication: Securing Your Services at the Edge

Every request that reaches your backend must prove it belongs there. The question is where you enforce that proof — at each individual service, or once at the gateway. API gateway authentication centralizes identity verification at the edge, reducing duplication and giving you a single chokepoint for security policy.

Gateway-Level vs Service-Level Auth#

There are two schools of thought on where authentication lives.

Gateway-level authentication means the gateway validates credentials before the request ever touches a downstream service. Services receive pre-verified context (a user ID, scopes, roles) via headers. This keeps business services lean and eliminates redundant auth logic.

Service-level authentication pushes verification into each microservice. Every service independently validates tokens. This is more resilient to gateway compromise but introduces duplication, version drift, and latency from repeated cryptographic checks.

Most production architectures use a hybrid approach: the gateway handles coarse-grained authentication (is this token valid?) while services handle fine-grained authorization (can this user access this resource?).

JWT Validation at the Gateway#

JSON Web Tokens are the most common credential format for gateway auth. The gateway validates the JWT signature, checks expiration, and extracts claims — all without calling an external service.

Key validation steps:

• Signature verification — confirm the token was signed by a trusted issuer using RS256 or ES256
• Expiration check — reject tokens past their exp claim
• Audience validation — ensure the aud claim matches the expected API
• Issuer validation — verify the iss claim against a known identity provider
• Scope extraction — pull scopes or roles from claims and forward them downstream

The gateway fetches the issuer's public keys from a JWKS (JSON Web Key Set) endpoint and caches them. Key rotation happens transparently — the gateway periodically refreshes the JWKS.

Client --> Gateway (JWT validation) --> Service (receives X-User-Id, X-Scopes headers)

Stateless validation is the main advantage: no database lookup, no session store, no external call on every request.

API Key Management#

API keys are simpler than JWTs but serve a different purpose. They identify the calling application rather than a specific user.

Best practices for API key management:

• Hash keys at rest — store only SHA-256 hashes, never plaintext
• Scope keys narrowly — each key should grant access to specific endpoints or resources
• Set expiration dates — force rotation on a schedule (90 days is common)
• Use prefixes — a prefix like ck_live_ makes it easy to identify key type and environment
• Track usage — log every key's request count, last used timestamp, and originating IP

The gateway looks up the hashed key, resolves the associated tenant and permissions, and injects that context into downstream headers.

OAuth2 Token Introspection#

For opaque tokens (non-JWT), the gateway cannot validate locally. It must call the authorization server's introspection endpoint (RFC 7662) to check token validity.

Gateway --> POST /oauth2/introspect { token: "abc123" } --> Auth Server
         <-- { active: true, scope: "read write", client_id: "app1" }

Introspection adds latency — every request requires a network call. Mitigate this with:

• Short-lived caching — cache introspection results for 30–60 seconds
• Token exchange — swap opaque tokens for JWTs at the gateway so downstream validation is stateless
• Circuit breakers — fail open or closed depending on your security posture if the auth server is unreachable

Rate Limiting per API Key#

Rate limiting protects your backend from abuse and ensures fair usage across tenants. The gateway is the natural enforcement point.

Common strategies:

Rate limits are typically per API key or per user, tracked in a fast store like Redis. The gateway returns 429 Too Many Requests with a Retry-After header when limits are exceeded.

Headers like X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset give clients visibility into their quota.

IP Whitelisting#

IP whitelisting restricts access to known, trusted addresses. It is a blunt instrument but effective for B2B integrations where partners have static IPs.

Implementation considerations:

• Maintain allow-lists per API key or per route
• Support CIDR notation for ranges (e.g., 203.0.113.0/24)
• Account for proxies — use X-Forwarded-For carefully and trust only known proxy hops
• Combine with other auth methods — IP whitelisting alone is not sufficient for security

The gateway checks the source IP against the allow-list before any further processing. Denied requests get a 403 Forbidden immediately.

Mutual TLS (mTLS)#

Standard TLS authenticates only the server. Mutual TLS requires the client to present a certificate too, proving its identity cryptographically.

How mTLS works at the gateway:

1. Client initiates TLS handshake and presents its certificate
2. Gateway validates the client certificate against a trusted Certificate Authority (CA)
3. Gateway extracts the client identity from the certificate's Common Name (CN) or Subject Alternative Name (SAN)
4. Request proceeds with verified client identity

mTLS is the gold standard for service-to-service authentication in zero trust architectures. It is harder to set up for external clients due to certificate distribution challenges.

The gateway terminates mTLS and can forward the client identity via headers like X-Client-Cert-CN to downstream services.

Tools and Platforms#

Kong Gateway#

Kong is an open-source API gateway built on NGINX. It supports authentication via plugins:

• JWT plugin — validates JWT signatures and extracts claims
• Key Auth plugin — API key validation with consumer mapping
• OAuth2 plugin — full OAuth2 server or token introspection
• mTLS plugin — client certificate validation
• Rate Limiting plugin — configurable per consumer, route, or service

Kong's plugin architecture makes it easy to compose auth policies per route.

AWS API Gateway#

AWS API Gateway offers managed authentication:

• Cognito authorizers — validate JWTs issued by Amazon Cognito
• Lambda authorizers — run custom auth logic in a Lambda function
• IAM authorization — use AWS SigV4 for service-to-service calls
• API keys + usage plans — built-in key management with throttling
• WAF integration — IP whitelisting and request filtering via AWS WAF

Lambda authorizers are the most flexible — you can implement any auth scheme and cache the result for a configurable TTL.

Other Notable Tools#

• Envoy — mTLS-native proxy used in service meshes (Istio)
• Traefik — middleware-based auth with ForwardAuth support
• Apigee — Google's full-lifecycle API management platform
• Tyk — open-source gateway with built-in OAuth2 and key management

Putting It All Together#

A production API gateway authentication stack typically layers multiple mechanisms:

Request
  |-> IP whitelist check (fast reject)
  |-> Rate limit check (protect backend)
  |-> mTLS or API key validation (identify caller)
  |-> JWT validation or token introspection (authenticate user)
  |-> Scope/role extraction (prepare authorization context)
  |-> Forward to upstream service

Each layer is a filter. Requests that fail any check are rejected early, saving compute for legitimate traffic.

The gateway handles authentication (who are you?). Downstream services handle authorization (what can you do?). This separation keeps both layers clean and independently testable.

---

That wraps up article #278 on Codelit. If you found this useful, explore our growing library of 278 articles covering system design, infrastructure, and software engineering — browse all posts here.