The direct answer
Choose the receiver’s token profile, trusted issuer and key source before accepting any JWT fields. Enforce its allowed algorithms, purpose, claims and time rules, then authorize the exact operation separately. A matching key ID or successful signature alone does not establish that the token belongs in this context.
Choose the receiving protocol before inspecting a token
A reporting tool receives something that looks like a JWT. Decoding its fields does not establish who issued it, which key is trusted, or whether it belongs at this endpoint. Start with the receiver's contract rather than letting the incoming header choose the contract.
The connector delegation guide begins with validated credential metadata. This guide examines that earlier validation boundary. It is not an OAuth client implementation, callback-signature recipe, or claim that every access token uses JWT format.
Define one fictional access-token receiver
Invent resource R-A, a notes-reading API, and trusted issuer I-A. These are labels for configuration, not literal issuer URLs or a serialized token. The deployment agrees to accept signed, unencrypted, compact access tokens using the RFC 9068 profile; encryption is not negotiated. Other token formats and purposes need separate receivers.
Its algorithm allowlist contains only RS256, chosen for this fictional contract, not as a universal recommendation. It accepts the profile's at+jwt and application/at+jwt type values. It requires iss, exp, aud, sub, client_id, iat, and jti, with their specified types and semantics. Missing required fields cannot become defaults.
Require exact configured issuer matching and audience membership for R-A. Check expiration and any optional not-before time using a trusted clock. RFC 7519 defines those time claims; this proposed deployment permits thirty seconds of skew. That number is a local choice, not an RFC requirement. Issued-at is not automatically a not-before claim.
Select within established trust, never create trust from a header
Configuration binds I-A to approved key-set location SET-A and an operational owner. A received issuer value may be compared with that configuration; it must not enroll a new issuer. The application never derives a key-fetch destination from model output or the token's jku or x5u fields. This narrow profile rejects those header fields.
RFC 8725 requires algorithm restrictions and issuer-to-key binding, and warns about unsafe key lookups and token-controlled URLs. A successful cryptographic operation using an unrelated key is insufficient. Choose a maintained verifier, pin its release, and review its supported key types and cryptographic checks; this article implements none.
Our profile additionally requires a kid label of one to sixty-four ASCII letters, digits, hyphens or underscores and exactly one eligible match within I-A's trusted set. These are application restrictions. RFC 7517 describes key IDs as case-sensitive selectors, not globally authenticated identities. Evaluate key type and permitted operation, including consistent algorithm and usage metadata when supplied. Do not turn an arbitrary key ID into a filename, database expression, or network address.
RFC 9068 does not define a marker identifying an advertised key as exclusively an access-token key. Keep token-purpose validation independent of key selection; a familiar key label cannot replace the receiver's type, issuer, audience and claim rules.
Review inert acceptance cards
Every row below is an independent proposed case. “Signature valid” is an assumed worksheet input, never an observed cryptographic result. K-1 and K-2 are invented labels without key material.
| Metadata card | Expected disposition | Boundary exercised |
|---|---|---|
| Approved I-A/K-1, RS256, access-token type, required claims and permitted note | Eligible only after all actual validation and authorization | Useful positive path |
| Same trusted key, but ID-token purpose or wrong type | Reject | Shared issuer/key does not merge purposes |
| Issuer label I-B with K-1 | Reject; do not enroll I-B | Key label cannot select trust domain |
| Header offers its own key-set destination | Reject under this profile | No token-directed key retrieval |
| Known label, wrong algorithm or incompatible key use | Reject | Selection is constrained beyond kid |
| K-2 absent; refresh prohibited by current cooldown or unavailable | No admission; retain operational reason | Unknown key is not permission to bypass validation |
| Authorized refresh admits K-2 into I-A's set | Restart full validation; do not automatically allow | Rotation preserves every other gate |
| Multiple eligible keys match | Reject ambiguous selection under this profile | No arbitrary first-key choice |
| Signature assumed valid; audience wrong, claim missing, or time unacceptable | Reject | Cryptography is not complete validation |
| All token checks pass, but requested note is unauthorized | Deny object access | Token validity is not object authority |
Write rotation policy separately from library behavior
The official jose main documentation for createRemoteJWKSet describes fetching when its cache is missing or stale, and an unmatched-key refetch subject to a cooldown since the last successful fetch. It selects using algorithm, key ID and applicable usage metadata. This is observed documentation, not a statement about an installed package.
For R-A, propose one bounded, rate-limited refresh path to SET-A, with a request timeout, coordinated concurrent refreshes and explicit cache-age policy. During an unresolved selection, deny admission rather than trying unrelated issuers or broadening algorithms. These are deployment requirements, not claimed library defaults. Pin and verify the actual implementation before relying on them.
Plan routine overlap for issuer rotation separately from emergency key removal. Define when cached keys cease to be accepted and how operators update that policy. A matching cached key does not establish current remote validity or immediate revocation awareness. Cache expiry, token expiry and local authorization have different meanings.
Keep application identity and evidence separate
After validation, resolve the issuer-subject pair and client context through trusted application mappings, then authorize the operation and exact object under current rules. A jti field alone neither makes the token single-use nor coordinates a business effect. Use separate action or callback state where that workflow requires it.
Record profile revision, verifier version, trusted-set revision, decision category and synthetic case ID without logging reusable tokens. All cards remain PROPOSED_UNRUN: no token generation, signing, verification, keys, JWKS retrieval, account operation or authentication experiment occurred. Boundary is a prelaunch commercial model router; planned request-path checks do not provide this JWT receiver. Its eight mock evaluator checks are different evidence.
Primary sources
Official references supporting the guidance. Examples in this guide are synthetic and are not reports of a production incident.