OAuth 2.0 Client Credentials

The client authenticates directly to the authorization server's token endpoint using its client_id and client_secret (or a private key assertion). This bypasses the redirect-based user consent flow entirely.

• Flow: Client POSTs credentials to /token endpoint
• Response: Receives an access_token and optional refresh_token
• No User Context: The token represents the client application itself, not an end-user

This grant is strictly for confidential clients capable of securely storing credentials. Public clients, like single-page applications, cannot use this flow.

• Credential Storage: Secrets must be stored in a secure backend, never in client-side code
• Alternative Authentication: For high-security environments, use private_key_jwt or mutual TLS (tls_client_auth) instead of a shared secret
• Client Type: Server-side web apps, daemons, and backend services

The access token's permissions are bounded by the scopes requested during the grant and the policies attached to the client registration.

• Least Privilege: Request only the specific scopes needed for the downstream API call
• No Refresh Tokens: By default, refresh tokens are not issued; the client simply requests a new access token when the old one expires
• Example Scope: api:read, service:admin, events:publish

To prevent token replay, the Demonstration of Proof-of-Possession (DPoP) extension binds the access token to a public/private key pair held by the client.

• Mechanism: Client generates a DPoP proof JWT for each request
• Binding: The access token contains a hash of the public key (jkt)
• Result: Even if a token is exfiltrated, it cannot be replayed without the corresponding private key

In dynamic environments like Kubernetes, static secrets are a liability. The client credentials flow integrates with workload identity systems to eliminate the Secret Zero Problem.

• SPIFFE/SPIRE: Exchanges a SPIFFE Verifiable Identity Document (SVID) for an OAuth token
• Cloud Metadata: Exchanges a signed identity document from AWS, GCP, or Azure
• Benefit: No long-lived secrets to rotate or leak; authentication is based on the platform's attested identity

Resource servers validate the access token's liveness and rights by calling the authorization server's introspection endpoint.

• Introspection: Returns metadata (active, scope, client_id, exp) about the token
• Revocation: Clients signal a token is no longer needed via the revocation endpoint
• Caching: Resource servers should cache introspection results for the token's lifetime to reduce latency

A cryptographically verifiable identity assigned to a specific software process, container, or service rather than to a physical machine or human user. Workload identity is the foundation of zero trust for machine-to-machine communication.

• Decouples identity from network location (IP addresses, subnets)
• Enables fine-grained access policies per microservice or agent instance
• Typically implemented via SPIFFE SVIDs or cloud provider identity tokens

A mechanism to cryptographically bind application-layer bearer tokens to the underlying TLS connection, preventing token export and replay attacks. If a token is stolen and used on a different connection, the binding validation fails.

• Addresses the fundamental weakness of bearer tokens in OAuth 2.0
• Creates a cryptographic channel between the token and the transport layer
• Superseded in many implementations by DPoP for application-level binding