Handbooks / Microservices / Chapter 6
Securing Microservices
7 pages · ~5 min✓ Reviewed
Builds on API Versioning and Contracts. Next up: Configuration and Feature Flags.
Auth Mental Model and Edge Authentication
1. AuthN vs AuthZ
| authN | authZ | |
|---|---|---|
| Question | Who are you? | What may you do? |
| Fails with | 401 Unauthorized | 403 Forbidden |
| Caller state | unknown or bad credentials | known, but not allowed |
2. Edge Authentication
- API gateway = the single entry point
- Credentials validated once, bad traffic rejected before services
- Also: rate limiting (429) and TLS termination
- Strips client-sent identity headers like
X-User-Idso they can't be spoofed
- Signaturevalid key
- iss / audissuer, audience
- exp / nbftime window
- Forwardidentity attached
3. Example: Bearer JWT
- Client sends the JWT in the
Authorizationheader - Gateway checks it against the IdP's JWKS endpoint
- Keys are cached, refreshed on an unknown
kid
http
GET /orders/42 HTTP/1.1 Authorization: Bearer <JWT>
gateway validates, then forwards identity
Never trust inbound identity headers
Strip X-User-Id from clients; only the gateway sets it, after the token is verified
JWT and OAuth2 Token Propagation
1. JWT and signing
- header.payload.signature, base64url-encoded
- Payload is signed, NOT encrypted: no secrets in claims
- Claims:
subissaudexpiatscope/roles - Access token 5-15 min, plus a refresh token
| HS256 | RS256 / ES256 | |
|---|---|---|
| Key | one shared secret | private signs, public (JWKS) verifies |
| Services can mint? | yes | no, verify only |
2. Flows and propagation
- Auth Code + PKCE: users and SPAs
- Client Credentials: machine-to-machine
- Avoid Implicit and Password flows
- User tokenaud=gateway
- Token ExchangeRFC 8693
- Narrow tokenaud=orders
Service-to-Service Auth and mTLS
1. mTLS and Identity
- A private network is not proof of identity
- Options: mTLS, service JWT (Client Credentials), or both
- One-way TLS authenticates only the server
- mTLS: both sides present X.509 certs, checked against a trusted CA
- Client hello
- Server certclient verifies CA
- Client certserver verifies CA
- Encrypted channel
- Identity lives in the cert: SPIFFE ID
spiffe://prod/ns/payments/sa/api - Issued by SPIRE or the mesh CA
2. Mesh and Tokens
| mTLS | JWT | |
|---|---|---|
| Proves | which service calls | which user it acts for |
| Layer | transport | request |
| Production | use both | use both |
Zero Trust and Secrets Management
1. Zero Trust
- Never trust network location
- Authenticate + authorize every request
- Assume breach
- Grant least privilege
- Identityworkload
- mTLSeverywhere
- Policyper request
- NetworkPolicydefault-deny
- Loggingcontinuous
2. Secrets
- Keep in a secrets manager: Vault, AWS Secrets Manager, K8s Secrets (encrypted at rest)
- Never in code, images or Git
- Prefer dynamic secrets: short-lived DB creds per service
- Fetch at runtime with workload identity (IAM role, service account)
- Rotate regularly; never log secrets
- Service accountidentity
- Vaultchecks policy
- DB credsTTL + lease
- Revokedon expiry
3. Mistakes
- Secrets in env vars baked into images
- One shared secret for all services
- Committed
.envfiles
Authorization Per Service
1. Where authZ lives
- Gateway: coarse authN and basic scopes only
- Every service enforces its own fine-grained authZ
- Defense in depth: the gateway can be bypassed or misconfigured
| Model | Decides by | Example |
|---|---|---|
| RBAC | role | admin, editor |
| ABAC | attributes | owner, region, time |
| ReBAC | relationships | Zanzibar-style |
- Scopes limit what a client app can do
- Roles limit what a user can do
2. Object-level and policy
- Check ownership in the service: user reads only their own order
- Missing it = BOLA/IDOR, the top API vulnerability
- Externalize policy with OPA (Rego) or Cedar, as sidecar or library
Gateway Auth Cheat Sheet
1. Status Codes and JWT Checks
| Code | Meaning |
|---|---|
| 401 | Not authenticated |
| 403 | Authenticated, not allowed |
| 429 | Rate limited |
JWT validation order
- 1Signature
- 2alg allow-list
- 3iss
- 4aud
- 5exp / nbf
- 6Claimsfor authZ
2. Flows and Workload Identity
| Flow | Use for |
|---|---|
| Auth Code + PKCE | Users |
| Client Credentials | Services |
| Token Exchange | Downstream narrowing |
- mTLS: both sides present certs
- Mesh STRICT mode enforces it
- SPIFFE ID names the workload
3. Secrets and Authorization
Check yourself
A token has a valid signature and is unexpired, but its aud is 'payments'. The orders service receives it. What happens?
- It is rejected with 401, using the RFC 6750 error
invalid_token. - Some gateways answer 403, but the token is never accepted.
The orders service returns orders for the X-User-Id header that callers send. What is the bug?
- Headers are spoofable, so any caller can read another user's orders (BOLA).
- Strip it at the gateway and use the verified token
sub.
Istio PeerAuthentication is PERMISSIVE. A pod with no sidecar calls payments in plaintext. Result?
- Allowed: PERMISSIVE accepts both plaintext and mTLS.
- STRICT would reject it.