iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
A successfully verified JWT can show that its protected claims have not changed and that the relevant key signed or authenticated them. It does not, by itself, prove those claims are true, that the key belongs to an issuer your API trusts, or that the subject is currently allowed to perform an action. Treat JWT verification as one step in a context-specific trust decision, not as a blanket authorization check.
What does a JWT actually prove?
A JSON Web Token (JWT) is a compact way to represent claims as a JSON object. It can be encoded in a JSON Web Signature (JWS) or JSON Web Encryption (JWE), allowing claims to be signed or protected with a message authentication code, encrypted, or both. The format alone does not establish trust.
When a JWS signature or MAC verifies correctly, the protected data has not been altered since it was created using the relevant key, and the cryptographic operation authenticates that key’s involvement. That conclusion is narrower than “the claims are true.” A signed statement can be false, outdated, or irrelevant to the API receiving it.
RFC 7519 warns that JWT contents cannot support a trust decision unless they are cryptographically secured and bound to the context needed for that decision. A valid cryptographic check is necessary in many deployments, but it is not the whole trust decision.
#1 Best Overall
What does verifying a JWT signature tell you?
Signature verification answers a cryptographic question: does the token’s protected content match a signature that verifies under the supplied key and algorithm? It does not independently answer whether the key is trusted, whether the claims are acceptable, or whether the API should honor the requested operation.
- Integrity: the protected content has not been changed without invalidating the signature or MAC.
- Key authentication: the token was produced by someone with access to the key that validates it. With a shared MAC secret, any party holding that secret may be able to create valid tokens.
- Not truth: a verified claim such as a subject identifier remains an assertion; the API must determine what it means and whether to accept it.
- Not confidentiality: signing does not hide the payload. Encryption can provide confidentiality, but encrypted content still needs appropriate validation and trust checks.
Is a valid JWT proof that a user is authorized?
No. A token may identify a subject or carry permissions, but authorization is a decision made by the application for a specific request. The API must evaluate the token’s claims against its own policy and, where required, current application state.
The general JWT format does not require every registered claim. Claims such as iss (issuer), sub (subject), aud (audience), exp (expiration time), and nbf (not-before time) are optional unless the applicable application profile requires them. “Valid JWT” therefore has no useful context-free meaning: validity depends on the token type and the endpoint’s defined validation rules.
The JWT standard cannot determine how a particular service handles revoked tokens, disabled accounts, changed permissions, or other state changes. Those checks depend on the service’s design. A token that passed cryptographic and claim validation may still fail the API’s current authorization policy.
Rank #3
What should an API check before trusting a JWT?
Validate the token for the endpoint’s specific purpose rather than decoding it and accepting its contents. A practical sequence is:
- Confirm the expected token form. Ensure the endpoint accepts this kind of JWT and applies the right parsing and validation rules for it.
- Verify the cryptographic operation. Use a locally configured allow-list of algorithms and the correct key. Reject unapproved algorithms, and ensure keys are used only with their intended algorithms.
- Bind the key to a trusted issuer. A valid signature only identifies the verifying key’s role; the API must establish that the key belongs to the issuer it intends to trust.
- Validate issuer and subject. Check that
issandsub, when present or required, have acceptable values for this application. - Check the audience. If an
audclaim is present, RFC 7519 requires a recipient that is not identified in it to reject the token. The claim is optional in the general format, but an API can require it. RFC 8725 recommends audience validation when one issuer serves multiple relying parties. - Apply temporal rules. Enforce required time claims such as
expandnbfaccording to endpoint policy. Do not infer that expiration is mandatory merely because it is commonly used. - Enforce token-purpose separation. Check the expected type and required claims, and use mutually exclusive validation rules for tokens meant for different contexts. This helps prevent a token issued for one purpose from being accepted in another.
- Make the authorization decision. Evaluate the requested action against applicable permissions and current application state, including any revocation or account checks the service requires.
Why algorithm and token-purpose checks matter
JWT best-current-practice guidance documents several validation hazards: accepting an unsecured alg: none token, confusing RSA and HMAC algorithm use, relying on weak symmetric secrets, skipping validation of nested JWTs, or accepting a token intended for another context.
RFC 8725 says libraries should let callers specify permitted algorithms, reject other algorithms, and check that keys are used only with the intended algorithm. It also recommends mutually exclusive validation rules for different JWT kinds. A token should not become acceptable just because it is well-formed and some cryptographic check succeeded; it must satisfy the profile for the endpoint receiving it.
What expiration does—and does not—establish
The exp claim identifies the time on or after which a JWT must not be accepted. RFC 7519 allows a small clock-skew leeway, usually no more than a few minutes. The claim is optional in the general JWT format, so an application profile must determine whether it is required and how to handle clock differences.
An unexpired token is not proof of current authorization. Expiration limits a token’s acceptable lifetime; it does not establish that the account remains active, that permissions have not changed, or that the action requested is permitted.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
