Token: How to reduce the traffic pressure of user identity authentication?

Many websites usually use the Session method to implement user login authentication in the early stages. Specifically, when a user successfully logs in, the server will store the user's relevant information in the Session cache and generate a unique session_id, which is stored in the user's cookie. After that, each time the user sends a request, the session_id will be carried, and the server will use the ID to find the user record in the Session cache to perform identity authentication and user information management.

The advantage of this user authentication method is that all user information is stored on the server side, no sensitive data is exposed to the client, and each logged-in user has a shared session cache space. However, as the website traffic grows, this design will also expose obvious shortcomings - user-centered identity authentication is unstable under high concurrency.

Specifically, the user center needs to maintain a large number of session caches, which are frequently accessed by various business systems. If the cache fails, all subsystems that rely on it will be unable to confirm the user's identity, resulting in service interruption. This is mainly due to the high coupling between the session cache and each subsystem. Each request needs to access the cache at least once, so the cache capacity and response speed directly affect the QPS upper limit of the entire site, reduce the isolation of the system, and cause the subsystems to affect each other.

So, how can we reduce the coupling between the user center and each subsystem to improve system performance? Let’s discuss this together.

JWT login and token verification

A common approach is to use a signed encrypted token, which is an industry standard for login, namely JWT (JSON Web Token):

picture

The above figure is the JWT login process. After the user logs in, the user information will be placed in an encrypted and signed token. Each request will put this string in the header or cookie and bring it to the server. The server can directly obtain the user's information by decrypting the token without making any interactive requests with the user center.

The token generation code is as follows:

 import "github.com/dgrijalva/jwt-go" //签名所需混淆密钥不要太简单容易被破解//也可以使用非对称加密，这样可以在客户端用公钥验签var secretString = []byte("jwt secret string 137 rick") type TokenPayLoad struct { UserId uint64 `json:"userId"` //用户id NickName string `json:"nickname"` //昵称jwt.StandardClaims //私有部分} // 生成JWT token func GenToken(userId uint64, nickname string) (string, error) { c := TokenPayLoad{ UserId: userId, //uid NickName: nickname, //昵称//这里可以追加一些其他加密的数据进来//不要明文放敏感信息，如果需要放，必须再加密//私有部分StandardClaims: jwt.StandardClaims{ //两小时后失效ExpiresAt: time.Now().Add(2 * time.Hour).Unix(), //颁发者Issuer: "geekbang", }, } //创建签名使用hs256 token := jwt.NewWithClaims(jwt.SigningMethodHS256, c) // 签名，获取token结果return token.SignedString(secretString) }

It can be seen that this type of token contains an expiration time. Tokens that are close to expiration will automatically communicate with the server to update on the client side. This design can greatly increase the difficulty of maliciously intercepting client tokens and forging user identities. At the same time, the server can also be decoupled from the user center. The business server only needs to parse the token in the request to obtain user information, without having to access the user center for each request. The refresh of the token can be initiated by the client to the user center, without the need for the business server to frequently request the user center to replace the token.

So, how does JWT (JSON Web Token) ensure that data cannot be tampered with and ensure data integrity? Next, let's take a look at its composition.

picture

The data structure of the decrypted JWT token is shown in the following figure:

 //header //加密头{ "alg": "HS256", // 加密算法，注意检测个别攻击会在这里设置为none绕过签名"typ": "JWT" //协议类型} //PAYLOAD //负载部分，存在JWT标准字段及我们自定义的数据字段{ "userid": "9527", //我们放的一些明文信息，如果涉及敏感信息，建议再次加密"nickname": "Rick.Xu", // 我们放的一些明文信息，如果涉及隐私，建议再次加密"iss": "geekbang", "iat": 1516239022, //token发放时间"exp": 1516246222, //token过期时间} //签名//签名用于鉴定上两段内容是否被篡改，如果篡改那么签名会发生变化//校验时会对不上

How does JWT verify whether the token is valid, whether the token is expired, and whether it is legal? The specific methods are as follows:

 func DecodeToken(token string) (*TokenPayLoad, error) { token, err := jwt.ParseWithClaims(token, &TokenPayLoad{}, func(tk *jwt.Token) (interface{}, error) { return secret, nil }) if err != nil { return nil, err } if decodeToken, ok := token.Claims.(*TokenPayLoad); ok && token.Valid { return decodeToken, nil } return nil, errors.New("token wrong") }

The decoding of JWT (JSON Web Token) is relatively simple. Both the first and second parts are encoded in Base64. Decoding these two parts will get all the data in the payload, including the user nickname, UID, user permissions, and the expiration time of the token. To verify whether the token is expired, just compare the expiration time with the current time to confirm whether the token is valid. The legitimacy of the token is verified through signature verification. Any modification of the information cannot pass the signature verification. If the token passes the signature verification, it means that it has not been tampered with and is a legal token that can be used directly.

This process is shown in the following figure:

picture

The Token method can significantly reduce the pressure on the user center, and there is no need to frequently access the user information interface. Each business server only needs to decode and verify the legitimacy of the Token to directly obtain user information. However, this method also has some disadvantages. For example, when a user is blacklisted, the client usually has to wait until the Token expires before automatically logging out, which will cause a certain delay in management.

If you want to achieve real-time management, you can temporarily store the newly generated Token on the server and compare it with the cached Token every time the user requests it. However, such an operation will affect system performance, so a few companies will adopt this method. In order to improve the security of the JWT system, the Token is usually set with a shorter expiration time, usually about fifteen minutes. After the Token expires, the client will automatically request an update from the server.

Token replacement and offline

So how do you replace the JWT token and verify it offline? The specific server-side replacement is very simple. As long as the client detects that the current token is about to expire, it will actively request the user center to replace the token interface and regenerate a token that will expire in fifteen minutes. However, if it is not replaced within fifteen minutes, the client login will fail. In order to reduce such problems and ensure that the client can still work normally when offline for a long time, the industry generally uses a dual token method. You can see the flowchart below for details:

picture

In this solution, two types of tokens are used:

1. Refresh Token: used to replace Access Token, valid for 30 days.
2. Access Token: used to store current user information and permission information, and is replaced every 15 minutes.

When the client attempts to request the user center to change the token but fails, and the client is offline, the system can still operate normally as long as the local refresh token has not expired. The client can continue to use the access token until the refresh token expires, at which time the system will prompt the user to log in again. In this way, even if the user center fails, the business system can still operate normally for a period of time, improving the robustness of the system and user experience.

The implementation of the user center detection token replacement is as follows:

 //如果还有五分钟token要过期，那么换token if decodeToken.StandardClaims.ExpiresAt < TimestampNow() - 300 { //请求下用户中心，问问这个人禁登陆没//....略具体//重新发放token token, err := GenToken(.....) if err != nil { return nil, err } //更新返回cookie中token resp.setCookie("xxxx", token) }

Safety Tips

When using the JWT scheme, in addition to what is mentioned in the code comments, there are some key considerations worth noting:

1. Ensure communication security: Use the HTTPS protocol to transmit data to reduce the risk of token interception.
2. Limit the frequency of token replacement: Control the number of token replacements and refresh tokens regularly. For example, limit the number of times a user's Access Token can be replaced 50 times a day. If the number exceeds the limit, the user is required to log in again and the token is replaced every 15 minutes. This can reduce the potential impact of a stolen token.
3. Securely store Web Tokens: For Web users, when Tokens are stored in Cookies, it is recommended to set HttpOnly and SameSite=Strict tags to prevent Cookies from being stolen by malicious scripts.