Yesterday we learned that whether I use token or session is better. I said it doesn’t make any difference. So today I went back to JWT (JSON Web Token) and finally understood the meaning of JWT.
The front end saves the login id returned by the back end locally, and then carries it to the back end each time. Whether it is through cookie or header with token, it is global configuration, so there is no difference between the front end and the back end.
If the background is through a session, the server will generally save relevant data to the login request into the session, and then return a sessionID to the user to write the user’s cookie. After that, the user will carry the cookie with each request, and the server obtains user information through this ID. It is said that this method requires the server to store sessions and occupies memory, and that each time carrying bandwidth is wasted. I think these two problems are not a problem. Generally, the front end uses other methods, which are also global configuration, and will carry authentication identification.
The most important thing about using the session method is that it has a great impact on the server cluster and the architecture of cross-domain services, because cookies are not supported across. If it is a cluster, session data should be shared so that each server can read the session. Of course, if it’s a single server, there’s nothing wrong.
To solve this session problem, JWT is the perfect solution. To put it simply, JWT is to turn user information into Base64 and return it to the front end with signature, which is stored by the front end and carried on each request. Then, the background determines whether it has been tampered with by signature. If it is correct, the user information will be directly used. In this way, the server does not need to store sessions and can obtain user information whether it is cross-domain or cluster.
JWT has three parts:
Header Header: {” ALG “: “HS256″,” TYP “: “JWT”}, ALG is the signature algorithm, the default is HS256, tyP is the token type, JWT is JWT by default.
Payload Payload Payload Payload Payload Payload Payload Payload
Iss (Issuer) : indicates the issuer
Exp (expiration Time) : expiration time
Sub (subject) : indicates the topic
Aud (audience) : Audience
NBF (Not Before) : indicates the effective time
Iat (Issued At) : time of issue
Jti (JWT ID) : indicates the ID
It’s official, you can add any field you want, like ID or something like that.
Singnature signature, sign the first two parts to prevent tampering. A public key is the same as a public key. The key is known only to the server, but not to the client. And then you convert it to Base64, and you use it in between. The splice is concatenated into a string that is returned to the front end.
After the current end receives the token, it can save cookies or localstorage. It should be noted that cookies cannot cross domains, so most of them are stored in localstorage, and then add a field in the header to send to the background. After receiving the signature, the background compares it with the signature sent to the background through Header and Payload to check whether the signature is tampered with.
This part just introduces the general principle of JWT, as for how to prevent tampering signature will not be studied. However, it is important to note that converting to Base64 is not encrypted unless you do it yourself, so you can’t put sensitive data into JWT. JWT simply solves user session problems. Like the session ID used to identify the server session, the session ID is not encrypted.
The downside of JWT is that the signature cannot be repealed at any time and is valid until it expires, but the server can do some logic to resolve this problem.
As for how to solve the security problem of encryption, background technology should be very mature, here or finally emphasize that JWT itself is only to solve the problem of user session, there is no encryption itself, the mechanism of encryption background through another method to achieve.
