Learn about JSON web token (JWT)


JSON Web Token (JWT)

Reference: introduction to JSON web tokens

brief introduction

JSON web token (JWT) is an open standard (RFC 7519), which defines a compact and independent method for securely transferring information as JSON objects between parties. Because this information is digitally signed, it can be verified and trusted.


The JSON web token consists of three parts, which are separated by (.).

  • Header
  • Payload
  • Signature

Therefore, the format of JWT is as follows:xxxx.yyyy.zzzz

Part I header

It usually consists of two parts: the type of token (JWT), and the hash algorithm used (such as HMAC sha256 or RSA).

  "alg": "HS256",
  "typ": "JWT"

This JSON is then the first part of the base64 URL encoding that forms the JWT.

The second part is payloads

Usually includes claims, which are declarations about entities (usually users) and additional metadata.

Here are three types of declarations:

  • reserved
  • public
  • private

Reserved claims

These are a set of predefined declarations, not mandatory, but recommended to provide a useful, interoperable set of declarations. Some of them are:

  • iss (issuer)
  • exp (expiration time)
  • sub (subject)
  • aud (audience)
  • other

PSNote that the declaration name is only three characters long, because JWT means compact.

Public claims

These can be defined at will by those who use JWT. However, in order to avoid conflicts, the
IANA JSON web token registry
They are defined in, or defined as URIs that contain an anti-collision namespace.

Private claims

These are custom declarations created to share information between parties that use them.

for example

    "sub": "1234567890", 
    "name": "John Doe", 
    "admin": true 

The payload is encoded by base64url to form the second part of the JSON web token.

Part 3 signature

To create the signature part, the following three data must be used. According to the algorithm specified in the header, the signature is used for signature verification.

  • Base64 encoded header
  • Coded payload
  • A secret

For example, if you want to use the HMAC sha256 algorithm, the signature is created in the following way:

HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)

And then we put them together

The output is three Base64 URL strings separated by dots (.), which can be easily passed in HTML and HTTP environments, and is more compact than XML based standards such as SAML.

The following is the JWT result string after encoding and signing:

You can use the JWT debug tool to test and verify signatures.

How to use JWT

Get JWT and use it to access APIs or resources:

  • The client logs in from the authorization server
  • After successful login, the authorization server issues a JWT token and returns it to the client
  • The client uses JWT token to access the protected API resource server

Please note that with a signed token, all the information contained in the token will be exposed to users or other parties (because Base64 can be decompiled to get the original text), even if they can’t change the data, they should not put the confidential information into the token. Due to the lack of security, sensitive session data should not be stored in the browser.

In authentication, the JSON web token is returned when the user successfully logs in using his credentials. Since tokens are credentials, extra care must be taken to prevent security issues. In general, the token should not be retained longer than required.

Whenever a user wants to access a protected route or resource, the user agent should send a JWT, usually in an authorization header using bearer mode.
The content of the header should be as follows:Authorization: Bearer <token>

In some cases, this can be a stateless authorization mechanism. The server‘s protected route checks for a valid JWT in the header and, if it exists, allows the user to access the protected resource. If JWT contains the necessary data, it can reduce the need to query some operations in the database, though not always.

If the token is sent in the header, cross domain resource sharing (CORS) does not become a problem because it does not use cookies.


The JSON web token (JWT) uses dots (.) to separate the strings concatenated by three Base64 encrypted parts.


  1. Lightweight cross language, using string transmission, different development language systems can use
  2. No state, no need to consume cache or other data storage to save state
  3. Cross domain
  4. It can transmit data to different systems and reduce database access
  5. The effective time can be set to process and judge in gateway layer / entrance interceptor
  6. Signature and hosting data cannot be changed


  1. Bearing data fully exposed
  2. Stateless, unable to manage token effectively, need to wait for valid time to be invalid
  3. Validity renewal


Now the developed system is to generate a token (such as UUID string), which is stored in the cache and managed by the server. The verification and storage requires some resources. When there are a large number of requests, there will be some pressure on the back-end.

Therefore, referring to the characteristics of JWT, the token string is changed to the form of JWT. The token is put in the cache, and the token state needs to be retained due to business problems. The advantage of this method is to keep the business unchanged. By using JWT’s bearing data to verify the effective time and identity, the interaction pressure with cache can be reduced, and useless token requests can be effectively filtered out to a large extent (although the stateless characteristics of JWT are not available).

Recommended Today

On the theoretical basis of SRE

What is SRE? When I first got into contact with SRE, many people thought that it was a post with full stack capability in Google and could solve many problems independently. After in-depth exploration, it is found that SRE can solve many problems, but there are too many problems. It is difficult for a post […]