No: an ID token tells the client about the user’s authentication, while an API should accept only an access token intended for that API.
Two tokens answer different questions
The frontend uses an ID token to learn the result of an OpenID Connect authentication. The API accepts an access token issued for that API. Similar JWT shapes do not make the tokens interchangeable: purpose, audience, required claims, and validation context differ. OpenID Connect Core defines OpenID Connect as an identity layer and describes the ID token’s role in authentication.
What the browser validates
OpenID Connect defines the ID token as claims about authentication and specifies validation of issuer, audience, expiry, and nonce where the authorization request used one. Clients should verify the ID token signature by default. OpenID Connect Core describes ID token purpose and validation requirements, including the narrow case where a client may rely on TLS server validation for an ID token returned directly from the token endpoint. That exception does not apply to arbitrary tokens submitted to an API.
When an authorization server issues OAuth 2.0 access tokens as JWTs using the RFC 9068 JWT profile for OAuth 2.0 access tokens, resource servers validate them according to that profile. RFC 9068 says it defines a profile for issuing OAuth 2.0 access tokens in JWT format and that JWT access tokens complying with that profile must be signed. Other deployments may use opaque access tokens with introspection or different JWT conventions. A token minted for client UI display can therefore be validly signed and still be invalid at the API.
What the API validates
After login, the browser receives an ID token with audience web-client and an access token with audience orders-api. It may use ID-token claims to display the signed-in name. For GET /orders, it sends the access token. The API rejects the ID token because orders-api is absent from its audience, then evaluates scope and application policy before returning an order. OpenID Connect Core explains the client-side authentication role of ID tokens, while RFC 9068 describes validation expectations for resource servers consuming access tokens that follow that JWT profile.
Walk one request across the boundary
Configure separate token-handling rules for clients and resource servers. Pin acceptable issuers and algorithms, and obtain verification keys from a trusted distribution mechanism such as issuer metadata or JWKS when your deployment supports it. Require the intended audience, and check time claims with a small documented clock skew. The browser binds the authentication response to its request with state and nonce. The API treats sub as an identifier, not proof that every object belongs to that subject.
Avoid claim-shaped authorization
Do not authorize from display claims such as email, name, or a UI role copied into an ID token unless the application has deliberately defined and governed that contract. Access-token scopes are also only a ceiling; object-level policy still decides whether the caller may read order 42. Logging should identify token type and failed check class without recording the credential.
A token contract worth writing down
Before implementation, write down these decisions: which component consumes each token; exact accepted issuer and audience; required signature algorithms; nonce and state ownership; scope-to-operation mapping; object authorization after token checks; key rotation and clock-skew tests. Turn each decision into an automated assertion or a rehearsal step. A design that exists only in prose will drift as callers, operators, and dependencies change. Record the owner and the signal that proves the control still works.
Make the acceptance test concrete
Create a test record for this boundary that names the starting state, the action taken, and the expected state afterward. The evidence should show which component consumes each token, exact accepted issuer and audience, and required signature algorithms under normal conditions. Then repeat the exercise while a dependency is delayed and while a relevant change happens concurrently. Capture timestamps and immutable identifiers rather than screenshots alone. A reviewer should be able to decide from the record whether the control worked, how long uncertainty lasted, and which owner must respond when it does not. Add the test to the release or operational cadence instead of treating the first successful run as permanent proof.
Audit one endpoint today
Pick one API endpoint and add a test presenting a correctly signed ID token with the wrong audience. The endpoint should return an authentication error before business authorization runs.
Save redacted examples of the expected issuer, audience, token purpose, and rejected token type beside the verifier configuration. Record a failed ID-token-to-API request as well as a valid access-token request so the boundary remains visible during incident diagnosis.
Reviewed: 2026-09-06.
Engineering re-check cadence: review this decision again on 2026-12-05, or sooner if the protocol, dependency, traffic shape, or threat model changes.
Sources are linked throughout this guide. Product capabilities can change; consult the linked documentation for your deployment.
Read our editorial approach ↗