Login technology selection
When reviewing the login verification method of the project, I found that the previous method was not reasonable, so I came up with the idea of learning to sort out the login method, so I came up with this article, which mainly discusses the theory. The actual code can refer to the existing articles on the Internet 1
. JWT+redis (this method was used in the project at the beginning, but it was found to be unreasonable later)
2. token+redis
3. JWT
4. session
JWT
Definition and Structure
JWT——Json web token
is a token token, which is a String string consisting of 3 parts, separated by dots in the middle
JWT structure:
header header:
contains the type of token and the signature algorithm used
Payload load
is the place to load data , including declarations (statements about user information (username, password) and other data)
signature Signature
The header and payload are base64-encrypted data , which is salted and then encrypted twice.
JWT login verification process
1. When logging in for the first time, the front-end adjusts the login interface of the back-end, and sends the user name and password.
2. The back-end receives the request, verifies the user name and password, and the verification is successful. The data containing user information is used as the Payload of JWT , and it is combined with The JWT Header is base64 coded and spliced separately and then signed to form a JWT Token . The formed JWT Token is a string like lll.zzz.xxx
3. The front end gets the token and jumps to the routing page
4. The front end adjusts the back end every time The interface must add token in the request header.
5. The backend judges whether there is a token in the request header. If there is a token, it will get the token and verify the token. If the verification is successful, it will return data, and if the verification fails (for example: token expired), it will return 401 , there is no token in the request header and 401 is returned
Advantages and disadvantages of JWT:
1. JWT is stateless, the server does not need to store login status information, reducing server pressure
2. No need to rely on cookies, so CSRF attacks can be avoided
1. The JWT is still valid in scenarios such as logout and login, and the server cannot actively invalidate the token.
2. Renewal issues
Based on the above scenario: JWT is suitable for the following occasions:
- Short validity period
- only want to be used once
- Cross-domain login (inconsistent protocol, domain name, and port number) ( this is also one of the reasons why our project uses JWT, and there are two backends of Springboot and Flask)
For example, after the user registers, send an email to activate the account. Usually, there needs to be a link in the email. This link needs to have the following characteristics: it can identify the user, and the link is time-sensitive (usually only allowed to be activated within a few hours), Cannot be tampered with to activate other possible accounts, one-time. This scenario is suitable for using jwt.
For the shortcomings of JWT, is there any solution?
1. The token is still valid after logout
** Store the token in redis or establish a blacklist mechanism**
Redis memory database is a good choice here. If you need to invalidate a token, just delete the token from redis directly. However, this will lead to the step of querying the existence of the token from the DB every time the token is used to send a request, and it violates the stateless principle of JWT.
2. The issue of renewal
We set the expiration time for each jwt separately in redis, and refresh the expiration time of the jwt every time you access it. If the jwt does not exist in redis, it will be considered expired. But this also violates the stateless principle of JWT.
To sum up, JWT is only suitable for some small projects with low security requirements. Using JWT+redis actually violates the original intention of JWT design;
Redis+token
1 Use the user id as the key, the generated token as the value, cache it in redis and set the expiration time
2 use the generated token as the key, user information as the value, cache it in redis and set the expiration time, and
finally return the token and user information to For the front end, the front end puts the token in the header and carries it when calling other interfaces.
If you log out, just delete the above two information from redis
Session + Cookie
Reference Article 1
Reference Article 2
Why use session?
The stateless nature of the HTTP protocol means that each HTTP request of the client is independent , there is no direct relationship between multiple consecutive requests, and the server will not actively retain the status of each HTTP request
Session login verification workflow
Many times we use SessionID to implement specific users, and SessionID is usually stored in Redis. for example:
- The user successfully logs in to the system, and then returns a Cookie with SessionID to the client.
- When the user initiates a request to the backend, the SessionID will be brought, so that the backend will know your identity status.
Session-Cookie under multi-service nodes
1. The user sessions saved by each server are consistent.
2. Use a single data node for saving
Can Session still be used if there is no Cookie?
1. It is a common practice to save the SessionID in the cookie, and it can also be placed in the URL of the request https://harry.com/?Session_id=xx