Double-token authorization refreshing method, device and system based on dynamic expiration tolerance

Abstract

The invention relates to a double-token authorization refreshing method, device and system based on dynamic expiration tolerance. The method comprises the following steps: modeling the dynamic expiration tolerance according to the number of requests per second qps of a key API, the response time Tresp of the key API and the utilization rate U of a database connection pool; for a first request of which the access token is expired and the refresh token is not expired, if the expiration duration of the access token corresponding to the request is within the corresponding dynamic expiration tolerance, setting a distributed lock for the request, triggering a token refresh mechanism at the same time, and after the token refresh mechanism is executed, releasing the distributed lock; and for a subsequent request of the first request, if the expiration duration of the access token corresponding to the request is within the corresponding dynamic expiration tolerance, the token refreshing mechanism is not triggered, and normal access is directly allowed. According to the method, modeling is performed on the dynamic expiration tolerance, and the pain points and the problems that in the prior art, expiration tolerance time parameters are fixed, and static configuration is not flexible are solved.

Description

Technical Field

[0001] The present invention relates to the technical field of network authority control, and in particular to a dual-token authorization refresh method, device and system based on dynamic expiration tolerance. Background Art

[0002] Patent CN110266703A solves the problem that when a large number of network requests need to obtain new tokens, it is currently impossible to effectively handle concurrent refresh of expired tokens. The solution is to add a synchronization lock to the client refresh operation so that the refresh operation can successfully send the network request for the refreshed token and continuously and orderly complete the refresh operation of the network request token. The above solution is similar to using Promise on the client Web (Promise is a key technology for solving asynchronous programming problems), LinkedBlockingQueue on Android Java (LinkedBlockingQueue is a blocking queue based on a linked list), and NSOperationQueue on iOS (NSOperationQueue is a multi-threaded solution provided by iOS). Its business pain points and inefficiencies are: multiple sets of similar codes need to be maintained for Web, mini-programs, Android, and iOS channels, which leads to the need to maintain different technology stack codes for multiple platforms, which is a huge workload and requires a high level of understanding of business details; further, as the number of terminals and access platforms increase, the same logic needs to be re-encoded on different heterogeneous and differentiated platforms each time, and the amount of code is large. When defects are encountered, all defects need to be modified again on all platforms; when the code needs to be updated, refactored and optimized, it is necessary to perform differentiated code time and business logic synchronization for multiple platforms, multiple languages, multiple operating systems, and multiple architectures, resulting in poor maintainability, low modifiability, and insufficient scalability. Secondly, another defect of patent CN110266703A is that concurrent, sequential execution, and processing similar to synchronous locks will reduce system efficiency, reduce system concurrency, and reduce system throughput.

[0003] In response to the defects of the above-mentioned patent CN110266703A, patent CN112003852B abandons processing on the client side and turns to the server backend for effective processing. Patent CN112003852B performs multi-level, three-dimensional, and differentiated intelligent judgment on the current request on the server side according to multi-dimensional judgment conditions, avoiding the disorder and repeated refresh problems caused by concurrent competing refresh requests belonging to the "expiration tolerance" time period; at the same time, the unified framework processing on the server side avoids a lot of redundant and heavy work of repeated encoding on different clients to perform token refresh adaptation; Patent CN112003852B further avoids the performance and efficiency loss problems caused by the traditional use of synchronization mechanisms, lock mechanisms or ordered queues.

[0004] However, when considering expiration tolerance, patent CN112003852B selects a static configuration value for the expiration tolerance time, and does not link it with the resource utilization and refined load of the current server; in addition, when considering concurrent requests for expired tokens, patent CN112003852B does not fully classify abnormal token requests, and there are omissions, which does not fully cover the scenario problem of expired requests.

[0005] In view of this, how to overcome the defects of existing technologies, how to link expiration tolerance with the current server's resource utilization and refined load, and how to cover more scenarios of expired requests have become important technical issues that the industry urgently needs to solve. Summary of the invention

[0006] In view of the defects or improvement needs in the prior art: how to link the expiration tolerance with the resource utilization and refined load of the current server, and how to cover more scenarios of expired requests. The present invention provides a dual-token authorization refresh method, device and system based on dynamic expiration tolerance. In terms of technical innovation, critical resources are protected, dynamic expiration tolerance time is constructed, and multi-dimensional performance indicators of the back-end server are combined to integrate the number of requests per second (Queries PerSecond, abbreviated as: QPS) of the key application programming interface (Application Programming Interface, abbreviated as: API), the response time (Tresp) of the key API, and the utilization rate (U) of the database connection pool. The multi-dimensionally collected server performance indicators, innovatively model the dynamic expiration tolerance time, optimize the pain points and problems of the fixed expiration tolerance time parameters, inflexible static configuration, and no linkage with the resource utilization and refined load of the current server in patent CN112003852B. Furthermore, in terms of business innovation, all scenarios and categories of expired abnormal requests are fully covered by introducing distributed locks.

[0007] The present invention adopts the following technical solution:

[0008] In a first aspect, the present invention provides a dual-token authorization refresh method based on dynamic expiration tolerance, comprising:

[0009] The dynamic expiration tolerance is modeled based on the number of requests per second (qps) of the key API, the response time (Tresp) of the key API, and the utilization rate (U) of the database connection pool. When qps, Tresp, and U are smaller, the dynamic expiration tolerance is smaller; when qps, Tresp, and U are larger, the dynamic expiration tolerance is larger.

[0010] For the first request whose access token has expired and whose refresh token has not expired, if the expiration time of the access token of the corresponding request is within the corresponding dynamic expiration tolerance, a distributed lock is set for the request and the token refresh mechanism is triggered. After the token refresh mechanism is executed, the distributed lock is released.

[0011] For subsequent requests of the first request, if the expiration time of the access token of the corresponding request is within the corresponding dynamic expiration tolerance, the token refresh mechanism will not be triggered and normal access will be allowed directly.

[0012] In some embodiments, modeling the dynamic expiration tolerance according to the number of requests per second qps of the key API, the response time Tresp of the key API, and the utilization rate U of the database connection pool specifically includes:

[0013] Define a system busy rate:

[0014]

[0015] Among them, i represents the index of the current user, α, β, γ represent coefficients, and Tresp aver represents the average response time;

[0016] Assuming that the maximum expiration tolerance is T_max and the minimum expiration tolerance is T_min, the dynamic expiration tolerance tolerance_t_window(i,U,qps) is:

[0017]

[0018] Among them, tolerance_t_window(i,U,qps) dynamically takes values ​​in [T_min,T_max].

[0019] In some embodiments, the token refresh mechanism specifically includes:

[0020] Get a new access token and a new refresh token;

[0021] Set the current access token to the last invalidated access token;

[0022] Set the new access token as the current access token.

[0023] In some embodiments, a refresh rule is set for the request, and the corresponding refresh rule is selected for execution according to the distributed lock state, the access token state of the request, and whether the expiration time is within the dynamic expiration tolerance;

[0024] When the state of the distributed lock is that the distributed lock can be obtained, the state of the requested access token is the current access token, and the expiration time is within the dynamic expiration tolerance, the first refresh rule is selected for execution; the first refresh rule includes: setting a distributed lock for the request and triggering a token refresh mechanism at the same time, and releasing the distributed lock after the token refresh mechanism is executed.

[0025] In some embodiments, when the distributed lock state is occupied, the requested access token state is the current access token, and the expiration time is within the dynamic expiration tolerance, the second refresh rule is selected for execution; the second refresh rule includes: not triggering the token refresh mechanism for the request, and directly allowing normal access.

[0026] In some embodiments, when the state of the distributed lock is that the distributed lock can be acquired, the state of the requested access token is the access token that expired last time, and the expiration time is within the dynamic expiration tolerance, the third refresh rule is selected for execution; the third refresh rule includes: not triggering the token refresh mechanism for the request, and directly allowing normal access.

[0027] In some embodiments, when the requested access token status is the current access token and is not expired, the fourth refresh rule is selected for execution; the fourth refresh rule includes: directly allowing normal access without other judgments.

[0028] In a second aspect, the present invention further provides a dual-token authorization refresh device based on dynamic expiration tolerance, the device comprising:

[0029] At least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the processor to execute the dual token authorization refresh method based on dynamic expiration tolerance described in the first aspect.

[0030] In a third aspect, the present invention further provides a dual-token authorization refresh system based on dynamic expiration tolerance, applying the dual-token authorization refresh method based on dynamic expiration tolerance as described in the first aspect, the system includes a dynamic expiration tolerance modeling module, a first request processing module and a subsequent request processing module, wherein:

[0031] The dynamic expiration tolerance modeling module is used to: model the dynamic expiration tolerance according to the number of requests per second qps of the key API, the response time Tresp of the key API, and the utilization rate U of the database connection pool; when qps, Tresp and U are smaller, the dynamic expiration tolerance is smaller; when qps, Tresp and U are larger, the dynamic expiration tolerance is larger;

[0032] The first request processing module is used to: for the first request whose access token has expired and whose refresh token has not expired, if the expiration time of the access token of the corresponding request is within the corresponding dynamic expiration tolerance, set a distributed lock for the request and trigger a token refresh mechanism at the same time, and release the distributed lock after the token refresh mechanism is executed;

[0033] The subsequent request processing module is used for: for subsequent requests of the first request, if the expiration time of the access token of the corresponding request is within the corresponding dynamic expiration tolerance, the token refresh mechanism is not triggered and normal access is directly allowed.

[0034] In a fourth aspect, the present invention further provides a non-volatile computer storage medium storing computer executable instructions, which are executed by one or more processors to complete the dual-token authorization refresh method based on dynamic expiration tolerance described in the first aspect.

[0035] Compared with the prior art, the present invention provides a dual-token authorization refresh method, device and system based on dynamic expiration tolerance, and its beneficial effects are: in terms of technical innovation, critical resources are protected, dynamic expiration tolerance is constructed, and multi-dimensional performance indicators of the back-end server are combined, and server performance indicators collected in multiple dimensions such as the number of requests per second qps of the key API, the response time Tresp of the key API, and the utilization rate U of the database connection pool are integrated, and dynamic expiration tolerance is innovatively modeled, which optimizes the pain points and problems of the fixed expiration tolerance time parameters, inflexible static configuration, and no linkage with the current server's resource utilization and refined load in the patent CN112003852B.

[0036] Furthermore, in terms of business innovation, by introducing distributed locks, all scenarios and categories of problems related to expired abnormal requests are fully covered. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the following briefly introduces the drawings required for use in the embodiments of the present invention. Obviously, the drawings described below are only some embodiments of the present invention, and for ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0038] Figure 1 A flowchart of a dual-token authorization refresh method based on dynamic expiration tolerance provided in Example 1 of the present invention;

[0039] Figure 2 A module diagram of a dual-token authorization refresh system based on dynamic expiration tolerance provided in Example 1 of the present invention;

[0040] Figure 3 A schematic diagram of the timing of request cases provided in Example 2 of the present invention;

[0041] Figure 4 A schematic diagram of the structure of a dual-token authorization refresh device based on dynamic expiration tolerance provided in Example 3 of the present invention. DETAILED DESCRIPTION

[0042] The present invention is described in detail below in conjunction with specific embodiments. The following embodiments will help those skilled in the art to further understand the present invention, but do not limit the present invention in any form. It should be noted that, for those of ordinary skill in the art, without departing from the concept of the present invention, several variations and improvements can also be made. These all belong to the protection scope of the present invention. It should be noted that, if there is no conflict, the various features in the embodiments of the present invention can be combined with each other, all within the protection scope of this application. In addition, although the functional module division may be performed in the device schematic diagram, and the logical order may be shown in the flow chart, in some cases, it may be different from the module division in the device, or the steps shown or described in the order in the flow chart may be performed.

[0043] Unless otherwise defined, all technical and scientific terms used in this specification have the same meaning as those commonly understood by those skilled in the art of the present invention. The terms used in this specification and in the specification of the present invention are only for the purpose of describing specific embodiments and are not intended to limit the present invention. In addition, the technical features involved in each embodiment of the present invention described below can be combined with each other as long as they do not conflict with each other.

[0044] Unless the context requires otherwise, throughout the specification and claims, the term "including" is to be interpreted as open inclusion, that is, "including, but not limited to". In the description of the specification, the terms "one embodiment", "some embodiments", "exemplary embodiments", "examples", "specific examples" or "some examples" and the like are intended to indicate that specific features, structures, materials or characteristics associated with the embodiment or example are included in at least one embodiment or example of the present disclosure. The schematic representation of the above terms does not necessarily refer to the same embodiment or example. In addition, the specific features, structures, materials or characteristics may be included in any one or more embodiments or examples in any appropriate manner, that is, although they may be carried in the embodiments or examples of the above terms due to reasons such as the order and position of appearance, it is not limited to that they can be carried in combination by one embodiment or example.

[0045] Before describing the specific embodiments, the following terms in the embodiments of the present invention are explained:

[0046] OAuth2.0: OAuth (Open Authorization) is an open standard that allows users to authorize third-party mobile applications to access specific private resources of the user in a server without providing usernames and passwords to third-party mobile applications or sharing all their data. OAuth2.0 is a continuation of the OAuth protocol, but is not backward compatible with OAuth 1.0.

[0047] AccessToken: Token is also called a token; in OAuth2.0, AccessToken is a string of characters generated by the server, which is used as a token for client requests. After the first login, the server generates an AccessToken and returns it to the client. In the future, the client only needs to bring this AccessToken to request data, without the need to bring the username and password again. AccessToken came into being when the client frequently requests data from the server, and the server frequently queries the database for usernames and passwords and compares them to determine whether the usernames and passwords are correct and gives corresponding prompts. The purpose of AccessToken is to reduce the pressure on the server, reduce frequent database queries, and make the server more robust.

[0048] refreshtoken: A token is a credential for obtaining protected resources, and of course it must have an expiration date. Otherwise, it can be used forever after logging in once, and the authentication function loses its meaning. A token must not only have an expiration date, but the expiration date cannot be too long; in addition to accesstoken, there is another token called refreshtoken. Usually, the validity period of refreshtoken is longer, while the validity period of accesstoken is shorter. When accesstoken expires, a new accesstoken can be obtained using refreshtoken. If refreshtoken also expires, the user can only log in again.

[0049] Redis: Redis (Remote Dictionary Server), also known as remote dictionary service, is an open source log-type, Key-Value database written in ANSI C language, supporting the network, memory-based or persistent, and providing APIs in multiple languages.

[0050] Distributed lock Redisson: In a single web application, if multiple threads need to access shared resources, we usually use a locking mechanism between threads. At a certain moment, only one thread can operate on this resource, and other threads need to wait for the lock to be released. Java also has some mechanisms for handling locks, such as synchronized. In a distributed environment, when a resource can be accessed and used by multiple systems, in order to ensure that everyone accesses the data consistently, it is required that it can only be used by one system at the same time. At this time, the locking mechanism between threads cannot work, because in a distributed environment, the system will be deployed on different machines, so distributed locks are needed.

[0051] Redisson is a Java In-Memory DataGrid implemented on the basis of Redis. It not only provides a series of distributed Java common objects, but also implements reentrant locks (ReentrantLock), fair locks (Fair Lock), interlocks (Multi Lock), red locks (Red Lock), read-write locks (Read WriteLock), etc., and also provides many distributed services. Redisson provides the simplest and most convenient way to use Redis. The purpose of Redisson is to promote the separation of concerns (Separation of Concern) of users on Redis, so that users can focus more on processing business logic.

[0052] In order to make the purpose, technical scheme and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not intended to limit the present application. The present invention is described in detail below with reference to the accompanying drawings and embodiments.

[0053] Embodiment 1:

[0054] like Figure 1 As shown, an embodiment of the present invention provides a dual-token authorization refresh method based on dynamic expiration tolerance, and the method includes the following steps.

[0055] Step 100: Model the dynamic expiration tolerance based on the number of requests per second qps of the key API, the response time Tresp of the key API, and the utilization rate U of the database connection pool; when qps, Tresp, and U are smaller, the dynamic expiration tolerance is smaller; when qps, Tresp, and U are larger, the dynamic expiration tolerance is larger. It should be noted that the dynamic expiration tolerance is essentially a dynamic grace time. Originally, when the access token carried by a request expires, direct access to the protected resource is not allowed. However, after the dynamic expiration tolerance is set, if the expiration time of the access token carried by the request is less than the corresponding dynamic expiration tolerance time, then it will be allowed to access the protected resource.

[0056] Step 200: For the first request whose access token has expired and whose refresh token has not expired, if the expiration time of the access token of the corresponding request is within the corresponding dynamic expiration tolerance, a distributed lock is set for the request, and the token refresh mechanism is triggered at the same time. After the token refresh mechanism is executed, the distributed lock is released. It should be noted that the scenarios discussed in this embodiment are basically for scenarios where the access token has expired and the refresh token has not expired. In this scenario, the first request carrying the expired access token needs to trigger the token refresh mechanism to re-acquire a new access token, and subsequent requests can be judged according to the dynamic expiration tolerance to see whether they can be allowed to access the protected resources.

[0057] Step 300: For subsequent requests of the first request, if the expiration time of the access token of the corresponding request is within the corresponding dynamic expiration tolerance, the token refresh mechanism is not triggered, and normal access is directly allowed. It should be noted that for subsequent requests of the first request, if the token refresh mechanism is triggered by the first request, in order to avoid repeated triggering of the token refresh mechanism, as long as the expiration time of the access token in the subsequent request is less than the corresponding dynamic expiration tolerance time, access to the protected resource can be allowed without triggering the token refresh mechanism again.

[0058] Based on the above steps, the embodiment of the present invention constructs dynamic expiration tolerance, combines the multi-dimensional performance indicators of the backend server, integrates the server performance indicators collected from multiple dimensions such as the number of requests per second qps of the key API, the response time Tresp of the key API, and the utilization rate U of the database connection pool, and innovatively models the dynamic expiration tolerance, optimizing the pain points and problems of the fixed expiration tolerance time parameters, inflexible static configuration, and lack of linkage with the current server's resource utilization and refined load in patent CN112003852B. Furthermore, by introducing distributed locks, all scenarios and categories of expired abnormal requests are fully covered.

[0059] In some embodiments, modeling the dynamic expiration tolerance according to the number of requests per second qps of the key API, the response time Tresp of the key API, and the utilization rate U of the database connection pool specifically includes:

[0060] Define a system busy rate:

[0061]

[0062] Among them, i represents the index of the current user, α, β, γ represent coefficients, and Tresp aver represents the average response time;

[0063] Assuming that the maximum expiration tolerance is T_max and the minimum expiration tolerance is T_min, the dynamic expiration tolerance tolerance_t_window(i,U,qps) is:

[0064]

[0065] Among them, tolerance_t_window(i,U,qps) dynamically takes values ​​in [T_min,T_max].

[0066] Through the above settings, when qps, Tresp and U are smaller, the system performance is better and can accommodate more requests. The value in the log is close to 0, and tolerance_t_window(i,U,qps) is close to T_min, that is, the dynamic expiration tolerance will be smaller, which is in line with the physical meaning of resource utilization. When qps, Tresp and U are larger, the system performance is poor, it can accommodate fewer requests, the response and processing rate are reduced, the value in the log is close to 1, and the entire expression is close to T_max, that is, the larger the dynamic expiration tolerance, the more time the system has for authorization fault tolerance, which is in line with the physical meaning of resource utilization.

[0067] Through the above settings, for each request, the specific value of the expiration tolerance can be dynamically set according to the system performance at the corresponding moment, optimizing the pain points and problems of the patent CN112003852B, such as the fixed expiration tolerance time parameter, inflexible static configuration, and lack of linkage with the current server's resource utilization and refined load.

[0068] In some embodiments, the token refresh mechanism specifically includes: obtaining a new access token and a new refresh token; setting the current access token to the last expired access token; setting the new access token to the current access token. In other words, two pieces of information will be kept for the access token, one is the current access token information, and the other is the last expired access token information; each time the token refresh mechanism is executed, a new access token will be generated as the current access token, and the original access token will be used as the last expired access token. This setting is to distinguish different subsequent expiration scenarios.

[0069] In some embodiments, refresh rules are set for requests, and corresponding refresh rules are selected for execution based on the distributed lock state, the requested access token state, and whether the expiration time is within the dynamic expiration tolerance. By combining the three pieces of information, namely, the distributed lock state, the requested access token state, and whether the expiration time is within the dynamic expiration tolerance, different expiration scenarios and different rules can be uniquely determined.

[0070] In some embodiments, when the state of the distributed lock is that the distributed lock can be obtained, the state of the requested access token is the current access token, and the expiration time is within the dynamic expiration tolerance, the first refresh rule is selected for execution; the first refresh rule includes: setting a distributed lock for the request, triggering a token refresh mechanism at the same time, and releasing the distributed lock after the token refresh mechanism is executed. The scenario corresponding to the first refresh rule is the scenario of the first request with an expired request. That is, it corresponds to the scenario of the first request in step 200 where the access token expires and the refresh token has not expired.

[0071] In addition, for the first refresh rule, if the expiration time of the first request initiated is not within the dynamic expiration tolerance, the corresponding physical meaning or typical scenario is: a page that requires authorization has not been updated for a long time (for example, 2 days), and a series of network requests are initiated by clicking on the page, but the token has expired and has been expired for too long. The system does not allow any request with an expired token to pass. The page will then redirect to the login interface, prompting the user to re-enter the user name, password, verification code and other information, and re-authorize the login. No request with an expired token will be allowed to pass to ensure the authorization security of the system.

[0072] In some embodiments, when the state of the distributed lock is occupied, the state of the requested access token is the current access token, and the expiration time is within the dynamic expiration tolerance, the second refresh rule is selected for execution; the second refresh rule includes: the token refresh mechanism is not triggered for the request, and normal access is directly allowed. The scenario corresponding to the second rule is the scenario where the subsequent 2nd to nth requests carry an expiration date, and the time when the request arrives at the server is within the duration of the distributed lock being occupied. Some of the subsequent requests of the first request in step 300 correspond to this scenario.

[0073] In some embodiments, when the state of the distributed lock is that the distributed lock can be acquired, the state of the requested access token is the access token that expired last time, and the expiration time is within the dynamic expiration tolerance, the third refresh rule is selected for execution; the third refresh rule includes: the token refresh mechanism is not triggered for the request, and normal access is directly allowed. The scenario corresponding to the third rule is the scenario in which the second to nth subsequent requests carry an expiration date, and the request arrives at the server after the distributed lock is released. Some of the subsequent requests of the first request in step 300 correspond to this scenario.

[0074] In addition, for the second and third refresh rules, if the expiration time of 2 to n initiated requests is not within the dynamic expiration tolerance, the probability is relatively low. If it happens, the corresponding physical meaning or typical scenario is: the page just expires, but the 2nd to nth request initiated may not arrive in time due to network delay or network failure. When the request arrives, it is found that the expiration tolerance has also been reached; at this time, there are two optional processing methods. Method 1: Redirect the request whose token has expired and the tolerance has also expired to the login interface, let the user re-enter the user name, password, verification code, re-authorize login, and do not allow any request with expired token to pass, so as to ensure the security of the system. Method 2: Do not allow the request whose token has expired and the tolerance has also expired, but do not redirect to the login page; because the first request is successful, although the 2nd to nth request fails, the page data is missing or incomplete. When the user initiates the request next time, the client has cached the valid token updated for the first time. The client carries the cached valid token that has just been updated locally, and refreshes again to access the target resource.

[0075] In some embodiments, when the requested access token status is the current access token and has not expired, the fourth refresh rule is selected for execution; the fourth refresh rule includes: directly allowing normal access without other judgments. The scenario corresponding to the fourth rule is that after the token refresh mechanism is executed and the distributed lock is released, the client has obtained a new access token and sends a request with the new access token. At this time, the token carried by the request is the new access token, that is, the current access token mentioned above, and the current access token has just been obtained and has not expired, so normal access can be performed directly.

[0076] In summary, the embodiment of the present invention provides a dual-token authorization refresh method based on dynamic expiration tolerance. In terms of technical innovation, it protects critical resources, builds dynamic expiration tolerance, combines multi-dimensional performance indicators of the back-end server, integrates multi-dimensionally collected server performance indicators such as the number of requests per second qps of the key API, the response time Tresp of the key API, and the utilization rate U of the database connection pool, and innovatively models the dynamic expiration tolerance, thereby optimizing the pain points and problems of the patent CN112003852B, such as the fixed expiration tolerance time parameters, the inflexible static configuration, and the lack of linkage with the current server's resource utilization and refined load.

[0077] Furthermore, in terms of business innovation, by introducing distributed locks, all scenarios and categories of problems related to expired abnormal requests are fully covered.

[0078] Based on the above method, this embodiment also provides a dual token authorization refresh system based on dynamic expiration tolerance, referring to Figure 2 As shown, the system includes a dynamic expiration tolerance modeling module, a first request processing module and a subsequent request processing module, wherein: the dynamic expiration tolerance modeling module is used to: model the dynamic expiration tolerance according to the number of requests per second qps of the key API, the response time Tresp of the key API and the utilization rate U of the database connection pool; when qps, Tresp and U are smaller, the dynamic expiration tolerance is smaller; when qps, Tresp and U are larger, the dynamic expiration tolerance is larger; the first request processing module is used to: for the first request when the access token expires and the refresh token is not expired, if the expiration time of the access token of the corresponding request is within the corresponding dynamic expiration tolerance, a distributed lock is set for the request, and a token refresh mechanism is triggered at the same time. After the token refresh mechanism is executed, the distributed lock is released; the subsequent request processing module is used to: for the subsequent request of the first request, if the expiration time of the access token of the corresponding request is within the corresponding dynamic expiration tolerance, the token refresh mechanism is not triggered, and normal access is directly allowed. The specific implementation process of each module can refer to the above method steps, which will not be repeated here.

[0079] Embodiment 2:

[0080] Based on the dual-token authorization refresh method based on dynamic expiration tolerance provided in the above-mentioned embodiment 1, embodiment 2 of the present invention provides a specific example for illustration.

[0081] Examples of the above scheme are as follows:

[0082] First, the user initiates a web or mobile login request on the page, enters the username and password, and completes the login. The above operation will cause the server to query the user information and determine whether the user data is a valid user ID and password; we name the user ID user_id; if the user_id and password do not meet the verification rules, an error message will be prompted and the subsequent process will be terminated. If the user_id and password meet the verification rules, the server will perform the following operations:

[0083] The token generation module is called to generate a token information; while the above token information is generated, a copy of the above token information will be stored in the token database management module; while the above token information is generated, a copy of the above token information will be cached in the token cache module.

[0084] The above cache frameworks are common knowledge and have mature open source implementations. The corresponding open source frameworks are named ehcache, memcache, redis, etc. The implementation principles of the corresponding open source frameworks are not described here. We use redis as the main method of server-side caching in this embodiment. Other more advanced and efficient server-side caching strategies and algorithms are not within the scope of this embodiment.

[0085] In this embodiment, a feasible engineering strategy for server-side caching is to use redis. The token cache module caches user information and token information in redis, where the key read by redis is user_id; the cached information acesstoken_info_cache can be read later through the key of redis (here the user id is user_id); the cached information acesstoken_info_cache includes but is not limited to: curr_token(i), the token of the current user i, that is, the current access token in embodiment 1; prev_token(i), the previous token of the current user i, that is, the last invalid access token in embodiment 1; refresh_lock(i), the current user i concurrently refreshes the distributed lock.

[0086] Afterwards, the server returns data carrying curr_token and user information to the client; the above return information includes: curr_token, user personal business information (such as user name, user gender, user province and other additional information).

[0087] Then, the web client caches the curr_token information in the above steps in the page, carries the above token information when requesting resources, opens a page, and triggers the client to request protected resources. Carrying token information, in engineering implementation, generally carries the header information named Authorization in the http header;

[0088] A method of sending a URL request is represented by curl and can be described as follows:

[0089]

[0090]

[0091] The above -H "Authorization: Bearer xxxx" means that the xxxx string is curr_token as an additional header of the request;

[0092] http: / / myhost:port / protect_resource_path1 indicates the URL corresponding to the resource of the above protected request;

[0093] We name url1 = http: / / myhost:port / protect_resource_path1;

[0094] We record the above request as request(curr_token, url1);

[0095] The above protected request resource URL is generally a web service protected by oauth2, such as http: / / myhost:port / protect_resource_path;

[0096] If the curr_token is not included as an additional header in the request, authentication will fail and the request will return an error message such as "Unauthorized".

[0097] During the entire stage of obtaining resources on the above page, if the requested curr_token has not expired, the above steps can successfully obtain the corresponding page static resources and service interface information and complete the opening of the page.

[0098] If the curr_token retained in the client cache has expired when the above page obtains resources. There are many cases where the curr_token expires, which are analyzed and processed below. It is worth mentioning that when the above steps open the page, there will generally be a large number of concurrent requests in a short period of time instead of one request; this embodiment makes the following agreements:

[0099] There are N requests to open a certain page, named as:

[0100] request(curr_token,url(1),t(1));

[0101] request(curr_token,url(2),t(2));

[0102] request(curr_token,url(3),t(3));

[0103] …

[0104] request(curr_token, urlN, t(N));

[0105] At the same time, it is assumed that t(1)<=t(2)<=t(3)…<=t(N);

[0106] Similarly, t(i) represents the time when the i-th request is initiated;

[0107] Similarly, url(i) represents the URL of the i-th request;

[0108] Obviously request(curr_token, url(1), t(1)) is the first request for the local page open event.

[0109] If curr_token has expired and refreshtoken has expired when request(curr_token, url(1), t(1)) is initiated, the user interface will directly return to the login page and log in again.

[0110] If curr_token has expired and refreshtoken has not expired when request(curr_token, url(1), t(1)) is initiated, the DTARADETTDL algorithm in the resource authorization core algorithm module is executed. The following is a detailed description of the Dual-Token Authorization Refresh Algorithm with Dynamic Expiration Tolerance Based on Distributed Locks (abbreviated as: DTARADETTDL).

[0111] When curr_token expires, clicking on the page will trigger 1-n concurrent transactions with expired tokens in a short period of time. This embodiment performs modeling optimization and algorithm design for the above scenario.

[0112] The first business transaction that arrives the fastest and carries an expired token can use Redis distributed locks to ensure the atomicity of the token refresh operation and prevent conflicts. The first invalidation request is determined by rule 1, and the first invalidation request will trigger a token refresh.

[0113] In this embodiment, after the first invalidation request of user i is determined by rule 1, a distributed lock is created using Redission to ensure that token refresh, curr_token(i), and prev_token(i) cache data updates are atomic operations. The distributed lock is released after the token refresh, curr_token(i), and prev_token(i) cache data updates are completed.

[0114] Therefore, for the current concurrent request, the distributed lock duration of user i is Figure 3The [T1, T2] interval in the above-mentioned distributed lock resource is defined as RedissionLock(i); Obviously, through rule 1 in the rule determination table (comprehensive judgment of lock status, token status, and expiration time), the system can distinguish the first request initiated by the current user (which will trigger a token refresh transaction) and the remaining n-1 requests (no need to refresh the token). The subsequent 2-n requests (refresh_st=1) do not perform synchronous blocking, but compare the cached double token information, and obtain the request time based on the modeling result of the dynamic expiration tolerance tolerance_t_window(i) of the token of user i, that is, the dynamic grace time of the expiration tolerance. Requests that carry expired tokens but meet tolerance_t_window (for example, a dynamically calculated result is 30 seconds) are released (analogous to the fact that candidates with ID cards are allowed to enter the venue if they are 30 seconds late). The algorithm can accurately distinguish between the first and second to n types of requests and process them differently; and allow the subsequent 2 to n requests with expired tokens within the tolerance_time_window (for example, 30 seconds, within the expiration tolerance period) to use prev_token or curr_token for verification, thereby avoiding the repeated triggering of the refreshtoken refresh process due to the failure of 2-n business requests.

[0115] The definition of the first request and the subsequent 2-n requests can be divided into multiple scenarios, see Figure 3 And the following rule determination table. Each rule can be uniquely determined by the combination of lock status + token status + expiration time equation. The rule determination table is as follows:

[0116]

[0117] The above rule 1 corresponds to the first refresh rule in Example 1, rule 2 corresponds to the second refresh rule in Example 1, rule 3 corresponds to the third refresh rule in Example 1, and rule 4 corresponds to the fourth refresh rule in Example 1.

[0118] The DTARADETDL algorithm uses dual tokens as a processing strategy in the concurrent competition stage of token refresh requests. It sets a certain expiration tolerance (that is, allowing expired requests of the same userid to be released within a short period of time after token expiration, such as the remaining 2 to n requests in this example), and the tolerance_t_window (i, U, qps) is generally short, which also ensures the security of the tolerance when the requirements are relaxed, thereby achieving the purpose of solving the problem of repeated refresh of refreshtoken during the concurrent competition state of refresh token.

[0119] In this embodiment, there are a total of N requests to open the page, and these N requests can be divided into three categories of requests; specifically: the first request request (accesstoken, url (1), t (1)) initiated for the first time is recorded as a Class A request; the second request request (accesstoken, url (2), t (2)) to the j-th request request (accesstoken, url (j), t (j)) totaling j-1 requests are recorded as Class B requests; the remaining j+1 to N-th requests, a total of N-(j+1)+1=Nj requests, are recorded as Class C requests.

[0120] For class A requests: class A requests trigger event eventA, which matches a legal curr_token(i) but is invalid; the first invalidation request is determined by rule 1, and the first invalidation request will trigger a token refresh; after the first invalidation request of user i is determined by rule 1, a distributed lock is created using Redission to ensure that token refresh, curr_token(i), and prev_token(i) cache data updates are atomic operations, and the distributed lock is released after token refresh, curr_token(i), and prev_token(i) cache data updates are completed. Therefore, for the current concurrent requests, the distributed lock duration of user i is Figure 3 In the interval [T1, T2], the above distributed lock resource is defined as RedissionLock(i); Obviously, through rule 1 in the rule determination table (comprehensive judgment of lock status, token status, and expiration time), the system can distinguish the first request initiated by the current user (which will trigger a token refresh transaction) and the remaining n-1 requests (no token refresh is required).

[0121] For type B requests: event eventB is triggered. At this time, a valid curr_token may be matched, or a valid prev_token may not be matched, and the requirements of rules 2 and 3 are met. Although the curr_token or prev_token is invalid, the request can still be made normally. At this time, there is no need to re-update the accesstoken and refreshtoken; the request is allowed to access the protected resources normally.

[0122] For type C requests: event eventC is triggered, and the request satisfies rule 4. At this time, the token has not expired and is in a normal state, allowing the request to access the protected resources normally.

[0123] At this point, the DTARADETL algorithm has solved the problem of repeatedly obtaining refreshtokens in a concurrent competition state after the token expires; the above-mentioned Class A requests, Class B requests, and Class C requests can all be executed efficiently, correctly, and without error.

[0124] There are many ways to model the dynamic expiration tolerance tolerance_t_window in the above-mentioned DTARADETTDL algorithm. This embodiment innovatively adopts a dynamic grace time to model tolerance_t_window.

[0125] Specifically, we can define a system busy rate by integrating the qps (requests per second) of the key API, the response time Tresp of the key API, and the utilization rate U of the database connection pool:

[0126]

[0127] The symbolic meaning, physical meaning, and modeling logic in the server system busy rate formula are as follows:

[0128] It can model the relationship between the utilization of the database connection pool and the system busyness, and smoothly map the linear growth of U to a nonlinear growth space, which reflects the characteristics that the system grows faster when the connection pool utilization is low, and slows down when the utilization is close to saturation.

[0129] It is possible to use a sigmoid activation function to perform a nonlinear mapping of the input to (0,1) normalization.

[0130] therefore The relationship between the utilization of the database connection pool and the system busyness can be modeled. As U increases, It also increases, and its value range is (0,1).

[0131] Increase, Also increases;

[0132] analyze The first-order derivative of can be obtained is an increasing function;

[0133] Therefore, with Increase, It also increases and the variation range is (0,1);

[0134] The relationship between the API's qps (requests per second), the key API's response time Tresp, and the system's busyness can be modeled.

[0135] Assuming that the contribution of the above factors to busyness is 0.5, weight them;

[0136] The final system busy rate expression can be obtained as:

[0137]

[0138] The busier the system is, the slower the number of requests it responds to per unit time, and the longer the dynamic grace expiration time is required; we assume that the maximum tolerance that can be tolerated is T_max (for example, 100s) and the minimum tolerance is T_min (for example, 10s);

[0139] We map it to the following formula:

[0140]

[0141] Obviously, when U, qps and Tresp are small, the system performance is better and can accommodate more requests. The value in the log approaches 0, and tolerance_t_window(i,U,qps) approaches T_min, which is consistent with the physical meaning of resource utilization. When U, qps and Tresp are large, the system performance is poor and can accommodate fewer requests. The response and processing rates are reduced, the value in the log approaches 1, and the entire expression approaches T_max, giving the system more time for authorization fault tolerance, which is consistent with the physical meaning of resource utilization. So far, the entire tolerance_t_window(i,U,qps) dynamically takes values ​​in [T_min,T_max].

[0142] It should also be noted that in the above formula, the variable i represents the index identifier of the current user, because the requests received by the backend come from different users i. α represents the characteristic of whether the growth is accelerated when the utilization rate U of the database connection pool is close to saturation; in this embodiment, α=1.5 is taken; the specific value of α can be adjusted according to the actual effect of the project or the historical data of the system. When β in this embodiment selects a reasonable value, such as 6, its nonlinear adjustment effect is more obvious, and only the value near the database connection pool is a specific area (such as 0.5) fluctuates a lot, while the change rate of U is not obvious when it is very small (machine idle) and close to 1 (machine busy). In this embodiment, β=6 is taken; the specific value of β can be adjusted according to the actual effect of the project or the historical data of the system. γ can control the amplitude and range of changes when the response time Tresp changes; smaller γ shows a significant change rate for a wider range of Tresp; larger γ, when Tresp is large and changes, is already saturated near slightly less than 1 and grows slowly; in this embodiment, γ=1, and the specific value of γ can be adjusted according to the actual effect of the project or the historical data of the system. Tresp averThe parameter indicates that statistics are taken for key transactions to obtain an average request response time; for example, for the core authorization transaction API interface, big data statistics are taken to analyze its response time, data cleaning and analysis are performed, and finally abnormal values ​​are eliminated to obtain Tresp aver is 0.5 seconds; the real Tresp aver The parameters need to be obtained through statistical analysis based on the system's historical data.

[0143] In general, the embodiment of the present invention provides a dual-token authorization refresh method based on dynamic expiration tolerance. In terms of technical innovation, it protects critical resources, builds dynamic expiration tolerance, combines multi-dimensional performance indicators of the back-end server, integrates multi-dimensionally collected server performance indicators such as the number of requests per second qps of the key API, the response time Tresp of the key API, and the utilization rate U of the database connection pool, and innovatively models the dynamic expiration tolerance, thereby optimizing the pain points and problems of the patent CN112003852B, such as the fixed expiration tolerance time parameters, the inflexible static configuration, and the lack of linkage with the current server's resource utilization and refined load.

[0144] Furthermore, in terms of business innovation, by introducing distributed locks, all scenarios and categories of problems related to expired abnormal requests are fully covered.

[0145] Embodiment 3:

[0146] Based on the dual token authorization refresh method based on dynamic expiration tolerance provided in the above embodiment 1, the present invention also provides a dual token authorization refresh device based on dynamic expiration tolerance that can be used to implement the above method and system, such as Figure 4 , which is a schematic diagram of the device architecture of an embodiment of the present invention. The dual token authorization refresh device based on dynamic expiration tolerance of this embodiment includes one or more processors 21 and a memory 22. Figure 4 A processor 21 is taken as an example.

[0147] The processor 21 and the memory 22 may be connected via a bus or other means. Figure 4 The example of connecting through bus is taken in the following.

[0148] The memory 22, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer executable programs and modules, such as the dual-token authorization refresh method based on dynamic expiration tolerance in Example 1. The processor 21 executes various functional applications and data processing of the dual-token authorization refresh device based on dynamic expiration tolerance by running the non-volatile software programs, instructions and modules stored in the memory 22, that is, the dual-token authorization refresh method based on dynamic expiration tolerance in Example 1 is implemented.

[0149] The memory 22 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other non-volatile solid-state storage device. In some embodiments, the memory 22 may optionally include a memory remotely arranged relative to the processor 21, and these remote memories may be connected to the processor 21 via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0150] The program instructions / modules are stored in the memory 22. When executed by one or more processors 21, the dual token authorization refresh method based on dynamic expiration tolerance in the above embodiment 1 is executed. For example, the above described dual token authorization refresh method is executed. Figure 1 The steps shown.

[0151] The above-mentioned product can execute the method provided in the embodiment of the present application, and has the functional modules and beneficial effects corresponding to the execution method. For technical details not fully described in this embodiment, please refer to the method provided in the embodiment of the present application.

[0152] It should be noted that the device embodiments described above are merely illustrative, wherein the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or may be distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0153] Through the description of the above implementation methods, ordinary technicians in this field can clearly understand that each implementation method can be implemented by means of software plus a general hardware platform, and of course, it can also be implemented by hardware. Ordinary technicians in this field can understand that all or part of the processes in the above-mentioned embodiment method can be completed by instructing related hardware through a computer program, and the program can be stored in a computer-readable storage medium. When the program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, the storage medium can be a disk, an optical disk, a read-only memory (ROM) or a random access memory (RAM), etc.

[0154] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit them. Under the concept of the present invention, the technical features in the above embodiments or different embodiments may also be combined, the steps may be implemented in any order, and there are many other changes in different aspects of the present invention as described above, which are not provided in detail for the sake of simplicity. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that the technical solutions described in the aforementioned embodiments may still be modified, or some of the technical features may be replaced by equivalents. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A dual-token authorization refresh method based on dynamic expiration tolerance, characterized in that: include: The dynamic expiration tolerance is modeled based on the number of requests per second (qps) of the key API, the response time (Tresp) of the key API, and the utilization rate (U) of the database connection pool. When qps, Tresp, and U are smaller, the dynamic expiration tolerance is smaller; when qps, Tresp, and U are larger, the dynamic expiration tolerance is larger. For the first request whose access token has expired and whose refresh token has not expired, if the expiration time of the access token of the corresponding request is within the corresponding dynamic expiration tolerance, a distributed lock is set for the request and the token refresh mechanism is triggered. After the token refresh mechanism is executed, the distributed lock is released. For subsequent requests of the first request, if the expiration time of the access token of the corresponding request is within the corresponding dynamic expiration tolerance, the token refresh mechanism will not be triggered and normal access will be allowed directly.

2. The dual token authorization refresh method based on dynamic expiration tolerance according to claim 1 is characterized in that: The modeling of dynamic expiration tolerance according to the number of requests per second qps of the key API, the response time Tresp of the key API, and the utilization rate U of the database connection pool specifically includes: Define a system busy rate: Among them, i represents the index of the current user, α, β, γ are coefficients, and Tresp aver represents the average response time; Assuming that the maximum expiration tolerance is T_max and the minimum expiration tolerance is T_min, the dynamic expiration tolerance tolerance_t_window(i,U,qps) is: Among them, tolerance_t_window(i,U,qps) dynamically takes values ​​in [T_min,T_max].

3. The dual token authorization refresh method based on dynamic expiration tolerance according to claim 1 is characterized in that: The token refresh mechanism specifically includes: Get a new access token and a new refresh token; Set the current access token to the last invalidated access token; Set the new access token as the current access token.

4. The dual token authorization refresh method based on dynamic expiration tolerance according to claim 3 is characterized in that: Set refresh rules for the request, and select the corresponding refresh rule for execution based on the distributed lock status, the requested access token status, and whether the expiration time is within the dynamic expiration tolerance; When the distributed lock status is that the distributed lock can be obtained, the requested access token status is the current access token, and the expiration time is within the dynamic expiration tolerance, the first refresh rule is selected for execution; The first refresh rule includes: setting a distributed lock for the request and triggering a token refresh mechanism at the same time, and releasing the distributed lock after the token refresh mechanism is executed.

5. The dual token authorization refresh method based on dynamic expiration tolerance according to claim 4 is characterized in that: When the distributed lock status is occupied, the requested access token status is the current access token, and the expiration time is within the dynamic expiration tolerance, the second refresh rule is selected for execution; The second refresh rule includes: not triggering a token refresh mechanism for the request and directly allowing normal access.

6. The dual token authorization refresh method based on dynamic expiration tolerance according to claim 4 is characterized in that: When the distributed lock status is that the distributed lock can be obtained, the requested access token status is the last invalid access token, and the expiration time is within the dynamic expiration tolerance, the third refresh rule is selected for execution; The third refresh rule includes: not triggering a token refresh mechanism for the request, and directly allowing normal access.

7. The dual token authorization refresh method based on dynamic expiration tolerance according to claim 4 is characterized in that: When the requested access token status is the current access token and has not expired, the fourth refresh rule is selected for execution; The fourth refresh rule includes: directly allowing normal access without other judgments.

8. A dual-token authorization refresh device based on dynamic expiration tolerance, characterized in that: The device includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the processor to execute the dual token authorization refresh method based on dynamic expiration tolerance as described in any one of claims 1-7.

9. A dual-token authorization refresh system based on dynamic expiration tolerance, applying the dual-token authorization refresh method based on dynamic expiration tolerance as described in any one of claims 1 to 7, characterized in that: The system includes a dynamic expiration tolerance modeling module, a first request processing module and a subsequent request processing module, wherein: The dynamic expiration tolerance modeling module is used to: model the dynamic expiration tolerance according to the number of requests per second qps of the key API, the response time Tresp of the key API, and the utilization rate U of the database connection pool; when qps, Tresp and U are smaller, the dynamic expiration tolerance is smaller; when qps, Tresp and U are larger, the dynamic expiration tolerance is larger; The first request processing module is used to: for the first request whose access token has expired and whose refresh token has not expired, if the expiration time of the access token of the corresponding request is within the corresponding dynamic expiration tolerance, set a distributed lock for the request and trigger a token refresh mechanism at the same time, and release the distributed lock after the token refresh mechanism is executed; The subsequent request processing module is used for: for subsequent requests of the first request, if the expiration time of the access token of the corresponding request is within the corresponding dynamic expiration tolerance, the token refresh mechanism is not triggered and normal access is directly allowed.

10. A non-volatile computer storage medium, characterized in that: The computer storage medium stores computer executable instructions, which are executed by one or more processors to complete the dual-token authorization refresh method based on dynamic expiration tolerance as described in any one of claims 1-7.

Images