Currently, **JWT (JSON Web Token) ** Token authentication is becoming more and more popular. This article mainly introduces the differences between JWT token authentication and traditional Session authentication.

Why certification?

HTTP is a stateless protocol, which means that the current client request is independent of any previous request, and the server does not record any request information. For example, if you simply access a static page (such as www.yiidian.com), the server doesn’t really need to know who the client is, and will simply return the pure page content to the client. On the other hand, if you want to make changes to your Facebook profile, you have to prove to a tutorial server that you are the account owner. In short, you need to verify your identity before the server can give you access to sensitive information. Before we look at JWT authentication, let’s take a look at traditional Session authentication.

Session Session authentication

Session In the Session authentication model, after the user logs in and authorizes, the server creates a unique Session for the client. The server returns the Session ID to the client, which stores it in a browser cookie. In subsequent HTTP calls, the cookie is automatically included in the HTTP request header, and the server learns the identity of the client from the Session ID recorded in the cookie. Although cookies are stored on the client side, the authentication model is a server-side session because validation is done on the server.

Server-side sessions: Not actually stateless

Technically, the HTTP stateless protocol does not prohibit the server from storing information. Most Web applications need to store some form of state to know if the client’s Session ID is valid. For example, a server might store the Session ID in server memory so that whenever a previously authenticated client makes a request again, the server can simply look up the Session ID in memory and verify that the client has been authenticated.

Advantages of Session authentication

  • The Session ID has an expiration time
  • The Session ID can be revoked or deleted
  • The amount of data in cookies is small and it is very portable to store Session ids

Disadvantages of Session authentication

  • Session ID sharing issues in distributed/cross-server architectures

In the distributed architecture, after a client passes the authentication on one server, the Session ID is stored in the current server only. When a client accesses another server, it cannot find the previous Session ID. In this case, authentication fails. One way to ensure that all servers have the same Session ID is to have all servers use a shared Redis cache (as shown in the figure above).

JWT token authentication

In the JWT (JSON Web Token) authentication model, the server does not return the Session ID after the user logs in, but returns the signed (encrypted) Token string to the client. The Token for this signature is essentially a JSON object that contains authentication information that the server signed with a private key or public/private key.

In subsequent HTTP requests, the client simply needs to pass the JWT encrypted string in the request and ensure that each server instance can decrypt the Token and authenticate the user.

The advantages of JWT

There is no need to use a cache/database to store Session ids

The disadvantage of JWT

A Token cannot be revoked from the server; the server can only determine whether the Token is valid

This article first published wechat public account: a little tutorial. Welcome to pay attention to the public account, get the exclusive arrangement of learning resources and daily dry goods push. If you are interested in my series of tutorials, you can also check out my website: yiidian.com