JSON Web Token (JWT, suggested pronunciation/dʒɒt/, same as the word "jot"^[1]) is aproposed Internet standard for creating data with optionalsignature and/or optionalencryption whosepayload holdsJSON that asserts some number ofclaims. The tokens are signed either using aprivate secret or apublic/private key.

For example, a server could generate a token that has the claim "logged in as administrator" and provide that to a client. The client could then use that token to prove that it is logged in as admin. The tokens can be signed by one party's private key (usually the server's) so that any party can subsequently verify whether the token is legitimate. If the other party, by some suitable and trustworthy means, is in possession of the corresponding public key, they too are able to verify the token's legitimacy. Thetokens are designed to be compact,^[2]URL-safe,^[3] and usable, especially in aweb-browsersingle-sign-on (SSO) context. JWT claims can typically be used to pass identity of authenticated users between anidentity provider and aservice provider, or any other type of claims as required by business processes.^[4][5]

JWT relies on other JSON-based standards:JSON Web Signature andJSON Web Encryption.^[1][6][7]

Header

Identifies which algorithm is used to generate the signature. In the below example,HS256 indicates that this token is signed using HMAC-SHA256.

Typical cryptographic algorithms used areHMAC withSHA-256 (HS256) andRSA signature with SHA-256 (RS256). JWA (JSON Web Algorithms) RFC 7518 introduces many more for both authentication and encryption.^[8]

{"alg":"HS256","typ":"JWT"}

Payload

Contains a set of claims. The JWT specification defines seven Registered Claim Names, which are thestandard fields commonly included in tokens.^[1] Custom claims are usually also included, depending on the purpose of the token.

This example has the standard Issued At Time claim (iat) and a custom claim (loggedInAs).

{"loggedInAs":"admin","iat":1422779638}

Signature

Securely validates the token. The signature is calculated by encoding the header and payload usingBase64url EncodingRFC 4648 and concatenating the two together with a period separator. That string is then run through the cryptographic algorithm specified in the header. This example uses HMAC-SHA256 with a shared secret (public key algorithms are also defined). TheBase64url Encoding is similar tobase64, but uses different non-alphanumeric characters and omits padding.

HMAC_SHA256(secret,base64urlEncoding(header)+'.'+base64urlEncoding(payload))

The three are encoded separately usingBase64url EncodingRFC 4648, and concatenated using periods to produce the JWT:

consttoken=base64urlEncoding(header)+'.'+base64urlEncoding(payload)+'.'+base64urlEncoding(signature)

The above data and the secret of "secretkey" creates the token:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJsb2dnZWRJbkFzIjoiYWRtaW4iLCJpYXQiOjE0MjI3Nzk2Mzh9.gzSraSYS8EXBxLN_oWnFSRgCzcmJmMjLiuyu5CSpyHI

(The above json strings are formatted without newlines or spaces, into utf-8 byte arrays. This is important as even slight changes in the data will affect the resulting token)

This resulting token can be easily passed intoHTML andHTTP.^[3]

In authentication, when a user successfully logs in, a JSON Web Token (JWT) is often returned. This token should be sent to the client using a secure mechanism like anHTTP-only cookie. Storing the JWT locally in browser storage mechanisms likelocal or session storage is discouraged. This is because JavaScript running on the client-side (including browser extensions) can access these storage mechanisms, exposing the JWT and compromising security. To make use of the HTTP-only cookie, as you might need it to authenticate with cross-origin APIs, the best approach is to use the credentials property to tell the browser to automatically send the cookies to the external APIs via a Fetch call like so:

fetch('https://api.example.com/data',{method:'GET',credentials:'include'// This tells the browser to include cookies, etc.}).then(response=>response.json()).then(data=>console.log(data)).catch(error=>console.error('Error:',error));

By using this method, the JWT is never exposed to client-side JavaScript, this is the best approach to make use of your JWT while maintaining security best practices. For unattended processes, the client may also authenticate directly by generating and signing its own JWT with a pre-shared secret and pass it to aOAuth compliant service like so:

POST /oauth2/tokenContent-type:application/x-www-form-urlencodedgrant_type=urn:ietf:params:oauth:grant-type:jwt-bearer&assertion=eyJhb...

If the client passes a valid JWT assertion the server will generate an access_token valid for making calls to the application and pass it back to the client:

{"access_token":"eyJhb...","token_type":"Bearer","expires_in":3600}

When the client wants to access a protected route or resource, the user agent should send the JWT, typically in theAuthorizationHTTP header using theBearer schema. The content of the header might look like the following:

Authorization: Bearer eyJhbGci...<snip>...yu5CSpyHI

This is a stateless authentication mechanism as the user state is never saved in server memory. The server's protected routes will check for a valid JWT in the Authorization header, and if it is present, the user will be allowed to access protected resources. As JWTs are self-contained, all the necessary information is there, reducing the need to query the database multiple times.

List of currently registered claim names can be obtained fromIANA JSON Web Token Claims Registry.^[11]

JWT implementations exist for many languages and frameworks, including but not limited to:

JSON web tokens may contain session state. But if project requirements allow session invalidation before JWT expiration, services can no longer trust token assertions by the token alone. To validate that the session stored in the token is not revoked, token assertions must be checked against adata store. This renders the tokens no longer stateless, undermining the primary advantage of JWTs.^[38]

Security consultant Tim McLean reported vulnerabilities in some JWT libraries that used thealg field to incorrectly validate tokens, most commonly by accepting aalg=none token. While these vulnerabilities were patched, McLean suggested deprecating thealg field altogether to prevent similar implementation confusion.^[10] Still, newalg=none vulnerabilities are still being found in the wild, with fourCVEs filed in the 2018-2021 period having this cause.^{[39][better source needed]}

With proper design, developers can address algorithm vulnerabilities by taking precautions:^[40][41]

1. Never let the JWT header alone drive verification
2. Know the algorithms (avoid depending on thealg field alone)
3. Use an appropriate key size

Several JWT libraries were found to be vulnerable to aninvalid Elliptic-curve attack in 2017.^[42]

Some have argued that JSON web tokens are difficult to use securely due to the many different encryption algorithms and options available in the standard, and that alternate standards should be used instead for both web frontends^[43] and backends.^[44]

• API key
• Access token
• Basic access authentication
• Digest access authentication
• Claims-based identity
• HTTP header
• Concise Binary Object Representation (CBOR)

• RFC 7519
• jwt.io – specialized website about JWT with tools and documentation, maintained by Auth0

• Computer access control
• Identity management
• Federated identity
• Identity management systems
• Metadata standards
• JSON

• Articles with short description
• Short description is different from Wikidata
• Use American English from July 2019
• All Wikipedia articles written in American English
• Use mdy dates from July 2019
• All articles lacking reliable references
• Articles lacking reliable references from January 2024