Hard20 minWeb Fundamentals
UpdatedAug 5, 2026
Edit

OAuth client credentials, scopes, audience

CONCEPTS:OAuth 2.0 Authorization

Question Variations

  • "When is client credentials the right OAuth grant?"
  • "How do scopes differ from an audience?"
  • "Why should an API validate both scope and audience?"

Why This Is Asked

This distinguishes user-delegated authorization from service-to-service authorization. Interviewers want to see whether you can choose client credentials appropriately, restrict machine tokens to the intended API and permissions, and protect the client credential as a production secret.

Key Concepts

  • Client credentials: A client authenticates as itself; there is no end-user authorization step.
  • Scopes: Permissions requested and granted to the token.
  • Audience: The resource server that is expected to accept the token.
  • Credential protection: Prefer workload identity or asymmetric client authentication over broadly shared static secrets.

Question Variations

  • “When is client credentials the right OAuth grant?”
  • “How do scopes differ from an audience?”
  • “Why should an API validate both scope and audience?”

Answers by Technology

+ Add Variant
System DesignImprove this answer ✏️

Expected Answer (OAuth 2.0 / RFC 9700)

The client credentials grant is for machine-to-machine access. The client authenticates to the authorization server as itself and receives an access token representing the client or workload, not an end user. Use it when a backend service, scheduled job, or workload needs to call an API under its own narrowly defined permissions. Do not use it to represent a user’s delegated authorization; that requires a user-facing flow such as authorization code with PKCE.

Scopes describe allowed operations, such as orders.read, while the audience identifies the resource server expected to accept the token. A resource server should validate its own audience and then enforce the scopes or permissions required for the requested operation. Tokens should be short lived and specific to one resource server where possible. Protect client authentication with workload identity, a managed identity, or asymmetric authentication in production; a static shared client secret is a credential that needs rotation and secure storage.

Why It Matters

An over-broad machine token can let a compromised service access unrelated APIs or perform destructive actions. Separating audience from scope limits blast radius and makes authorization decisions explicit.

Example Code

interface AccessTokenClaims {
  aud: string | string[];
  scope?: string;
  client_id: string;
}

export function canReadOrders(claims: AccessTokenClaims): boolean {
  const audience = Array.isArray(claims.aud) ? claims.aud : [claims.aud];
  return audience.includes('https://orders-api.example')
    && claims.scope?.split(' ').includes('orders.read') === true;
}

Common Mistakes

  • Using client credentials for a user’s request: The resulting token cannot express which user granted access or which user-specific policy applies.
  • Checking scopes but not audience: A token for another API may contain a similarly named scope and must not be accepted here.
  • Giving every workload an admin scope: A breach of one service then becomes a breach of the entire API estate.

Follow-up Questions

  • What identity does a client-credentials token represent? (Answer: The client or workload, rather than a human resource owner.)
  • Why use short-lived machine tokens? (Answer: They reduce the time a stolen token can be replayed and encourage automated credential rotation.)

References