Recently, I started to work on a new project, a toC project. The login interface was written by an intern before. By chance, another colleague told me that the login interface was modified to improve security after taking a look at the project code.

background

The login interface of a project I was working on was written by the intern. The login design was simply to submit the user name and password to obtain the token, and the token expired for 30 days. Then another colleague with a longer working experience modified the code to obtain two tokens through login:

  • 1.accessToken: The permission that is actually used to get data
  • 2.refreshToken: used to obtainaccessToken

Why doubletoken?

As we all know, token is to prevent the user information from being passed and hijacked, but if the token has no expiration time or expires for a long time, then obviously the token is not safe to be hijacked, and the token loses its significance.

Therefore, everyone must think: then set the token expiration time to be shorter.

Yes, accessToken is generally supposed to expire at a shorter time, but this can be a hassle for users.

Because token expiration means you have to log in again, imagine you are browsing well, suddenly let you off line and ask you to log in again, the heart must want to swear.

When does the user need to log in again?

There are three main cases:

  • 1. If a user does not perform any operation for a long time or defines a inactive user, the user will be automatically kicked off and redirected to the login page. The timeout period can be customized.
  • 2. If both tokens are invalid, a user needs to log in to the system again to obtain a new double token.
  • 3. If a risk is detected, you can log in again to obtain the token.

When both tokens expire, the user is required to re-log in. Refreshtokens are only used to obtain accessToken and will not be frequently used in requests. For accessToken, their expiration time is very short. Decryption takes time even if it is intercepted, and the token itself expires quickly, so this design is more secure.

So that’s how it ends? Obviously, it is not the front end. We also need to make users insensitive to the operation of obtaining accessToken by using refreshToken, so as to ensure more security and reasonable and not to affect user experience.

How to implementrefreshTokenTo obtaintokenInsensitive refresh?

Generally speaking, there are three methods:

  • 1. The back end returns the expiration time. The front end determines the current time and expiration time and invokes the token refresh interface

    Disadvantages: The backend needs to provide an additional Token expiration time field; If the local time is tampered, especially if the local time is slower than the server time, interception will fail.

  • 2. Perform scheduled tasks and use them periodicallyrefreshTokenTo obtainaccessToken

    It wastes resources and consumes performance, and is not recommended.

  • 3. Intercept in the response interceptor and judge the backendtokenAfter returning an expiration, the refresh token interface is called

    Better solution, which is the one I use in my project, and AXIos has an API to do response interception

Here is a simple implementation demo:

import axios from 'axios'; Axios. Interceptors. Response. Use (res = > {/ / token exception if (res) data) code = = = 409) {deleteToken (); router.push('/login') return Promise.reject(); // Update Token} else if (res.data.code === 410) {const {Token} = res.data setToken(Token); // reset token} return res && res.data})Copy the code

conclusion

For the sake of user security, token design is used. To solve the problem of frequent login, dual token design is adopted. At the same time, certain processing needs to be done in the front end.