Hash crypto & JWT

JWT Token Type: Separate Format, Purpose, and Bearer Usage

Understand JWT format, JOSE typ headers, OAuth bearer tokens, access tokens, ID tokens, and refresh tokens without treating them as interchangeable.

By Uddhav Gopani, FounderPublished 27 September 2026Updated 29 September 2026

Ask which kind of type you mean

JWT describes a token representation, not one universal permission or login role. A question about token type might instead concern the JOSE typ header, the OAuth token_type response field or the token's intended purpose. Keep these dimensions separate when configuring a client or investigating a failed API request.

A value with dot-separated encoded sections may look like a compact token, but its appearance does not establish who issued it or where it is accepted. A parser can classify a candidate shape for debugging. The receiving system still needs to apply the correct cryptographic and application-level validation rules.

Compare the labels used at different layers

Label	What it describes	What it does not prove
JWT	A claims representation used with JOSE protection	Permission to call every API
typ	A JOSE header's application-level type hint	That the header has been verified
Bearer	A token usage method in an authorization protocol	That the token is encoded as JWT
Access token	A credential intended for a protected resource	A replacement for every identity assertion
ID token	An OpenID Connect authentication result for a client	A general-purpose API access token
Refresh token	A credential used at an authorization server to request renewed access	A token to send to an ordinary resource endpoint

Interpret a header under a specific profile

{
  "alg": "RS256",
  "typ": "at+jwt",
  "kid": "example-key-1"
}

This fictional header illustrates a JWT access-token profile, not a complete signed token. RFC 9068 defines a profile that uses an explicit access-token type. Do not assume that every provider follows that profile or that a matching typ value makes a token authentic.

The algorithm and key identifier must be interpreted against trusted configuration. A token cannot grant itself a trusted algorithm by declaring one. The exact issuer, audience and validation rules still come from the protocol and the application's integration with that issuer.

Use access and ID tokens at their intended destinations

In OpenID Connect, an ID token communicates an authentication result to the client. Its audience and validation rules are tied to that use. The OpenID Connect ID Token definition explains that role. Sending an ID token to an unrelated API does not turn it into an access token for that resource.

An API access token can be a JWT or an opaque value, depending on the authorization server. A client should not require every access token to have three readable sections. When the client only needs to attach a credential to a documented request, it often does not need to decode the token at all.

Likewise, a refresh token need not be a JWT. It belongs in the provider's token-renewal flow, not in a resource request's Authorization header simply because the access token has expired. Treat the provider's returned fields as distinct credentials with distinct destinations and lifetimes.

Distinguish readable signing formats from encryption

A compact signed JWT commonly has three sections, while compact JWE encryption uses five. A three-section decoder does not decrypt a five-section encrypted token. The JWT specification describes these protection mechanisms; a signed payload can remain readable even though its integrity is protected.

Do not infer confidentiality from the presence of a signature. If claims contain information that should not be visible to the token holder or intermediaries handling it, review the protocol's data-minimization and protection requirements instead of relying on Base64URL encoding.

Record a token's purpose without exposing the credential

Use the JWT Decoder with a synthetic signed-format fixture to inspect header and payload structure. Label the output as unverified. For a production integration, log a safe correlation reference or token metadata allowed by policy, rather than copying the entire credential into a ticket.

Test the boundary between token uses: an ID token should not be accepted where an API access token is required, and a token for one audience should not silently work for another. A useful test suite proves these rejections, not only the successful login path.