Clarify goals & constraints
- Securely propagate identity and least-privilege across ~100s microservices, low latency, support IAM, auditing, and fast revocation.
Token formats: JWT vs opaque
- JWT (self-contained): good for low-latency local auth checks (no network call), contains claims, but risks token bloat and stale claims; must be signed (RS256) and short-lived.
- Opaque (reference) tokens: small, tunable, requires introspection endpoint which centralizes revocation and claim freshness; preferred for internal calls where revocation/fine-grained claims are critical.
Token exchange patterns
- Use OAuth 2.0 token exchange (RFC 8693) at a trusted Token Broker: client token -> service-specific downstream token containing minimal scopes/claims.
- Authenticate service-to-service with mTLS + short-lived service tokens (SPIFFE/SPIRE) for strong mutual auth.
- Option: forward original user identity as a lightweight subject token + service-bound opaque token for authorization.
Refresh & revocation
- Make access tokens very short-lived (minutes). Use refresh tokens only to the client-authenticated auth server.
- For services, prefer short-lived exchanged tokens; implement central introspection and a revocation cache (push invalidation via pub/sub to sidecars/edge gateways) to minimize stale acceptance.
- Support immediate revocation by maintaining a compact revocation stream (Kafka/Redis) and hot cache invalidation in gateways/sidecars.
Minimize token bloat
- Use opaque/reference tokens or only include essential claims (sub, scopes, aud, exp).
- Avoid embedding large role lists; instead include role IDs and resolve in-service or via PDP.
- Pass tokens in Authorization header only; avoid extra headers. For intra-cluster, use mTLS + SPIFFE SVIDs to avoid JWTs in every request.
Enforcing fine-grained permissions
- Push coarse-grained allow/deny to API gateways/sidecars (Envoy ext_authz) using a policy service for speed.
- For fine-grained business rules, use a PDP/PAP or policy-as-a-service (e.g., OPA, PDP behind gRPC) to evaluate attributes (user, resource, action, context).
- Implement authorization middleware in each service that:
- Validates token (signature/introspection)
- Extracts minimal claims
- Calls local policy engine or cached policy decision client
- Cache policy decisions with TTLs; invalidate on policy change via control plane.
Operational patterns & trade-offs
- Central token broker + introspection eases revocation and claim freshness, at cost of network hop — mitigate with highly available caches and local JWT verification when safe.
- Sidecar model (Envoy + ext_authz) centralizes enforcement and scales well; service-level policy for domain-specific checks.
- Monitoring: audit logs for auth decisions, latency SLOs for token-introspection and PDP.
Example stack: Identity Provider (OIDC) -> Token Broker (OAuth token exchange) -> Envoy sidecar (mTLS + ext_authz calling OPA/Introspect) -> Service with light middleware for business checks.
This balances security (revocation, least privilege), latency (local verification & caching), and manageability (central policy and token lifecycle).
