What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
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 JSON Web Token (JWT) is a compact, URL-safe format for carrying claims—statements represented as JSON, such as who issued a token or when it expires. A JWT may be signed or protected with a message authentication code (MAC), encrypted, or constructed to use both. A readable signed JWT is not automatically secret: its contents can usually be decoded, so applications must validate it before relying on its claims.
What does JWT mean?
JWT stands for JSON Web Token. It is a standard format for carrying a set of claims in a compact representation designed for transmission, including in HTTP headers and URI query parameters. The IETF describes JWTs as URL-safe, JSON-based security tokens that contain claims; the definition appears in RFC 8725, the JWT Best Current Practice published in February 2020. The original format is specified in RFC 7519, published in May 2015.
A claim is a name/value statement in a JSON object. For example, a token might state that its subject is a particular account and that it expires at a specified time. A claim is information to be interpreted under the rules of the application or protocol; its presence alone does not prove it is true.
Free tools Windows power users keep installed
One-click scans. No signup required.
What does a JWT look like?
Common signed form: three sections
A JWT in compact JWS form commonly appears as three Base64url-encoded sections separated by periods:
#1 Best Overall
header.payload.signature- Header: Protected metadata, commonly including the signing algorithm and token type.
- Payload: The JSON claims.
- Signature: A cryptographic value used to check integrity and, depending on the signing method and key, the token’s origin.
This is an illustrative shape, not a usable token. The header and payload are encoded so they can be represented compactly; encoding does not encrypt or conceal them. Anyone who obtains a typical signed JWT can decode those sections and read their contents. The signature does not hide the payload.
Encrypted form: five sections
A compact JWE, the encrypted JWT form, has five period-separated sections rather than the three sections shown above. Encryption provides confidentiality for the protected content. A nested construction can combine encryption and signing. Therefore, counting three parts is a useful clue for a common signed form, not a rule that every JWT has exactly three parts.
Does a JWT protect its contents?
It depends on the representation. A JWS signs or MACs content to support integrity checks; it does not by itself make the claims confidential. A JWE encrypts content to provide confidentiality. Some designs nest these mechanisms to provide both protections. Which form is appropriate depends on the protocol and its security requirements.
Because a signed token’s claims may be readable, do not put passwords, private keys, or other secrets in an ordinary signed JWT on the assumption that its signature hides them. A signature or MAC helps detect unauthorized changes when correctly verified; it is not a substitute for encryption.
Rank #3
What do common JWT claims mean?
RFC 7519 defines registered claim names, but does not require every JWT to include every registered claim. The application or protocol determines which claims are required and how they are interpreted.
| Claim | Meaning |
|---|---|
iss |
Issuer: the entity that issued the token. |
sub |
Subject: the principal the token is about. |
aud |
Audience: the intended recipient or recipients. |
exp |
Expiration time, after which the token must not be accepted under the applicable rules. |
nbf |
Not-before time, before which the token must not be accepted under the applicable rules. |
iat |
Issued-at time. |
jti |
JWT ID: an identifier for the token. |
A claim’s name does not establish that a token is valid. For example, an application needs to check that the issuer is the expected one and that the audience matches the intended service, rather than treating any token containing those fields as trustworthy.
How should an application validate a JWT?
Decoding is not validation. A secure implementation follows the rules for the token’s intended use and checks both its cryptography and its claims. RFC 8725 recommends that implementations use an explicitly supported set of algorithms and verify that the algorithm indicated in the token header is consistent with the cryptographic operation being performed.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Repair Windows errors before they cause bigger problems3Fix the driver behind crashes, sound loss and screen glitches- Apply an algorithm policy. Accept only algorithms the application explicitly supports for this token type; do not let an untrusted header choose an operation outside that policy.
- Verify the signature or MAC. Use the correct trusted key and the expected cryptographic method. A decoded payload or a token that merely looks well-formed is not evidence that verification succeeded.
- Check required claims. Validate issuer, audience, expiration, not-before time, and any other claims required by the application or protocol.
- Check the token’s purpose. Ensure the token is being used in the context for which it was issued, with the appropriate application-specific rules.
- Handle key references cautiously. Do not blindly fetch key URLs supplied in a token header; RFC 8725 warns that doing so can create server-side request forgery risk.
These are standard-level safeguards, not a recipe for any particular library or identity provider. The details depend on the protocol and implementation. RFC 8725 also notes that recommendations can change, so implementations should account for applicable updates and errata.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.JWT, JWS, and JWE: how are they related?
JWT describes the claims-based token format, while JWS and JWE describe ways of representing and protecting content. In a common compact JWS, the claims are signed or MACed; in compact JWE, they are encrypted. A JWT may also use a nested construction to combine these mechanisms. Neither the three-part appearance nor confidentiality should be assumed without identifying the actual form and its protections.
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.
