OAuth access tokens and scopes: authorize the intended resource
Distinguish access tokens, scopes and audiences in service integrations. Diagnose valid tokens rejected by the wrong API and design credential handling safely.
TL;DR: An access token carries or references authority to call a resource. The API must validate the token under its trust policy and enforce the requested operation; a valid signature or familiar scope name alone does not establish permission.
Identify the parties and the kind of token
OAuth separates the client requesting access, the authorization server issuing credentials and the resource server protecting an API. The resource owner may be a user in a delegated flow. In a client-credentials flow, the client acts under its own authorized identity rather than pretending to be a signed-in human. RFC 6749 defines these roles and the original framework; use current security guidance when selecting a flow.
An access token may be opaque to the client or represented as a structured token such as a JWT. The client should not assume every access token can be decoded. An ID token serves an OpenID Connect authentication purpose and is not interchangeable with an API access token.
The diagram omits user interaction for simplicity. The chosen grant determines what authentication, consent and redirect handling occur before token issuance.
Scope and audience constrain different dimensions
A scope describes authorized capabilities according to the issuer and API's contract. An audience identifies the intended recipient or resource. Two APIs can use the same string read while protecting completely different data. Accepting a token solely because it contains that string lets authority cross an unintended boundary.
| Property | Question for the API | Example failure |
|---|---|---|
| Issuer | Did an accepted authority issue this token? | Token comes from an untrusted tenant or issuer |
| Audience or resource binding | Is this API an intended recipient? | Token was issued for a different API |
| Validity and status | Is the token currently acceptable? | Expired or otherwise invalid token |
| Scope or role | Does it authorize this operation class? | Read-only token attempts a write |
| Resource-specific policy | Can this principal access this particular object? | Caller requests another team's deployment |
Signature verification is one part of validating a JWT access token. Opaque tokens require the supported validation mechanism for the deployment. Neither format removes the need for authorization on the requested object.
Diagnose a rejected automation request
Suppose an illustrative deployment tool obtains a token successfully but receives an authorization error when reading a release record. The engineer decodes a JWT and sees releases.read, then assumes the API is broken.
Inspect the configured issuer and intended resource, token lifetime and the API's accepted permissions. If the token was issued for the artifact service, the release API should reject it even if the scope string looks suitable. Request the correct resource through the issuer's supported flow, then verify that the client is actually allowed to receive that authority.
Do not paste the bearer token into a public decoder or incident channel. Bearer possession can be sufficient to use its authority. RFC 6750 specifies bearer-token usage and associated threats. Log a safe correlation identifier and validation reason rather than the complete credential.
If the correct token still cannot access a particular release, inspect object-level authorization. Broadening the scope to an administrator permission may mask a missing ownership relationship while granting access to unrelated projects.
Select a flow appropriate to the caller
For an interactive application, use a modern authorization-code design with the required protections, including PKCE where applicable, and exact redirect handling. For a background service, choose an appropriate workload identity or client authentication mechanism with narrowly granted authority. RFC 9700 updates OAuth security best practices and deprecates insecure patterns from older deployments.
Keep refresh tokens separate from access tokens. A refresh token requests new access credentials from the authorization server; it is not the credential to send to the resource API. Its storage and rotation policy should reflect its potentially longer-lived authority.
Short access-token lifetimes reduce some exposure but do not make token theft harmless. Combine protected storage and transport with resource restriction and a response plan for compromised clients. Secrets lifecycle covers ownership and revocation procedures.
Check the boundary in an interview scenario
A useful answer identifies who issues authority, which API consumes it and how the API decides on the specific action. Explain the failure response without exposing the credential or blindly retrying the same rejected request.
Self-check: a token has a valid signature from a trusted issuer, has not expired and includes deploy.write. It was issued for a staging-only resource. Should production accept it because the scope permits writes?
No. The intended resource and production authorization must also match. Obtain a production-authorized credential through the configured approval and identity path. A broad-sounding scope name cannot extend a token beyond the authority the issuer granted.