JWT profile

JWT, short for JSON Web Token, is used as a Token in a Web application in the form of JSON to securely transfer information between parties as JSON objects. Data encryption and signature can also be completed during data transmission.

JWT function

  • Licensing: This is the most common way to use JWT. Once the user is logged in, each subsequent request will include JWT to allow the user to access the routes, services, and resources allowed by the token. Single sign-on is a feature that is widely used in JWT today because it has little overhead and can be easily used in different domains.

  • Information Exchange: JSON Web tokens are a good way to securely transfer information between parties. Because JWT can be signed (for example, using public/private key pairs), you can ensure that the sender is who they say they are. In addition, because the signature is calculated using headers and payloads, you can also verify that the content has been tampered with.

Session-based authentication

As we know, HTTP itself is a stateless protocol, which means that if a user provides a user name and password to our application, the user is authenticated. On the next request, the user will have to authenticate the user again. Because the HTTP protocol does not allow us to know which user made the request, we can only store a copy of the user login information on the server in order for our application to identify which user made the request. This login information is passed to the browser in response, telling it to save it as a cookie and send it to our app on the next request, so our app can identify which user the request is from. This is traditional session-based authentication.

Exposed problems:

  1. After each user is authenticated by our application, our application should make a record on the server side to facilitate the authentication of the user’s next request. Generally speaking, session is stored in memory, but with the increase of authenticated users, the overhead on the server side will increase significantly.

  2. After the user is authenticated, the server makes the authentication record. If the authentication record is stored in memory, this means that the user must request the server again in order to obtain the authorized resources, which limits the load balancer’s ability in distributed applications. This also means that the application’s ability to scale is limited.

  3. Because users are identified based on cookies, if cookies are intercepted, users will be vulnerable to cross-site request forgery attacks.

  4. This is even more painful in a front and rear separation system, as shown below:

This means that the front-end separation increases the complexity of the deployment after the application is decoupled. Often a user will forward a request multiple times. If you use session to carry the session ID to the server each time, the server will also query the user information. And if you have a lot of users. This information is stored in the server memory, adding to the burden on the server. There is also CSRF(Cross-site forgery Request Attack) attack, session is based on cookie to identify users, if the cookie is intercepted, users will be vulnerable to cross-site request forgery attack. In addition, the sessionID is an eigenvalue, which is not rich enough to be extended. And if your backend application is multi-node deployment, then you need to implement session sharing mechanism, which is not easy to cluster applications.

Based on JWT certification

Certification process:

  1. First, the front end sends its user name and password to the back-end interface via a Web form. This process is usually aHTTP POSTThe request. The recommended method is SSL encrypted transmission (HTTPS protocol) to prevent sensitive information from being sniffed.
  2. After verifying the user name and password, the backend uses other information, such as the user ID, asJWT Payload(payload), which is Base64 encoded and signed with the header to form a JWT(Token). The resulting JWT is a string like XXX.yyy.zzz.
  3. The back end returns the JWT string to the front end as the result of a successful login. The front end can save the returned results inlocalStorageorsessionStorageOn, delete the saved JWT when you log out.
  4. The front end puts JWT in the HTTP Header on each requestAuthorizationposition (Solve XSS and XSRF issues)
  5. The backend checks if there is, if there is, to verify the validity of JWT. For example, check whether the signature is correct. Check whether the Token has expired. Check whether the receiver of the Token is itself (optional).
  6. After verification, the back-end uses the user information contained in JWT to perform other logical operations and return corresponding results.

Advantages of JWT:

  1. Compact: Can be sent through the URL, the POST parameter, or in the HTTP header, because the amount of data is small and the transmission speed is fast.
  2. Self-contained: The load contains all the information required by the user, avoiding multiple queries to the database.
  3. Because the Token is stored on the client in the form of JSON encryption, JWT is cross-language and in principle any Web form is supported.
  4. There is no need to store session information on the server, especially for distributed microservices.