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

Abstract

The application relates to a dynamic expiration tolerance-based double-token authorization refreshing method, device and system. The method comprises the following steps: modeling a 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 in which an access token is expired and a refresh token is not expired, if the expiration time length of the corresponding access token is within the corresponding dynamic expiration tolerance, a distributed lock is set for the request, and a token refreshing mechanism is triggered; after the token refreshing mechanism is executed, the distributed lock is released; for subsequent requests of the first request, if the expiration time length of the corresponding access token is within the corresponding dynamic expiration tolerance, the token refreshing mechanism is not triggered, and normal access is directly allowed. The application models the dynamic expiration tolerance, optimizes the pain points and problems of the fixed, static and inflexible configuration of an expiration tolerance time parameter in the prior art.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of network permission control, and particularly relates to a double-token authorization refreshing method, device and system based on dynamic expiration tolerance. BACKGROUND

[0002] Patent CN110266703A solves the problem that when a large number of network requests need to obtain new tokens, the current cannot effectively process the concurrent refreshing of expired tokens. The solution is to add a synchronization lock to the client refresh operation to make the refresh operation successfully send the network request of the refreshed token, and continuously and orderly complete the refresh operation of the network request token. The above-mentioned solution is similar to using Promise (Promise is a key technology for solving asynchronous programming problems) in the end Web, using LinkedBlockingQueue (LinkedBlockingQueue is a blocking queue based on a linked list) in Android Java, and using NSOperationQueue (NSOperationQueue is a multi-threading solution provided by iOS) in iOS. The business pain points and inefficiencies are as follows: multiple sets of similar codes need to be maintained for Web, applet, Android and iOS channels, which leads to the need to maintain different technology stack codes for multiple platforms, huge workload and high requirement for understanding of business details; further, the locking and synchronization processing needs to be re-coded for the same logic on different heterogeneous and differentiated platforms with the increase of the number of terminals and access platforms, which results in large amount of code, and when defects are encountered, all platforms need to be re-modified; when the code needs to be updated, restructured and optimized, the code time and business logic synchronization need to be fine-tuned for multiple platforms, multiple languages, multiple operating systems and multiple architectures, which leads to poor maintainability, low modifiability and insufficient scalability. Secondly, another defect of patent CN110266703A is that the concurrency, sequential execution and processing similar to the synchronization lock will reduce the system efficiency, system concurrency and system throughput.

[0003] In view of the defects of the above patent CN110266703A, the patent CN112003852B gives up processing on the client side and turns to the server backend for effective processing. The patent CN112003852B performs multi-level, three-dimensional and differentiated intelligent discrimination on the current request on the server side according to multi-dimensional judgment conditions, avoids the disorder and repeated refresh problems caused by concurrent refresh requests in the "expiration tolerance" time period, and at the same time, the unified framework processing of the server side avoids the large amount of redundant and heavy work of repeated coding on different clients to adapt to token refresh. The patent CN112003852B further avoids the performance and efficiency loss problems caused by the traditional synchronization mechanism, lock mechanism or ordered queue.

[0004] However, the patent CN112003852B selects a static configuration value for the expiration tolerance time when considering the expiration tolerance, and does not link the current server resource utilization and refined load. In addition, the patent CN112003852B does not fully cover the expiration request scenario problem when considering the concurrent request of the expired token, and the classification of abnormal token requests is incomplete.

[0005] Therefore, how to overcome the defects of the prior art, how to link the expiration tolerance with the current server resource utilization and refined load, and how to cover more expiration request scenarios have become important technical problems to be solved in the industry. SUMMARY

[0006] In view of the defects or improvement needs in the prior art: how to link the expiration tolerance with the current server resource utilization and refined load, and how to cover more expiration request scenarios. The present application provides a double-token authorization refresh method, device and system based on dynamic expiration tolerance. In terms of technical innovation, the critical resources are protected, the dynamic expiration tolerance time is constructed, the performance indicators of the backend server are combined, the Queries Per Second (QPS) of the key Application Programming Interface (API), the response time (Tresp) of the key API and the utilization rate (U) of the database connection pool are integrated, and the server performance indicators collected in multiple dimensions are modeled. The dynamic expiration tolerance time is innovatively modeled to optimize the fixed, static configuration of the expiration tolerance time parameter in the patent CN112003852B, which is not flexible and does not link the current server resource utilization and refined load. Further, through the introduction of a distributed lock, all scenarios and categories of expired abnormal requests are comprehensively covered.

[0007] The application adopts the technical solutions below.

[0008] In a first aspect, the application provides a double-token authorization refreshing method based on dynamic expiration tolerance, comprising:

[0009] 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; the smaller qps, Tresp and U are, the smaller the dynamic expiration tolerance is; the larger qps, Tresp and U are, the larger the dynamic expiration tolerance is.

[0010] For the first request in 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, a distributed lock is set for the request, and a token refreshing mechanism is triggered; after the token refreshing mechanism is executed, the distributed lock is released.

[0011] For the subsequent requests 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.

[0012] In some embodiments, the modeling of 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 specifically comprises:

[0013] A system busy rate is defined as:

[0014] ;

[0015] Wherein, i represents the index identification of the current user, and a, b and g represent coefficients, Tresp aver represents the average response time.

[0016] Suppose that the maximum expiration tolerance is T_max and the minimum expiration tolerance is T_min, then the dynamic expiration tolerance is:

[0017] ;

[0018] Wherein, The dynamic expiration tolerance is dynamically taken in [T_min, T_max].

[0019] In some embodiments, the token refreshing mechanism specifically comprises:

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

[0021] set the current access token as the last invalid 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 a corresponding refresh rule is selected for execution according to the distributed lock state, the access token state of the request, and whether the expiration duration is within the dynamic expiration tolerance;

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

[0025] In some embodiments, when the distributed lock state is that the distributed lock is occupied, the access token state of the request is the current access token, and the expiration duration is within the dynamic expiration tolerance, a 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 distributed lock state is that the distributed lock can be acquired, the access token state of the request is the last invalid access token, and the expiration duration is within the dynamic expiration tolerance, a 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 access token state of the request is the current access token and is not expired, a fourth refresh rule is selected for execution; the fourth refresh rule includes: without other judgments, directly allowing normal access.

[0028] In a second aspect, the application 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 with 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 of the first aspect.

[0030] In a third aspect, the application further provides a dual-token authorization refresh system based on dynamic expiration tolerance, which applies the dual-token authorization refresh method based on dynamic expiration tolerance of the first aspect, and the system comprises 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 configured 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; the smaller the qps, Tresp, and U, the smaller the dynamic expiration tolerance; the larger the qps, Tresp, and U, the larger the dynamic expiration tolerance;

[0032] The first request processing module is configured to, for the first request in which the access token is expired and the refresh token is not expired, if the expiration time length of the access token corresponding to the request is within the corresponding dynamic expiration tolerance, set a distributed lock for the request, and trigger a token refreshing mechanism, and after the token refreshing mechanism is executed, release the distributed lock.

[0033] The subsequent request processing module is configured to, for the subsequent request of the first request, if the expiration time length of the access token corresponding to the request is within the corresponding dynamic expiration tolerance, not trigger the token refreshing mechanism, and directly allow normal access.

[0034] In a fourth aspect, the application further provides a non-volatile computer storage medium, which stores computer executable instructions, and the computer executable instructions are executed by one or more processors to complete the double-token authorization refreshing method based on dynamic expiration tolerance.

[0035] Compared with the prior art, the application provides a double-token authorization refreshing method, device and system based on dynamic expiration tolerance, which has the beneficial effects that: in terms of technical innovation, the critical resources are protected, the dynamic expiration tolerance is constructed, the 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, the dynamic expiration tolerance is modeled innovatively, and the pain points and problems in the fixed, static configuration of the expiration tolerance time parameter in the patent CN112003852B are solved, such as the inflexibility and the lack of linkage with the current server resource utilization and refined load.

[0036] Further, in terms of business innovation, all scenarios and category problems of expired abnormal requests are comprehensively covered by introducing a distributed lock. BRIEF DESCRIPTION OF DRAWINGS

[0037] In order to more clearly illustrate the technical solutions of the embodiments of the application, the following will briefly introduce the drawings needed to be used in the embodiments of the application. Obviously, the drawings described below are only some embodiments of the application, and for those skilled in the art, other drawings can also be obtained from these drawings without creative labor.

[0038] Figure 1 A flow chart of a double token authorization refresh method based on dynamic expiration tolerance provided for embodiment 1 of the present application;

[0039] Figure 2 A module schematic diagram of a double token authorization refresh system based on dynamic expiration tolerance provided for embodiment 1 of the present application;

[0040] Figure 3 A request case timing schematic diagram provided for embodiment 2 of the present application;

[0041] Figure 4 A double token authorization refresh device structure schematic diagram based on dynamic expiration tolerance provided for embodiment 3 of the present application. DETAILED DESCRIPTION

[0042] The present application will be described in detail below with specific embodiments. The following embodiments will help those skilled in the art to further understand the present application, but do not limit the present application in any form. It should be noted that for those skilled in the art, without departing from the concept of the present application, a number of modifications and improvements can be made. These are within the scope of the present application. It should be noted that if there is no conflict, each feature in the embodiments of the present application can be combined with each other, and all within the scope of protection of the present application. In addition, although the functional modules may be divided in the device schematic diagram, and the steps shown or described in the sequence may be executed in the flowchart, in some cases, they may be different from the module division in the device or the order shown or described in the flowchart.

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

[0044] Unless the context clearly requires otherwise, throughout the description and the claims, the term "comprise" is to be construed as an open-ended term meaning "including, but not limited to," and the term "comprises" is to be construed as an open-ended term meaning "including, but not limited to." As used in the description and the claims, the terminology or description associated with an embodiment, some embodiments, an example embodiment or an example encompasses that the particular feature, structure, material or characteristic described can be included in at least one embodiment or example of the disclosure. The appearances of the above terminology or description associated with an embodiment, some embodiments, an example embodiment or an example in various places in the specification do not necessarily refer to the same embodiment or example. Furthermore, the particular features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples, as suitable for the intended purpose.

[0045] Before the specific embodiment description is carried out, the explanation of the terms in the embodiments of the disclosure is described:

[0046] oauth2.0: oauth (Open Authorization) is an open standard that allows a user to authorize a third-party mobile application to access specific private resources of the user in a certain server without providing the user name and password to the third-party mobile application or sharing all the contents of their data, oauth2.0 is a continuation version of the oauth protocol, but is not backward compatible with oauth 1.0.

[0047] accesstoken (access token): token is also called token; in oauth2.0, accesstoken is a string generated by the server, which is a token for the client to make a request, when logging in for the first time, the server generates an accesstoken, and returns the accesstoken to the client, so that the client only needs to bring this accesstoken to request data, without the need to bring the username and password again. In the background of the client frequently requesting data from the server, the server frequently querying the database for the username and password and comparing the username and password to determine whether the username and password are correct, and making corresponding prompts, the accesstoken is born. The purpose of accesstoken is to reduce the pressure on the server, reduce the frequent database queries, and make the server more robust.

[0048] Refresh token: Token is the access to protected resources, of course, must have an expiration time. Otherwise, a login can be used permanently, authentication function has lost its meaning. Token must not only have an expiration time, but also the expiration time can not be too long; In addition to access token there is another token called refresh token, usually, the validity period of refreshtoken will be longer, and the validity period of accesstoken is shorter, when accesstoken is invalid due to expiration, using refreshtoken can get a new accesstoken, if refreshtoken is also invalid, the user can only re-login.

[0049] Redis: Redis (Remote Dictionary Server), that is, remote dictionary service, is an open source using ANSI C language, supporting network, can be based on memory and persistent log type, Key-Value database, and provides API in multiple languages.

[0050] Distributed lock Redisson: When a single web application, if multiple threads want to access shared resources, we usually use the inter-thread locking mechanism, at a certain time, only one thread can operate on this resource, other threads need to wait for the release of the lock, Java also has some processing lock mechanism, such as synchronized. When it comes to distributed environment, when a resource can be accessed by multiple systems, in order to ensure the consistency of access to this data, it is required that only one system can be used at the same time. At this time, the thread locking mechanism cannot work, because in the distributed environment, the system will be deployed to different machines, so we need to use distributed locks.

[0051] Redisson is a Java in-memory data grid based on Redis. It not only provides a series of distributed Java common objects, but also implements ReentrantLock, Fair Lock, Multi Lock, Red Lock, Read WriteLock, etc. It 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 of users to Redis, so that users can focus more on business logic.

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

[0053] Example 1:

[0054] As shown in the figure, the embodiment of the present application provides a double-token authorization refresh method based on dynamic expiration tolerance, which comprises the following steps. Figure 1 Step 100: 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; the smaller the qps, Tresp and U are, the smaller the dynamic expiration tolerance is; the larger the qps, Tresp and U are, the larger the dynamic expiration tolerance is. It should be noted that the dynamic expiration tolerance is essentially a dynamic grace period. Originally, when the access token carried by a request expires, it is not allowed to directly access the protected resource. However, after setting the dynamic expiration tolerance, if the expiration time of the access token carried by the request is less than the corresponding dynamic expiration tolerance time, the grace period is obtained and the access to the protected resource is permitted.

[0055] Step 200: for the first request whose access token is expired and whose refresh token is not expired, if the expiration time of the corresponding request's access token is within the corresponding dynamic expiration tolerance, set a distributed lock for the request, and trigger the token refresh mechanism 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 the scenario where the access token is expired and the refresh token is not expired. In this scenario, the first request carrying the expired access token needs to trigger the token refresh mechanism to obtain a new access token. The subsequent requests can be judged according to the dynamic expiration tolerance to see if they can be permitted to access the protected resource.

[0056] Step 300: for the subsequent request of the first request, if the expiration time of the corresponding request's access token is within the corresponding dynamic expiration tolerance, do not trigger the token refresh mechanism and directly allow normal access. It should be noted that for the subsequent request of the first request, in the case where the first request triggers the token refresh mechanism, 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, the protected resource can be accessed without triggering the token refresh mechanism again.

[0057]

[0058] ​Based on the above steps, this embodiment of the invention constructs a dynamic expiration tolerance, combining multi-dimensional performance indicators of the backend server. It integrates server performance indicators collected from multiple dimensions, such as requests per second (QPS) of key APIs, response time (Tresp) of key APIs, and database connection pool utilization (U). This innovatively models the dynamic expiration tolerance, optimizing the pain points and problems of the fixed expiration tolerance time parameter, inflexible static configuration, and lack of linkage with current server resource utilization and fine-grained load in patent CN112003852B. Furthermore, it introduces a distributed lock to comprehensively cover all scenarios and categories of expired and abnormal requests.

[0059] In some embodiments, modeling the dynamic expiration tolerance based on the key API's requests per second (QPS), the key API's response time (Tresp), and the database connection pool utilization (U) specifically includes:

[0060] Define a system busy rate:

[0061] ;

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

[0063] Assuming the maximum expiration tolerance is T_max and the minimum expiration tolerance is T_min, then the dynamic expiration tolerance... for:

[0064] ;

[0065] in, The values ​​are dynamically determined in [T_min, T_max].

[0066] With the above settings, the lower the QPS, Tresp, and U, the better the system performance, the more requests it can handle, and the values ​​in the log approach 0. Approaching T_min, meaning the dynamic expiration tolerance will be smaller, aligns with the physical meaning of resource utilization. When qps, Tresp, and U are larger, system performance is worse, fewer requests can be accommodated, response and processing speeds decrease, the value in log approaches 1, and the entire expression approaches T_max, meaning the dynamic expiration tolerance is larger, giving the system more time for authorization and fault tolerance, aligning with the physical meaning of resource utilization.

[0067] With the above settings, the expiration tolerance value can be dynamically set for each request based on the system performance at the corresponding time, thus optimizing the pain points and problems of fixed expiration tolerance time parameters, inflexible static configuration, and lack of linkage with the current server resource utilization and fine-grained load in patent CN112003852B.

[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 as the previously expired access token; and setting the new access token as the current access token. That is, two pieces of information are maintained for the access token: the current access token and the previously expired access token. Each time the token refresh mechanism is executed, a new access token is generated as the current access token, while the original access token becomes the previously expired access token. This setting is to distinguish between different subsequent expiration scenarios.

[0069] In some embodiments, refresh rules are set for requests, and the corresponding refresh rule is selected and executed based on the distributed lock state, the request's access token state, and whether the expiration time is within the dynamic expiration tolerance. By combining these three pieces of information—distributed lock state, request's 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 distributed lock is in an acquireable state, 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 on the request, triggering a token refresh mechanism, and releasing the distributed lock after the token refresh mechanism is completed. The scenario corresponding to this first refresh rule is the first request carrying an expired request. That is, it corresponds to the scenario in step 200 where the access token has expired but the refresh token has not expired.

[0071] Additionally, regarding the first refresh rule, if the expiration time of the first request 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 (e.g., 2 days). Clicking the page initiates a series of network requests, but the token has expired and expired for too long. The system will not allow any requests carrying expired tokens to pass through, and the page will then redirect to the login page, prompting the user to re-enter the username, password, verification code, and other information to re-authorize the login. Any requests carrying expired tokens will not be allowed to pass through, thus ensuring the authorization security of the system.

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

[0073] In some embodiments, when the distributed lock is in an acquireable state, the requested access token is a previously expired access token, and the expiration time is within the dynamic expiration tolerance, a third refresh rule is selected for execution. The third refresh rule includes: not triggering a token refresh mechanism for this request, and directly allowing normal access. This third rule corresponds to the scenario where the 2nd to nth subsequent requests carry expired tokens, and the request arrives at the server after the distributed lock has been released. Some subsequent requests following the first request in step 300 correspond to this scenario.

[0074] Additionally, for the second and third refresh rules, the probability of requests 2 to n expiring outside the dynamic expiration tolerance is relatively low. If this does occur, the corresponding physical meaning or typical scenario is: the page has just expired, but the 2nd to nth requests may not arrive in time due to network latency or failure. By the time the requests arrive, the expiration tolerance has already expired. There are two possible handling methods: Method 1: Redirect requests with expired tokens and expired tolerances to the login page, requiring the user to re-enter their username, password, and verification code for re-authorization. Prevent any requests carrying expired tokens from passing, ensuring system security. Method 2: Prevent requests with expired tokens and expired tolerances from passing, but do not redirect to the login page. Because the first request succeeded, although the 2nd to nth requests failed, resulting in missing or incomplete page data, when the user makes the next request, the client has already cached the valid token from the first update. The client carries the locally updated cached valid token and refreshes the page to access the target resource.

[0075] In some embodiments, when the requested access token is the current access token and has not expired, the fourth refresh rule is selected for execution. The fourth refresh rule includes: allowing normal access directly without any further judgment. The scenario corresponding to this fourth rule is that after the token refresh mechanism has been completed and the distributed lock has been released, the client has obtained a new access token and sends a request carrying the new access token. At this time, the token carried in the request is the new access token, that is, the current access token mentioned above, and since the current access token has just been obtained and has not expired, normal access can be directly granted.

[0076] In summary, this invention provides a dual-token authorization refresh method based on dynamic expiration tolerance. Its technical innovation lies in protecting critical resources by constructing dynamic expiration tolerance. It integrates multi-dimensional performance metrics from the backend server, including requests per second (QPS) of key APIs, response time (Tresp) of key APIs, and database connection pool utilization (U). This innovative modeling of dynamic expiration tolerance addresses the pain points and problems of patent CN112003852B, such as fixed expiration tolerance time parameters, inflexible static configuration, and lack of linkage with current server resource utilization and refined load.

[0077] Furthermore, in terms of business innovation, by introducing distributed locks, we can comprehensively cover all scenarios and categories of expired and abnormal requests.

[0078] Based on the above method, this embodiment also provides a dual-token authorization refresh system based on dynamic expiration tolerance, see reference. Figure 2 As shown, the system includes a dynamic expiration tolerance modeling module, a first request processing module, and a subsequent request processing module. The dynamic expiration tolerance modeling module models the dynamic expiration tolerance based on the requests per second (qps), response time (Tresp), and database connection pool utilization (U) of the key API. The lower the qps, Tresp, and U, the lower the dynamic expiration tolerance; the higher the qps, Tresp, and U, the higher the dynamic expiration tolerance. The first request processing module sets a distributed lock on the first request whose access token has expired but whose refresh token has not, if the expiration duration of the access token for that request is within the corresponding dynamic expiration tolerance, and triggers a token refresh mechanism. After the token refresh mechanism is completed, the distributed lock is released. The subsequent request processing module allows normal access without triggering a token refresh mechanism for subsequent requests to the first request if the expiration duration of the access token for that request is within the corresponding dynamic expiration tolerance. The specific implementation process of each module can be found in the above steps and will not be elaborated here.

[0079] Example 2:

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

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

[0082] First, the user initiates a login request on the web or mobile page, enters their username and password, and completes the login. This process prompts the server to query user information and determine if the user data is a valid user ID and password; we'll name the user ID "user_id". If the user_id and password do not meet the validation rules, an error message is displayed, and the subsequent process terminates. If the user_id and password meet the validation rules, the server performs the following operations:

[0083] The token generation module is invoked to generate a token; at the same time as generating the above token information, a copy of the above token information will be stored in the token database management module; at the same time as generating the above token information, a copy of the above token information will be cached in the token caching module.

[0084] The aforementioned caching frameworks are common knowledge and have mature open-source implementations. The corresponding open-source frameworks are named ehcache, memcache, and redis, respectively. The implementation principles of each open-source framework will not be elaborated here. We use redis as the primary server-side caching method 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 caching module caches user information and token information in Redis, where the key read from Redis is user_id; subsequently, the cached information accesstoken_info_cache can be read through the Redis key (here, user_id). The cached information accesstoken_info_cache includes, but is not limited to: curr_token(i), the token of the current user i, which is the current access token in embodiment 1; prev_token(i), the previous token of the current user i, which is the previously expired access token in embodiment 1; refresh_lock(i), the distributed lock for concurrent refresh of the current user i.

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

[0087] Then, the web client caches the `curr_token` information from the above steps on the page. When requesting resources, it carries this token information, opens a page, and triggers the client to request the protected resource. In engineering implementations, carrying the token information is typically done by including a header named `Authorization` in the HTTP header.

[0088] A method for sending a request to a specific URL, represented by curl, can be described as follows:

[0089] curl -X POST --header "Content-Type: application / json" --header "Accept: * / *" -d "{

[0090] "pagination": {

[0091] "current": 0,

[0092] "limit": 0,

[0093] "offset": 0,

[0094] "pageSize": 0

[0095] },

[0096] "usr_id": "string"

[0097] }"-H "Authorization: Bearer xxxx" \

[0098] "http: / / myhost:port / protect_resource_path1"

[0099] The above -H "Authorization: Bearer xxxx" indicates that the xxxx string is the curr_token as an additional header in the request;

[0100] http: / / myhost:port / protect_resource_path1 represents the URL corresponding to the resource in the above protected request;

[0101] We named url1=http: / / myhost:port / protect_resource_path1;

[0102] We denote the above request as request(curr_token, url1);

[0103] The protected request resource URLs mentioned above are generally web services protected by OAuth2, such as http: / / myhost:port / protect_resource_path;

[0104] If the aforementioned 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 access".

[0105] Throughout the entire process of retrieving resources from the aforementioned page, if the requested curr_token has not expired, the above steps can successfully retrieve the corresponding static resources and service interface information for the page, thus completing the page opening.

[0106] If the client's cached curr_token has expired when retrieving resources from the aforementioned page, there are several possible scenarios for curr_token expiration, which will be analyzed and addressed below. It's worth noting that when opening the page in the above steps, there are typically a large number of concurrent requests rather than a single request within a short period; this embodiment makes the following stipulations:

[0107] Opening a certain page involves N requests, named as follows:

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

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

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

[0111] ...

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

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

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

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

[0116] Clearly, request(curr_token, url(1), t(1)) is the first request in the local page open event.

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

[0118] If curr_token has expired but refreshtoken has not expired when request(curr_token, url(1), t(1)) is initiated, then the DTARADETDL algorithm in the core resource authorization 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 (DTARADETDL).

[0119] When the curr_token expires, clicking the page will trigger 1-n concurrent transactions carrying the expired token in a short period of time. This embodiment optimizes the model and designs the algorithm for the above scenario.

[0120] The first transaction carrying an expired token that arrives fastest can utilize Redission's distributed lock 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.

[0121] In this embodiment, after user i's first invalidation request 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 update are performed atomically. The distributed lock is released after token refresh, curr_token(i), and prev_token(i) cache data update are completed.

[0122] Therefore, for the current concurrent requests, the duration of the distributed lock for user i is Figure 3In the interval [T1, T2], the aforementioned distributed lock resource is defined as RedissionLock(i). Clearly, through rule 1 in the rule judgment table (comprehensive judgment based on lock state, token state, and expiration time), the system can distinguish between the first request initiated by the current user (which will trigger a token refresh transaction) and the remaining n-1 requests (which do not require token refresh). The subsequent 2-n requests (refresh_st=1) are not synchronously blocked; instead, the cached dual-token information is compared, and based on the modeling result of user i's token dynamic expiration tolerance tolerance_t_window(i), the time given to the request is obtained, i.e., the dynamic grace period of the expiration tolerance. Requests carrying expired tokens but meeting the tolerance_t_window (e.g., a dynamically calculated result of 30 seconds) are allowed (analogous to a student arriving 30 seconds late with their ID card being allowed entry). The algorithm can accurately distinguish between the first and second to n types of requests and process them differently; and allows the subsequent second to n requests carrying expired tokens that are within the tolerance_time_window (e.g., 30 seconds, within the expiration tolerance period) to be verified using prev_token or curr_token, thereby avoiding the repeated triggering of the refreshtoken refresh process due to the failure of 2-n business requests.

[0123] The definitions of the first request and subsequent requests 2-n can be divided into several scenarios, see details. Figure 3 The following rule decision table is used. Each rule can be uniquely determined by a combination of three factors: lock state, token state, and expiration time equation. The rule decision table is as follows:

[0124]

[0125] Rule 1 corresponds to the first refresh rule in Embodiment 1, Rule 2 corresponds to the second refresh rule in Embodiment 1, Rule 3 corresponds to the third refresh rule in Embodiment 1, and Rule 4 corresponds to the fourth refresh rule in Embodiment 1.

[0126] The DTARADETDL algorithm uses dual tokens as a handling strategy during the concurrent contention phase of token refresh requests. This is achieved by setting a certain expiration tolerance (allowing expired requests for the same user ID to proceed within a short period after the token expires, such as the remaining 2 to n requests in this example). The time is generally short, which also ensures the security of the tolerance when the requirements are relaxed, and achieves the purpose of solving the problem of repeated refresh of refresh token when the refresh token is in a state of concurrent competition.

[0127] In this embodiment, there are a total of N requests to open the page. These N requests can be divided into three categories. Specifically, the first request initiated at the beginning, request(accesstoken, url(1), t(1)), is denoted as category A. The second request, request(accesstoken, url(2), t(2)) to the jth request, request(accesstoken, url(j), t(j)), totaling j-1 requests, is denoted as category B. The remaining requests, from the j+1th to the Nth, totaling N-(j+1)+1=Nj requests, are denoted as category C.

[0128] For request type A: Request type A triggers event A, at which point a valid curr_token(i) is matched but expired. The first expired request is determined by rule 1, triggering a token refresh. After user i's first expired request is determined by rule 1, a distributed lock is created using Redission to ensure atomicity in token refresh, curr_token(i), and prev_token(i) cache data updates. The distributed lock is released after the token refresh, curr_token(i), and prev_token(i) cache data updates are complete. Therefore, for the current concurrent requests, the duration of user i's distributed lock is... Figure 3 In the interval [T1,T2], the above distributed lock resource is defined as RedissionLock(i). Obviously, by using rule 1 in the rule judgment table (comprehensive judgment of lock status, token status, and expiration time), the system can distinguish between the first request initiated by the current user (which will trigger a token refresh transaction) and the remaining n-1 requests (which do not require token refresh).

[0129] For Class B requests: Event B is triggered. At this time, a valid curr_token may be matched, or a valid prev_token may be matched but no valid curr_token may be matched. If the requirements of rules 2 and 3 are met, the request can still be made normally even though the curr_token or prev_token has expired. In this case, there is no need to update the accesstoken and refreshtoken. The request is allowed to access the protected resource normally.

[0130] For Class C requests: Event C is triggered. The request meets rule 4. At this time, the token has not expired and is in a normal state, allowing the request to access the protected resource normally.

[0131] Thus, the DTARADETDL algorithm solves the problem of repeatedly obtaining refresh tokens under concurrent competition after the token expires; it can efficiently, correctly, and error-free execute the aforementioned A, B, and C type requests.

[0132] There are multiple ways to model the dynamic expiration tolerance_t_window in the DTARADETDL algorithm described above. This embodiment innovatively uses a dynamic grace period to model the tolerance_t_window.

[0133] Specifically, we integrate the QPS (queries per second) of key APIs, the Tresp (response time) of key APIs, and the utilization U of the database connection pool. We can define a system busy rate:

[0134] ;

[0135] The meanings of the symbols, their physical meanings, and the modeling logic in the server system busy rate formula are as follows:

[0136] It can model the relationship between the utilization of the database connection pool and the system's busyness, smoothly mapping the linear growth of U to a non-linear growth space. This reflects the characteristic that the system grows faster when the connection pool utilization is low, and slows down when the utilization is close to saturation.

[0137] It can perform a nonlinear mapping that normalizes the input to (0,1) using a sigmoid activation function.

[0138] therefore It is possible to model the relationship between database connection pool utilization and system busyness; as U increases, It also increases, and its range is (0,1).

[0139] Increase It also increases;

[0140] analyze The first derivative can be obtained It is an increasing function;

[0141] Therefore, with Increase It also increases and the range of change is (0,1);

[0142] It can model the relationship between API QPS (queries per second), critical API response time (Tresp), and system busyness.

[0143] Assuming the above factors contribute 0.5 to the busyness factor, a weighted average is applied.

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

[0145] ;

[0146] The busier the system is, the slower the number of requests it responds to per unit time, and the longer the dynamic grace period needs to be; we assume that the maximum tolerance is T_max (e.g., 100s) and the minimum tolerance is T_min (e.g., 10s);

[0147] We map it to the following formula:

[0148] ;

[0149] Obviously, when the values ​​of U, QPS, and Tresp are small, the system performance is better, it can accommodate more requests, and the values ​​in the log are close to 0. Approaching T_min aligns with the physical meaning of resource utilization; when U, qps, and Tresp values ​​are large, system performance is poor, fewer requests can be accommodated, response and processing rates decrease, the value in the log approaches 1, and the entire expression approaches T_max, giving the system more time for authorization and fault tolerance, which aligns with the physical meaning of resource utilization; thus, the entire... The values ​​are dynamically determined in [T_min, T_max].

[0150] It should also be noted that in the above formula, 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 accelerates when the utilization rate U of the database connection pool is close to saturation; in this embodiment, α=1.5; the specific value of α can be adjusted according to the actual engineering effect or historical system data. In this embodiment, when β is selected with a reasonable value, such as 6, its non-linear adjustment effect is more obvious, allowing the value near the database connection pool to fluctuate greatly in a specific area (e.g., 0.5), while making the rate of change of U insignificant when it is very small (machine idle) and close to 1 (machine busy). In this embodiment, β=6; the specific value of β can be adjusted according to the actual engineering effect or historical system data. γ can control the magnitude and range of change when the response time Tresp changes; a smaller γ shows a significant rate of change for a wider range of Tresp; a larger γ, when Tresp is large and shows changes, has already saturated and grows slowly near slightly less than 1; in this embodiment, γ=1, and the specific value of γ can be adjusted according to the actual engineering effect or historical system data. Tresp averThe parameters indicate an average request response time obtained by statistical analysis of key transactions; for example, for core authorization transaction API interfaces, large-scale data statistics are performed to analyze their response time, including data cleaning, analysis, and finally removal of outliers to calculate Tresp. aver It takes 0.5 seconds; the actual Tresp aver The parameters need to be obtained through statistical analysis based on historical system data.

[0151] In summary, this invention provides a dual-token authorization refresh method based on dynamic expiration tolerance. Its technical innovation lies in protecting critical resources by constructing dynamic expiration tolerance. It integrates multi-dimensional performance metrics from the backend server, such as requests per second (QPS) of key APIs, response time (Tresp) of key APIs, and database connection pool utilization (U). This innovative modeling of dynamic expiration tolerance addresses the pain points and problems of patent CN112003852B, which suffers from fixed expiration tolerance time parameters, inflexible static configuration, and lack of linkage with current server resource utilization and refined load balancing.

[0152] Furthermore, in terms of business innovation, by introducing distributed locks, we can comprehensively cover all scenarios and categories of expired and abnormal requests.

[0153] Example 3:

[0154] Based on the dual-token authorization refresh method based on dynamic expiration tolerance provided in Embodiment 1 above, 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 The diagram shown is a schematic representation of the device architecture according to an embodiment of the present invention. This embodiment of the dual-token authorization refresh device based on dynamic expiration tolerance includes one or more processors 21 and a memory 22. Wherein, Figure 4 Take a processor 21 as an example.

[0155] Processor 21 and memory 22 can be connected via a bus or other means. Figure 4 Taking the example of a connection between China and Israel via a bus.

[0156] 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 Embodiment 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, thereby implementing the dual-token authorization refresh method based on dynamic expiration tolerance in Embodiment 1.

[0157] Memory 22 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some embodiments, memory 22 may optionally include memory remotely located relative to processor 21, which can be connected to processor 21 via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

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

[0159] The above-described product can perform the methods provided in the embodiments of this application, and has the corresponding functional modules and beneficial effects for performing the methods. Technical details not described in detail in this embodiment can be found in the methods provided in the embodiments of this application.

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

[0161] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented using software and a general-purpose hardware platform, or of course, using hardware. Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0162] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; under the concept of the present invention, the technical features of the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations of different aspects of the present invention as described above. For the sake of brevity, they are not provided in detail; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate 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: 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. The smaller the QPS, Tresp, and U, the smaller the dynamic expiration tolerance; the larger the QPS, Tresp, and U, the larger the dynamic expiration tolerance. For the first request where the access token has expired but the refresh token has not expired, if the expiration time of the access token for 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 completed, the distributed lock is released. For subsequent requests to the first request, if the access token for the corresponding request expires within the corresponding dynamic expiration tolerance, the token refresh mechanism will not be triggered, and normal access will be allowed directly. The modeling of dynamic expiration tolerance based on the key API's requests per second (QPS), key API response time (Tresp), and database connection pool utilization (U) specifically includes: Define a system busy rate: ； Where i represents the index identifier of the current user, α, β, and γ are coefficients, and Tresp aver Indicates the average response time; Assuming the maximum expiration tolerance is T_max and the minimum expiration tolerance is T_min, then the dynamic expiration tolerance... for: ； in, The values ​​are dynamically determined in [T_min, T_max].

2. The dual-token authorization refresh method based on dynamic expiration tolerance according to claim 1, characterized in that, The token refresh mechanism specifically includes: Obtain a new access token and a new refresh token; Set the current access token to the last expired access token; Set the new access token as the current access token.

3. The dual-token authorization refresh method based on dynamic expiration tolerance according to claim 2, characterized in that, Set refresh rules for requests, and select the corresponding refresh rules to execute based on the distributed lock status, the request's access token status, and whether the expiration time is within the dynamic expiration tolerance. When the distributed lock is in an acquireable state, the requested access token is in the current access token state, 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, and releasing the distributed lock after the token refresh mechanism is completed.

4. The dual-token authorization refresh method based on dynamic expiration tolerance according to claim 3, characterized in that, When the distributed lock is in an occupied state, the requested access token is in the current access token state, 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 this request, and directly allowing normal access.

5. The dual-token authorization refresh method based on dynamic expiration tolerance according to claim 3, characterized in that, When the distributed lock is in an acquireable state, the requested access token is a previously expired 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 the token refresh mechanism for this request, and directly allowing normal access.

6. The dual-token authorization refresh method based on dynamic expiration tolerance according to claim 3, characterized in that, If the requested access token is in the current access token state and has not expired, select the fourth refresh rule to execute; The fourth refresh rule includes: allowing normal access directly without any further judgment.

7. A dual-token authorization refresh device based on dynamic expiration tolerance, characterized in that, The apparatus 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, the instructions being executed by the processor for performing the dual-token authorization refresh method based on dynamic expiration tolerance as described in any one of claims 1-6.

8. A dual-token authorization refresh system based on dynamic expiration tolerance, employing the dual-token authorization refresh method based on dynamic expiration tolerance as described in any one of claims 1-6, characterized in that, The system includes a dynamic expiration tolerance modeling module, a first request processing module, and subsequent request processing modules, wherein: The dynamic expiration tolerance modeling module is used to model 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. The smaller the qps, Tresp, and U are, the smaller the dynamic expiration tolerance is; the larger the qps, Tresp, and U are, the larger the dynamic expiration tolerance is. The first request processing module is used to: for the first request where the access token has expired but the refresh token has not expired, if the expiration time of the access token for the corresponding request is within the corresponding dynamic expiration tolerance, then set a distributed lock for the request and trigger the token refresh mechanism at the same time. After the token refresh mechanism is completed, release the distributed lock. The subsequent request processing module is used to: for subsequent requests of the first request, if the expiration time of the access token for the corresponding request is within the corresponding dynamic expiration tolerance, then the token refresh mechanism is not triggered, and normal access is directly allowed.

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

Images