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 JWT is a compact format for carrying claims—statements about a subject—not a permission decision by itself. Its meaning depends on who issued it, who it is for, what kind of token it is, and the rules the receiving application applies. A signed JWT can be checked for integrity and authenticity, but its claims are not confidential unless the token is encrypted.
What is a JWT?
JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties, as defined by the Internet Engineering Task Force (IETF) in RFC 7519. A claim is a name/value assertion about a subject. JWT is a representation format; it does not prescribe every application’s required claims or how an application must interpret them.
JWTs commonly use either JSON Web Signature (JWS) or JSON Web Encryption (JWE). A JWS can be digitally signed or protected with a message authentication code (MAC), helping a receiver detect changes and verify the token’s source under an established key arrangement. Signing does not hide the payload: its encoded contents can generally be read by anyone who obtains the token. JWE encrypts the contents for confidentiality. A JWT can also be nested, for example by signing an encrypted JWT or encrypting a signed JWT.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →What does a JWT token contain?
A JWT carries a claims set, commonly represented as JSON. Registered claim names have standardized meanings, but RFC 7519 does not require every JWT to contain every registered claim. The application or token profile determines which claims must be present and how they are processed.
#1 Best Overall
- Made in USA - Proudly produced in Ohio by a Veteran-owned business
- Comprehensive Coverage: This BookFactory log book includes essential fields such as post/shift, time of change, date, weather conditions, and a designated space for detailed notes. This ensures that all relevant information is captured and easily accessible.
- Sturdy Cover: The trans-lux cover protects the log book from wear and tear, ensuring its longevity and maintaining the integrity of your recorded data.
- Essential Security Tool: This log book is an indispensable tool for any organization that values security and accountability. It helps to prevent misunderstandings, improve communication, and ensure a smooth transition between shifts.
- Wire-O with Trans-lux cover, 100 Pages, Dimensions 8.5" x 11" - (Security-Pass-Down) Reorder SKU: LOG-100-7CW-PP(Security-Pass-Down)
| Claim | Meaning | Question for the receiver |
|---|---|---|
iss |
Issuer: the principal that issued the token. | Is this an issuer I trust, and does the verification key belong to it? |
sub |
Subject: the principal the token is about. | Does this subject have the expected meaning in this application? |
aud |
Audience: the intended recipient or recipients. | Is this service an intended audience for the token? |
exp |
Expiration time. | Has the token expired? |
nbf |
Not-before time. | Is the token valid yet? |
iat |
Issued-at time. | When was the token issued, and does that fit the application’s rules? |
jti |
JWT ID: an identifier for the token. | Does the application use the identifier for tracking or replay-related controls? |
These meanings follow RFC 7519; whether a claim is required is a separate question answered by the applicable profile. A claim’s presence also does not prove that its value is trustworthy or appropriate: the receiver must validate the token and interpret each value in context.
How do JWT tokens work?
The issuer creates a claims set and packages it according to a JWT structure. If it signs or MAC-protects the token, the receiver can verify the protection using an appropriate key. If it encrypts the token, a holder of the relevant decryption key can recover its contents. The receiver then checks the token against its own trust and application rules. Encoding is not encryption, and a valid signature alone does not tell the receiver whether the token is meant for it or whether its subject may perform a particular action.
Rank #2
- Made in USA - Proudly produced in Ohio by a Veteran-owned business
- This BookFactory log book is for security guards in any sector or business. You can report location, circumstances and report number.
- There are spaces to log the individual's names address, description and other identifying information. There are also spaces to note others involved, notes, and vehicle information if one was involved
- Wire-O, 100 Pages, Dimensions 3.5" x 5.25"
- Reorder SKU: LOG-100-M3CW-PP(Security-Report)
Keep three questions separate:
- Identity: Who issued the token (
iss), and who or what is its subject (sub)? - Context: Which recipient should accept it (
aud), when may it be used (nbfandexp), and what token kind or profile governs it? - Permissions: What authorization information does it carry, and does that information permit this particular operation on this resource under current conditions?
The subject need not always be a person. Under the OAuth JWT access-token profile in RFC 9068, for example, a client application can be the subject in a client-credentials grant; in a user-involved grant, the subject can represent the user. The application must know which semantics apply.
How are permissions represented in a JWT?
OAuth access tokens may carry a scope claim to express authorization information. Other claims, such as groups, roles, or entitlements, may convey broader attributes. Their names and meanings depend on the issuer and application profile; the JWT format does not make them universal permission rules.
Rank #3
A resource server should evaluate such claims together with the target resource, requested action, subject, client, and relevant runtime context. A scope associated with one resource does not automatically authorize access to another. Treat the token as authenticated input to an authorization decision, not as the decision itself. RFC 9068 discusses using authorization claims alongside other context, and RFC 8725 advises validating token semantics for the application that receives them.
How do I validate a JWT access token?
Validation depends on the token’s profile. For an OAuth JWT access token that follows RFC 9068, the resource server should apply the profile’s checks rather than accept any well-formed JWT. RFC 9068 requires the claims iss, exp, aud, sub, client_id, iat, and jti; it also requires signed tokens and prohibits the none algorithm.
- Identify the expected profile and token kind. RFC 9068 access tokens use the explicit type
at+jwt. Check the token type as specified by the profile, and do not treat an OpenID Connect ID token as an OAuth access token. Mutually exclusive validation rules for different token kinds help prevent substitution between contexts. - Check the issuer. Require the exact issuer expected by the resource server. Bind the verification keys to that issuer; do not assume a key is trustworthy merely because the token names or links to it.
- Check the audience. Confirm that the audience identifies this resource server. A token intended for another service should not be accepted simply because its signature is valid.
- Verify the signature and algorithm. Use keys obtained through the trusted issuer configuration, apply the profile’s algorithm rules, and reject
alg: nonefor RFC 9068 tokens. RFC 9068 recommends asymmetric signing to simplify distribution of validation keys. - Validate time and required claims. Check that the required claims are present and that the token is within its validity period, including applicable
nbfandexpchecks. Apply the expected subject and client semantics. - Make the authorization decision separately. After authentication and profile validation, evaluate scope or other authorization attributes against the requested operation, resource, and application policy.
RFC 8725, the IETF’s JWT Best Current Practices, says applications must ensure that keys used with an issuer claim belong to that issuer and validate the semantics of a present subject claim. If an issuer creates tokens for multiple relying parties or applications, the intended audience must be identified and checked. The same guidance warns against blindly following untrusted jku or x5u header URLs: fetching arbitrary URLs can expose a server to server-side request forgery. Use trusted issuer metadata and key-distribution arrangements rather than treating a token-supplied URL as authority.
JWT access tokens versus opaque access tokens
OAuth 2.0 does not require access tokens to use a particular format. RFC 9068 defines one JWT profile for OAuth access tokens, but it does not establish that JWT or opaque tokens are universally faster or more secure.
Best Value
| Choice | What it establishes | What the receiver must still do |
|---|---|---|
| JWT access token | Claims are carried in a standardized, signed token under a chosen profile such as RFC 9068. | Validate the profile, issuer, audience, signature, time constraints, and application-specific authorization rules. |
| Opaque access token | The token’s internal representation is not defined by the JWT format. | Use the applicable authorization-server or application mechanism to determine its validity and authorization meaning. |
Choose and validate tokens according to the system’s trust model, deployment, and authorization requirements. Neither format removes the need for the resource server to decide whether a particular request is allowed.
Quick Recap
Common JWT mistakes to avoid
- Assuming all JWTs have the same required fields. RFC 7519 defines registered claims but leaves applications to specify their requirements; a profile such as RFC 9068 adds its own requirements.
- Confusing a signature with secrecy. A signed JWS can be readable. Use encryption when token contents must be confidential.
- Accepting a token because its signature verifies. Also check issuer, audience, token profile and type where applicable, subject meaning, time limits, and application rules.
- Using an ID token as an access token. They serve different purposes; explicit access-token typing and distinct validation rules help keep them separate.
- Turning claims directly into an allow decision. Claims supply authorization information, but policy must relate them to the resource, action, and current context.
- Trusting token-provided key URLs. Resolve verification keys through trusted issuer arrangements, not arbitrary URLs from an untrusted header.
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.
