Authentication & Authorization Architecture · Authorization at Scale
Service-to-Service Authentication
Identity for workloads: client credentials, mTLS, workload identity and token exchange.
Internal calls need authentication too — "inside the network" isn't a security boundary (zero trust). Options: OAuth 2.0 client credentials (service gets its own access token), mTLS with short-lived certificates (often via a service mesh and SPIFFE IDs), and cloud workload identity (Kubernetes service accounts federated to cloud IAM, no static keys). To act on a user's behalf downstream, use token exchange (RFC 8693) rather than forwarding the user's token everywhere.
# Kubernetes workload identity (concept)
ServiceAccount orders-api ──(projected OIDC token)──► cloud IAM role 'orders-api'
└─ permissions: read S3 bucket 'invoices'
# No long-lived access keys in the pod; tokens rotate automatically.
# Token exchange (RFC 8693)
POST /token grant_type=urn:ietf:params:oauth:grant-type:token-exchange
subject_token=<user access token> audience=billing-api scope=invoices:read
Common pitfalls
- Shared static API keys between services.
- Forwarding broad user tokens to every downstream service.
- Plaintext internal traffic in zero-trust environments.
Key points
- Every workload gets an identity
- Client credentials, mTLS, workload identity
- Token exchange for delegated calls
Further reading: SPIFFE overview
Practice questions
Why avoid long-lived cloud access keys in containers?
Answer
They're easily leaked (images, logs, env dumps) and rarely rotated; workload identity issues short-lived credentials bound to the workload automatically.
What problem does OAuth token exchange solve?
Answer
It lets a service obtain a new, narrowly scoped token for a downstream API on behalf of the user, instead of forwarding the original broad token everywhere.
Open in the app to mark lessons complete, take notes and track your progress.