Review safety

Authentication/Authorization

  • Authentication: Verifies the identity of the target object. For example, logging in to a system with a user name and password is authentication.
  • Authorization: Grants operation rights to target objects that pass the authentication. To put it more simply:

Certification solves the question of who you are. Empowerment solves the “what can you do” problem.

For normal Web applications, we know that HTTP is stateless, so the client and server need to figure out how to make the conversation stateful. For example, only logged-in users have the permission to invoke certain interfaces. After logging in, you need to remember that the user is logged in. The common approach is to use the session mechanism. The common session model works like this:


image.png

  • After the user logs in to the browser, the server generates a unique session ID for the user, which is stored in the storage service (such as MySql and Redis) on the server
  • The session ID is also returned to the browser and stored in the browser cookie with the SESSION_ID KEY
  • If the user visits the site again, the SESSION_ID in the cookie will be sent to the server along with the request. The server can determine whether the user is logged in by checking whether the SESSION_ID is already in Redis

In theory, the JWT mechanism could replace the session mechanism. Users do not need to log in in advance, and the backend does not need Redis to record user login information. The client saves a valid JWT locally. When the user needs to call the interface, the legal JWT is attached. Each time the interface is called, the backend uses the JWT attached to the request to verify the validity. This also indirectly achieves the authentication user’s purpose

But can JWT really replace the session mechanism? What are the pros and cons of doing this?

The purpose of JWT is not to hide or keep the data secret, but to ensure that the data is actually created by an authorized person (and not tampered with)

Remember, when you get JWT, you can decode headers and payloads without secret, because headers and payloads are just encoded in Base64, The purpose of coding is to facilitate the transmission of data structures. Although the process of creating signature is similar to encrypt, it is essentially an act of signing to ensure data integrity and does not actually encrypt any data

Second, the defects of JWT in Web applications

Disadvantage 1: The deregistration scenario cannot be met

In the traditional session+cookie scheme, the user clicks logout and the server clears the session, because the state is stored on the server. JWT schemes are more difficult because JWT is stateless and the server verifies validity through calculations. It is not stored, so even if the client deletes the JWT, the JWT is still alive, but in a floating state.

Disadvantage 2: The password cannot be changed

Changing the password is slightly different. Assuming that the number is arrived, after changing the password (it is the user’s password, not JWT’s Secret), the number thief can still access the system within the validity period of the original JWT. Therefore, it is not enough to just clear the cookie.

Disadvantage 2: The token renewal scenario cannot be met

We know that as long as you use wechat every day, you do not need to re-log in, because there is a token renewal, because the traditional cookie renewal scheme is generally built in the framework, the session validity period is 30 minutes, if there is access within 30 minutes, the session validity period will be renewed to 30 minutes. JWT’s payload has an expiring time parameter that represents the timeliness of a JWT. The JWT’s payload is a signer of the expiring time, and the JWT’s payload is a signer of the expiring time. JWT features naturally do not support renewals!

Iii. JWT application scenarios

One-time validation

For example, after registering, users need to send an email asking them to activate their accounts. Usually, there needs to be a link in the email. This link should have the following features: it can identify the user, it should be time-sensitive (usually only allowed to activate within a few hours), and it should not be tampered with to activate other possible accounts

This scenario is very similar to JWT, where the payload is a fixed parameter for which iss writer and EXP expiration time are prepared.

Four,

Using JWT in Web applications just makes it more complex. In the vast majority of web applications, the traditional cookie-session mechanism works better. JWT is suitable for simple restful API authentication. Issue a JWT with a fixed validity period to reduce the risk of JWT exposure. Do not do server state management for JWT, so as to reflect the advantages of STATeless JWT.