How would you share authentication across 50 microservices?
Share authentication across 50 microservices using a stateless JWT-based model with an API Gateway, a centralized authentication service (IdP), and asymmetric signing (RS256) for token validation, eliminating the need for a central session store and enabling independent service scaling.
In a microservices architecture with 50 services, sharing authentication requires a distributed, stateless approach. The core pattern is to use an API Gateway as the single entry point for all client requests, which validates incoming JSON Web Tokens (JWTs) issued by a centralized Identity Provider (IdP). The gateway then forwards the request (with the JWT) to downstream services. Each microservice validates the JWT's signature locally using the IdP's public key (via JWKS) without calling a central authentication service per request, ensuring high scalability and low latency.
The recommended architecture combines four layers: (1) API Gateway (e.g., Kong, NGINX, or Envoy) for edge authentication, rate limiting, and request routing; (2) a dedicated IdP (e.g., Keycloak, Auth0, Ory Hydra) to issue and manage tokens; (3) asymmetric (RS256) JWTs, where the IdP signs with a private key and microservices verify with a public key distributed via a JWKS endpoint; and (4) optional mutual TLS (mTLS) inside a service mesh (e.g., Istio) for internal service-to-service authentication. This design avoids the anti-pattern of microservices calling a central 'user service' on every request, which would become a bottleneck and single point of failure.
- 1
Asymmetric signing (RS256): Private key stays with the IdP; public keys distributed via JWKS. Rotate keys without redeploying all 50 services.
- 2
Stateless validation: Microservices validate JWTs locally using cached public keys. No network calls to a central authentication service, resulting in O(1) latency per request.
- 3
API Gateway responsibility: Offloads authentication, token forwarding, and optional token transformation from individual services, keeping them lean.
- 4
Service mesh for internal security: Use mTLS (e.g., Istio) to secure service-to-service communication, especially when JWTs are propagated across internal calls.
- 5
Refresh token handling: Keep refresh tokens in the gateway or a separate session store (Redis) to allow logout; do not expose refresh tokens to downstream services.
- 6
Token propagation: Forward the original JWT from gateway to downstream services; each service can still validate the token locally, maintaining trust without re-authenticating.
- 7
Revocation strategy: Short-lived access tokens (e.g., 15 minutes) combined with refresh token revocation; for immediate revocation, use a token blacklist (shared Redis) checked at the gateway, not inside each service.