Developer tools · JWT decoder
ID Token vs Access Token: Why an OpenID Connect JWT Is Not an API Key
· Background
jwt oauth authentication
Both may be JWTs from the same provider, yet they answer different questions. This post explains what an ID token and an access token each contain, who should consume them, and how to tell them apart by decoding.
The API rejects a token that looks perfectly valid — because it was never meant for the API
An API can reject a well-formed, correctly signed token because that credential was issued for another consumer and purpose. “It is a JWT” describes a possible format, not permission to send it everywhere. ID tokens and access tokens answer different questions in an identity flow.
ToolAcre can expose header and payload patterns that support debugging, but it cannot authenticate the token or validate an OpenID Connect profile. The final classification must come from the provider contract, issuance flow and trusted verification result rather than visual inspection.
ID-token claims may suggest identity use; this generic decoder does not validate an OpenID Connect profile
An ID token communicates authentication information to the client that requested sign-in. Depending on the profile, visible claims may include a nonce, authentication time, authentication methods or a hash related to another token. Those fields are not generic API authorization grants.
The decoder treats `auth_time` as a time-shaped field and displays other names as application-specific unless they are among its core seven. It does not validate nonce, `at_hash`, `amr` or client audience semantics. A readable identity payload remains untrusted until the client validates it correctly.
Access tokens may be JWTs or opaque; only three-part JWTs fit this decoder
An access token authorizes calls to a resource server under an authorization system. It may be a JWT or an opaque string. Only the three-part signed shape fits ToolAcre’s route; an opaque token has no general client-side structure to decode and should not be forced through this tool.
A JWT access token can carry audience and scope information, but those values need authenticated verification and resource policy. The browser panel does not implement a resource server and cannot tell whether a scope permits a particular operation.
Refresh tokens — usually opaque, never meant to be decoded, and never to be sent to an API
A refresh token supports obtaining replacement access credentials under provider rules. It is commonly opaque and is not intended for resource APIs. It is also a high-value credential, so pasting it into a decoder creates risk without a reliable diagnostic benefit.
Do not infer that every token-shaped value should be decoded. Use provider tooling and controlled logs for refresh failures. ToolAcre’s explicit warning against production tokens applies with particular force here, and its three-segment parser offers no refresh operation.
Audiences differ — the client ID in an ID token versus the resource in an access token
Audience is a strong clue because the intended consumer differs. An ID token often targets the client, while an access token targets a resource. Exact identifiers and representations depend on the provider and profile, so this article does not invent a universal string pattern.
A header `typ` can also provide an explicit label, but it remains token-controlled data until verification. ToolAcre warns only when a string `typ` differs from `JWT`; it does not recognize every profile label or turn one into an authorization decision.
Worked example: compare visible fields without treating them as proof of token type
Decode two synthetic examples: one carrying client-oriented authentication claims and one carrying a resource audience and scope. Record the differences in `aud`, `typ` and payload names. The exercise teaches what to ask the issuer, not how to prove either example’s identity.
A fabricated token can copy the same labels, and a real token can use provider-specific conventions. Confirm type from the issuance response and documentation, then validate it with the intended consumer. The decoder’s output is supporting evidence, never the deciding authority.
What this does not cover — the OAuth flows that issue these tokens, which are a separate topic
This comparison does not explain the authorization-code, device or other flows that issue tokens. It also does not cover provider-specific validation steps, opaque access-token introspection or refresh rotation. Those subjects depend on the selected ecosystem and deployment.
Keep the immediate debugging question narrow: which credential did the client receive, who is its intended consumer, and which trusted component validates it? Answering those three questions prevents a generic JWT shape from erasing protocol roles.
Takeaway: look at aud and typ before you send — the ToolAcre JWT decoder lets you check which kind of token you are holding
Look at audience and type before sending a token, but do not trust either field until verification succeeds. An ID token belongs at its client validation boundary; an access token belongs at its resource server. A refresh token belongs in the provider’s refresh process, not at an API.
ToolAcre helps read safe three-part examples and makes no claim to classify or validate them. Use it to spot likely mistakes, then let the documented flow and independently configured verifier establish the credential’s real purpose.