A Validly Signed Access Token Still Needs the Right Recipient and Permission

Name the token and its protocol profile

Here, token means a credential used in API access, not a unit of model input or output. OAuth distinguishes the authorization server that issues access tokens from the resource server hosting protected resources. RFC 6749, published in October 2012, describes access tokens as representing defined scopes and durations of access, with different token formats possible.

This article uses RFC 9068, the October 2021 JWT profile for OAuth 2.0 access tokens. It specifies required claims and validation behavior for that profile. Those requirements do not apply to every possible use of JWT.

An OpenID Connect ID token communicates claims about a user's authentication to a client. Its audience includes that client's identifier. It serves a different purpose from the access token presented to an API. A shared JWT format does not make the two interchangeable.

References: [O1][A1][I1]

Reading a claim and validating a signature establish different things

A displayed claim is content awaiting validation in the appropriate context. Being able to read it does not establish that an API trusts its issuer, that its integrity has been established or that its meaning fits the intended use.

RFC 7515 describes JWS cryptographic protection as protecting content integrity. A useful signature result depends on the correct trusted issuer and key context. Even when that context and the signature are correct, the result does not decide which recipient may accept the token or what request it may authorize.

RFC 9068 requires an access-token type identified by the typ values at+jwt or application/at+jwt. It also addresses encrypted access tokens. Signing does not itself encrypt claims; the profile cannot be reduced to a description of three readable segments.

References: [J1][A1]

Check the intended recipient and the applicable time separately

The aud claim identifies intended recipients. RFC 8725, published in February 2020, explains the audience-binding rationale in section 3.9: when an issuer supplies JWTs for multiple applications, the recipient must establish that it is an intended audience. Trusting the issuer does not make every token from that issuer applicable to every API.

Expiration answers another question. RFC 7519 defines exp as the time on or after which a token must not be accepted, with limited clock-skew leeway permitted. Its iat claim records issuance time; that is a different fact from the expiry boundary.

An expired token can retain the same signed content and a valid cryptographic signature. A token presented to the wrong recipient can do so too. In either case, signature validity leaves an independent reason for the receiving API to reject it.

References: [B1][J2]

Connect permission claims to the actual object and action

Under RFC 9068, scope strings must have meaning for the audience resources. The profile says the resource server should consider authorization claims with other context when deciding whether to authorize the call. The profile leaves the details of that application decision outside its scope.

A reports:read claim can be relevant to reading reports without answering which particular report the requester may read. The application's policy must connect the validated authorization information to the requested object and action. Matching the API's audience does not grant every operation it exposes.

References: [A1][O1]

AT-252: one signature, four different request conclusions

Fictional example AT-252 assumes a symbolic access token whose signature and issuer have already been correctly validated. Its token type and other unmentioned token-validation conditions are stipulated to be satisfied. This isolates recipient, time and permission without constructing a complete token.

Its audience is resourceR. Its expiry corresponds to 10:00, and its only scope is the fictional reports:read. All times refer to the same fictional day and clock; they are human-readable shorthand rather than encoded claim values. The stipulated application policy requires a separate write permission for writing and grants none to this token. The exercise stipulates no clock leeway solely to make the comparison definite; that is not a recommended production clock setting.

At 09:30, resourceR/read matches the audience and is before expiry. The reports:read scope is potentially relevant. The actual application authorization decision for the requested report is still required; these matches alone do not establish that the request should succeed.

At 09:30, resourceR/write meets those audience and time conditions but lacks write permission under the stipulated policy.

At 09:30, resourceS/read fails the audience condition. A relevant-looking read scope cannot make resourceS an intended recipient.

At 10:05, resourceR/read fails the stipulated expiry condition even though the recipient matches.

The same signature remains valid in all four comparisons while the request conclusions differ. These are deductions from invented assumptions, with no real token, endpoint or performed access test.

Ask the provider to substantiate access behavior

An offer saying JWT supported makes a format claim. Ask the API provider to explain the behavior for the resource you intend to use: the accepted issuer and token profile, the intended audience, the applicable time limits and how authorization information maps to the requested object and action. A signature demonstration answers only part of that inquiry.

Ask separately how permission withdrawal reaches the API and what limits token reuse. RFC 6750 defines bearer tokens so that possession can suffice for use; a valid signature alone does not establish replay protection. Instant revocation and a live check of current employment also cannot be inferred from a signed claim. Those behaviors need their own explanation and evidence.

For AT-252, a useful provider explanation would distinguish the potentially authorized read from the disallowed write, wrong recipient and expired presentation. It would also explain what additional application policy decides access to the particular report. A collection of readable claims leaves that decision unanswered.

References: [O1][B2]

Keep API authorization and physical deployment responsibilities distinct

The related confidential-computing article concerns evidence about an execution environment. The software-provenance article concerns an artifact's origin and production. Neither supplies the API's authorization decision about a request.

Where the project also involves equipment installation, Leviathan's Complete Physical Infrastructure Deployment service can scope receiving, rack integration, onsite installation, cabling and physical handoff. IAM configuration, cryptographic implementation, application security assessment and operating API access are outside this educational article and the physical service described here.

Use the related physical-deployment service and project inquiry to discuss a nonconfidential equipment outline, site, required physical stages and receiving team. Keep access tokens out of that inquiry; the requested outcome is a defined equipment work package and handoff.

References: [L1]