Identity & Access Management

API & Service-to-Service Authentication

Once a call has no human user behind it, authentication changes shape entirely: API keys, OAuth2 Client Credentials, mTLS, and workload identities (SPIFFE/SPIRE) are the tools for proving "which service is this, really" between machines.
  • API keys are simple bearer secrets that identify a caller, not a user — easy to leak (committed to source, printed in logs), typically do not expire on their own, and carry no scoping unless the issuing service builds it in
  • The OAuth 2.0 Client Credentials grant is the standard for service-to-service calls with no human in the loop: the calling service authenticates as itself (client id + secret, or a certificate) and receives a scoped, short-lived access token
  • mTLS authenticates both sides of a TLS connection via certificates, not just the server — the norm inside a service mesh (Service Mesh), where every workload is issued its own identity certificate at startup
  • SPIFFE/SPIRE issues short-lived, cryptographically verifiable workload identities (SVIDs) tied to what a workload is rather than where it is running — solving "which service am I actually talking to" in an environment where IPs and hostnames are ephemeral
  • A service mesh's sidecar proxies can enforce mTLS and authorization policy transparently at the network layer, so individual services don't each reimplement their own auth
  • Blast radius is the deciding factor: a leaked shared API key compromises every caller using it at once; per-caller credentials or short-lived workload identities contain a single compromised credential to a single caller
Sidecar mTLS handshake between two workloads with SPIFFE IDs
Neither service handles certificates directly — the sidecar terminates mTLS and hands the application plain HTTP over a verified identity
API key vs OAuth Client Credentials vs mTLS
API keyOAuth2 Client CredentialsmTLS
IdentifiesA caller (often coarse)A registered client applicationA workload/certificate identity
ExpiryUsually none, unless built manuallyShort-lived access token (minutes-hours)Certificate lifetime, often hours with auto-rotation
RevocationManual key rotation/deletionRevoke the client or let the token expireRevoke/rotate the certificate; short lifetime limits exposure
Typical useSimple internal tools, third-party API accessService-to-service behind a token-based API layerService mesh, zero-trust internal networks
Sources
  • API Security in ActionCh. 11 — Securing Service-to-Service APIs
  • Zero Trust Networks (2nd ed.)Ch. 4 — Workload Identity