Github address for this article

Before reading this article, it is recommended to read the following articles:

  • Cookie, Session, Token, JWT
  • Design of multi-platform identity Authentication architecture based on Token

As mentioned in the article above, account architecture has become the necessary cornerstone of an Internet product, often a server (or a single account server) with N clients.

Here are the differences between Token and JWT:

The same:

  • Are tokens to access resources
  • Can record user information
  • Both make the server stateless
  • The client can access the protected resources on the server only after the authentication is successful

The difference between:

  • Token: When authenticating the Token sent from the client, the server also needs to query the database to obtain user information and verify whether the Token is valid.
  • JWT: encrypts the Token and Payload and stores them on the client. The server only needs to use key decryption for verification (which is also implemented by the JWT itself). The JWT does not need to query or reduce the query database, because the JWT contains user information and encrypted data.

Common authentication modes are as follows:

  • Session-cookie: After the front and back ends are separated, the usage frequency decreases greatly.
  • Token authentication (including JWT, SSO) : commonly used in small and medium-sized projects;
  • OAuth2.0 (Open Authorization) : commonly used in medium and large projects, especially services that will be open to the outside world;

OAuth2.0

The author recommends OAuth2.0, which is mature in design and widely used. There are many ready-made third-party packages for the back end, which reduces the difficulty of access.

Generally, access_token has a short validity period, while refresh_Token has a long validity period (such as one month or one year). In addition, the response field of the third-party platform does not contain the expiration time of refresh_Token. You need to pay attention to the document and record the expiration time of refresh_Token yourself.

In addition, different development platforms manage refresh_token differently, for example, Douban.com and Baidu Cloud. Refresh_token can only be used once. Therefore, when refresh_Token is used to update access_token, a new refresh_token is returned.

The following is an excerpt from wechat’s development document:

{ 
    "access_token":"ACCESS_TOKEN"."expires_in":7200."refresh_token":"REFRESH_TOKEN"."openid":"OPENID"."scope":"SCOPE"."unionid": "o6_bmasdasdsad6_2sgVt7hMZOPfL"
}
Copy the code

Refresh the validity period of the Access_Token. The validity period of the access_Token is short (currently 2 hours). When the access_token times out, refresh_token can be refreshed. The access_token refresh results are as follows:

  • If the access_token has timed out, refresh_token will obtain a new access_token with a new timeout period.
  • If the access_token does not time out, refresh_token does not change the access_token, but the timeout period is refreshed, which is equivalent to renewing the access_token.

2. The refresh_token has a long validity period (30 days). When the refresh_token becomes invalid, users need to reauthorize it.

Therefore, the correct login process is as follows :(take refresh_token validity period of 30 days and access_token validity period of 2 hours as examples)

  1. Check whether there is a time cache for refresh_token:
    1. If no, perform the login process.
    2. If yes, check whether refresh_token is expired. If the current time-cache timestamp >= 30, refresh_token has expired, and you need to log in again.
  2. If refresh_token is not expired, check whether access_token is expired:
    1. Read expire_date to check whether the access_token is expired. If the current time – expire_date > 2 hours, it is expired. Obtain a new access_token and expire_date and cache the result locally.
    2. If the access_token does not expire, the interface is invoked.
  3. The valid Access_token is used to make interface requests and obtain data in different service scenarios.

For the front end, consider the following questions:

  • When a service request is executed, the Access_Token becomes invalid. Refresh_token is automatically executed, and the previous service request is retried with the latest Access_token.
  • When multiple service requests are accessed concurrently, all the requests are invalid, ensuring only one refresh_token operation.
  • Reasonably throttling refresh_token;
  • Business request +refresh_token Reasonable degrade policy;
  • Special scenario: No refresh_token whitelist policy and SSO.

Simply put, when an access_token expires, the access_token is refreshed automatically without affecting normal business requests, and concurrent refreshes are considered.

After analyzing the previous login process, we found that there are two time points that can be adjusted. Can we change the time points to reduce the application robustness problems caused by token expiration? For example, in reality, more than 90% of users will sleep between 01:00 and 04:00, so an APP, web page and other resident front desk will not be more than 1 day:

  • The value of refresh_token is expired>= 30 instead of >= 28;
  • Access_token expired byFixed 2 hours changed to longer time difference (next day 3am - current time);

In services such as IM that may limit sso, the single-token mode (with no validity period) is more appropriate because IM is usually a long connection mode, and the server records the unique ID of each login device, and the server actively notifies the client when the token expires.

Application of Token in visitor mode

  1. To prevent crawlers and robots, the following is taken from the Token design discussion in API interface design:

* {Session} in the signature algorithm is encrypted information used to determine the request of the current page. * {browser summary} will record the visitor's IP and browser information to prevent token from being used by different machines. Usage scenarios: * Media temporary access page to prevent machine crawler from accessing other interfaces indefinitely after acquiring token * Dynamic temporary interface to prevent machine from continuously obtaining data in dynamic temporary page informationCopy the code
  1. Visitors how to transfer to the logged in user mode user behavior In a certain electric business products, users xiao Ming in visitor mode using this product for a period of time, such as search the bicycles, laptops and other commodities, suddenly one day to sign up and log on to the product, then you need to put before the browser data associated with xiao Ming’s account, So that the backstage to xiaoming continue to recommend the goods he is interested in.

References:

  • App OAuth authorized login, Access Token, and Refresh token
  • Website application wechat login development guide
  • The token scheme is automatically refreshed
  • Cookie, Session, Token, JWT
  • Design of multi-platform identity Authentication architecture based on Token
  • Discussion on Token design in API interface design