CN119834982A - Dual-token authorized refreshing method, device and system based on dynamic expiration tolerance - Google Patents

Abstract

The invention relates to a double-token authorization refreshing method, device and system based on dynamic expiration tolerance. The method comprises the steps of modeling the dynamic expiration tolerance according to the number qps of requests per second of a key API, response time Tresp of the key API and utilization rate U of a database connection pool, setting a distributed lock for a first request with an expired access token and an unexpired refresh token if the expiration duration of the access token of the corresponding request is within the corresponding dynamic expiration tolerance, triggering a token refresh mechanism, releasing the distributed lock after the token refresh mechanism is executed, and directly allowing normal access for subsequent requests of the first request if the expiration duration of the access token of the corresponding request is within the corresponding dynamic expiration tolerance. The method models the dynamic expiration tolerance, and optimizes pain points and problems of fixed expiration tolerance time parameters and inflexible static configuration in the prior art.

Description

Dual-token authorized refreshing method, device and system based on dynamic expiration tolerance

Technical Field

The invention relates to the technical field of network authority control, in particular to a double-token authorization refreshing method, device and system based on dynamic expiration tolerance.

Background

The CN110266703a solves the problem that when a large number of network requests need to acquire new tokens (token), the concurrent refresh expiration token cannot be effectively processed at present, and the solution idea is to add a synchronization lock to the client refresh operation, so that the refresh operation successfully sends the network request of the refreshed token, and the refresh operation of the network request token is continuously and orderly completed. The above scheme is similar to that for on-end Web Promise (Promise is a key technique for solving asynchronous programming problems), for android Java LinkedBlockingQueue (LinkedBlockingQueue is a linked list based blocking queue), for iOS NSOperationQueue (NSOperationQueue is a set of multi-threaded solutions provided by iOS). The business pain point and inefficiency is that multiple sets of similar codes are required to be maintained aiming at Web, small programs, android and iOS channels, so that different technical stack codes of multiple platforms are required to be maintained, the workload is huge, the understanding degree requirements on business details are high, furthermore, the same logic is required to be recoded on different heterogeneous differentiation platforms each time along with the increase of the number of terminals and access platforms, the code quantity is large, when defects are met, the defects are required to be completely revised on all the platforms, and when the codes are required to be updated, reconstruction and optimization, the refined code time and business logic synchronization aiming at the multiple platforms, the multiple languages, the multiple operating systems and the multiple frameworks are required to be differentiated, so that the maintainability is poor, and the defects of low maintainability and low expandability are caused. Second, another drawback of patent CN110266703a is that concurrency, sequential execution, and processing similar to that of the lock can reduce system efficiency, reduce system concurrency, and reduce system throughput.

In view of the above-described drawbacks of patent CN110266703a, patent CN112003852B foregoes processing at the client and goes processing efficiently towards the server back-end. The patent CN112003852B carries out multi-level, three-dimensional and differentiated intelligent judgment on the current request at the server side according to multi-dimensional judgment conditions, avoids the unordered and repeated refreshing problems caused by concurrent competing refreshing requests in an overdue tolerance time period, simultaneously, the unified framework processing of the server side avoids a great amount of redundant heavy work for carrying out token refreshing adaptation by repeated coding at different clients, and the patent CN112003852B further avoids the performance and efficiency loss problems caused by the traditional adoption of a synchronous mechanism, a locking mechanism or an ordered queue.

However, when considering the expiration tolerance, the patent CN112003852B selects a static configuration value for the expiration tolerance time, and does not link with the current resource utilization and refined load of the server, and when considering the expiration token concurrent request, the patent CN112003852B does not classify the abnormal token request completely, and there is a problem that omission does not completely cover the scene of the expiration request.

In view of this, how to overcome the defects existing in the prior art, how to link the expiration tolerance with the resource utilization and the refined load of the current server, and how to cover the scenario of more expiration requests, is an important technical problem to be solved in the industry.

Disclosure of Invention

The method aims at the defects or improvement requirements in the prior art, namely a scene of how to link the expiration tolerance with the resource utilization and refined load of the current server and how to cover more expiration requests. The invention provides a double-token authorization refreshing method, a device and a system based on dynamic expiration tolerance, which are used for protecting critical resources, constructing dynamic expiration tolerance time, integrating server performance indexes acquired in multiple dimensions such as request number per second (Queries Per Second, abbreviated as QPS) of a key application programming interface (Application Programming Interface, abbreviated as API), response time (Tresp) of the key API, utilization rate (U) of a database connection pool and the like by combining the performance indexes of multiple dimensions of a back-end server, innovatively modeling the dynamic expiration tolerance time, optimizing the pain points and problems that the expiration tolerance time parameter is fixed, static configuration is inflexible, and the pain points and problems of linkage with the resource utilization and refined load of a current server in a patent CN 112003852B. Further, at the service innovation point, all scene and category problems of the expired exception request are covered comprehensively by introducing the distributed locks.

The invention adopts the following technical scheme:

in a first aspect, the present invention provides a dual token authorization refresh method based on dynamic expiration tolerance, including:

Modeling the dynamic expiration tolerance according to the request per second qps of the key API, the response time Tresp of the key API and the utilization rate U of a database connection pool, wherein the smaller the qps, the Tresp and the U are, the smaller the dynamic expiration tolerance is, and the larger the qps, the Tresp and the U are;

For a first request with an expired access token and a non-expired refresh token, if the expiration time 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, and releasing the distributed lock after the token refresh mechanism is executed;

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.

In some embodiments, the 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 U of the database connection pool specifically includes:

defining a system busy rate:

wherein i represents index identification of the current user, alpha, beta and gamma represent coefficients, and Tresp _aver represents 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:

wherein tolerance_t_window (i, U, qps) is dynamically valued at [ t_min, t_max ].

In some embodiments, the token refresh mechanism specifically includes:

acquiring a new access token and a new refresh token;

setting the current access token as the last invalid access token;

the new access token is set to the current access token.

In some embodiments, refresh rules are set for the request, and execution is performed by selecting corresponding refresh rules within a dynamic expiration tolerance through the distributed lock state, the requested access token state, and the expiration duration;

when the distributed lock state is that the distributed lock can be acquired, the requested access token state is the current access token, the expiration time is within the dynamic expiration tolerance, a first refreshing rule is selected for execution, and the first refreshing rule comprises setting the distributed lock for the request, triggering a token refreshing mechanism, and releasing the distributed lock after the token refreshing mechanism is executed.

In some embodiments, when the distributed lock state is occupied, the requested access token state is the current access token, and the expiration duration is within the dynamic expiration tolerance, a second refresh rule is selected for execution, wherein the second refresh rule comprises that a token refresh mechanism is not triggered for the request, and normal access is directly allowed.

In some embodiments, when the distributed lock state is that the distributed lock can be obtained, the requested access token state is that the access token is invalid last time, and the expiration time is within the dynamic expiration tolerance, a third refresh rule is selected for execution, wherein the third refresh rule comprises that a token refresh mechanism is not triggered for the request, and normal access is directly allowed.

In some embodiments, when the requested access token state is the current access token and is not expired, a fourth refresh rule is selected for execution, the fourth refresh rule comprising allowing normal access directly without further determination.

In a second aspect, the present invention further provides a dual token authorized refresh device based on dynamic expiration tolerance, the device comprising:

And a memory communicatively coupled to the at least one processor, wherein the memory stores instructions executable by the at least one processor for performing the dynamic expiration tolerance-based dual token authorized refresh method of the first aspect.

In a third aspect, the present invention further provides a dual token grant refresh system based on dynamic expiration tolerance, applying the dual token grant refresh method based on dynamic expiration tolerance according to the first aspect, where the system includes a dynamic expiration tolerance modeling module, a first request processing module, and a subsequent request processing module, where:

The dynamic expiration tolerance modeling module is used for modeling the dynamic expiration tolerance according to the number of requests per second of the key API qps, the response time Tresp of the key API and the utilization rate U of a database connection pool, wherein the smaller the qps, the Tresp and the U are, the smaller the dynamic expiration tolerance is, and the larger the qps, the Tresp and the U are;

The first request processing module is used for setting a distributed lock for a first request with an expired access token and an unexpired refresh token if the expired access token time length of the corresponding request is within the corresponding dynamic expiration tolerance, triggering a token refresh mechanism, and releasing the distributed lock after the token refresh mechanism is executed;

The subsequent request processing module is used for directly allowing normal access to the subsequent request of the first request if the expiration duration of the access token of the corresponding request is within the corresponding dynamic expiration tolerance without triggering a token refreshing mechanism.

In a fourth aspect, the present invention also provides a non-volatile computer storage medium storing computer executable instructions for execution by one or more processors to perform the dual token authorized refresh method according to the first aspect based on dynamic expiration tolerance.

Compared with the prior art, the dual-token authorization refreshing method, device and system based on the dynamic expiration tolerance have the beneficial effects that on the technical innovation point, the dynamic expiration tolerance is constructed by aiming at critical resources, the server performance indexes acquired in multiple dimensions such as the number of requests per second qps of key APIs, the response time Tresp of the key APIs and the utilization rate U of a database connection pool are integrated by combining the performance indexes of multiple dimensions of a rear-end server, the dynamic expiration tolerance is innovatively modeled, and the pain points and problems that the expiration tolerance time parameter is fixed, the static configuration is inflexible and the linkage with the resource utilization and the refined load of the current server are avoided in the patent CN112003852B are optimized.

Further, at the service innovation point, all scene and category problems of the expired exception request are covered comprehensively by introducing the distributed locks.

Drawings

In order to more clearly illustrate the technical solution of the embodiments of the present invention, the drawings that are required to be used in the embodiments of the present invention will be briefly described below. It is evident that the drawings described below are only some embodiments of the present invention and that other drawings may be obtained from these drawings without inventive effort for a person of ordinary skill in the art.

Fig. 1 is a flowchart of a dual token authorized refresh method based on dynamic expiration tolerance provided in embodiment 1 of the present invention;

Fig. 2 is a schematic block diagram of a dual token authorized refresh system based on dynamic expiration tolerance according to embodiment 1 of the present invention;

FIG. 3 is a timing diagram of a request case according to embodiment 2 of the present invention;

fig. 4 is a schematic structural diagram of a dual token authorized refresh device based on dynamic expiration tolerance according to embodiment 3 of the present invention.

Detailed Description

The present application will be described in detail with reference to specific examples. The following examples will assist those skilled in the art in further understanding the present application, but are not intended to limit the application in any way. It should be noted that variations and modifications could be made by those skilled in the art without departing from the inventive concept. These are all within the scope of the present application. It should be noted that, if not in conflict, the features of the embodiments of the present application may be combined with each other, which is within the protection scope of the present application. In addition, while functional block division may have been performed in a device diagram, a logical order may be depicted in a flowchart, in some cases, steps depicted or described may be performed differently than block division in a device, or in a sequence in a flowchart.

Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. The terminology used in the description of the invention herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. In addition, the technical features of the embodiments of the present invention described below may be combined with each other as long as they do not collide with each other.

Throughout the specification and claims, the term "comprising" is to be interpreted as an open-ended meaning, i.e. as "including, but not limited to, unless the context requires otherwise. In the description of the present specification, the terms "one embodiment," "some embodiments," "example embodiments," "examples," "particular examples," or "some examples," etc., are intended to indicate that a particular feature, structure, material, or characteristic associated with the embodiment or example is included in at least one embodiment or example of the present disclosure. The schematic representations of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the particular features, structures, materials, or characteristics described may be included in any suitable manner in any one or more embodiments or examples, i.e., embodiments or examples that may be described in any suitable manner in one or more embodiments or examples, although they may be carried out in various combinations, for example, due to the order of occurrence and location of such features, etc.

Before describing the embodiments, explanation of terms in the embodiments of the present invention will be described:

oauth 2.0-oauth 2.0 is an open standard that allows a user to authorize a third party mobile application to access a particular private resource of the user in a server without the need to provide the third party mobile application with a user name and password or to share all of their data, oauth2.0 is a continuation of the oauth protocol, but is not backwards compatible with oauth 1.0.

Accesstoken (access token) token is also called token, accesstoken is a string of character strings generated by the server in oauth2.0 to be used as a token for the client to request, after logging in for the first time, the server generates a accesstoken to return accesstoken to the client, and the client only needs to carry accesstoken to request data, and does not need to carry a user name and a password again. And under the background that the client frequently requests data from the server, the server frequently goes to the database to inquire the user name and the password, compares the user name and the password, judges whether the user name and the password are correct or not and makes corresponding prompts, accesstoken is generated. accesstoken aims to relieve the pressure of the server, reduce frequent database query and make the server more robust.

Refreshtoken (refresh token) token is a credential to acquire a protected resource, of course an expiration time is necessary. Otherwise, the user can use the device permanently after logging in once, and the authentication function loses the meaning. the token must not only have an expiration time, but also not too long, and in addition to accesstoken, there is another token refreshtoken, typically with a relatively long expiration of refreshtoken and a relatively short expiration of accesstoken, and when accesstoken fails due to expiration, a new accesstoken is obtained using refreshtoken, and if refreshtoken fails, the user can only log in again.

Redis: redis (Remote Dictionary Server), a remote dictionary service, is an open-source log-type, key-Value database written and supported by ANSI C language, can be based on memory and can be persistent, and provides multiple language APIs.

Distributed lock Redisson when a single web application is used, if multiple threads are to access a shared resource, we usually use a mechanism of locking between threads, only one thread can operate on the resource at a time, other threads need to wait for release of the lock, and some mechanisms for processing the lock, such as synchronized, are also available in Java. In a distributed environment, when a resource is accessed and used by a plurality of systems, in order to ensure that the data is consistent for a large number of accesses, the resource is required to be used by only one system at the same time, and a lock mechanism between threads cannot be used at the time.

Redisson is a Java resident Memory Data Grid (In-Memory Data Grid) implemented on the basis of Redis. It not only provides a series of distributed Java common objects, but also implements re-entrant locks (REENTRANT LOCK), fair locks (fairlock), interlocks (Multi Lock), red locks (Red Lock), read-write locks (READ WRITE Lock), etc., and also provides many distributed services. Redisson provides the simplest and most convenient method of using Redis. Redisson is directed to facilitating separation of user attention to Redis (Separation of Concern), thereby enabling users to focus more on handling business logic.

The present application will be described in further detail with reference to the drawings and examples, in order to make the objects, technical solutions and advantages of the present application more apparent. It should be understood that the specific embodiments described herein are for purposes of illustration only and are not intended to limit the scope of the application. The application will be described in detail below with reference to the drawings and examples.

Example 1:

As shown in fig. 1, an embodiment of the present invention provides a dual token authorized refresh method based on dynamic expiration tolerance, which includes the following steps.

Step 100, modeling the dynamic expiration tolerance according to qps requests per second of the key API, response time Tresp of the key API and utilization ratio U of a database connection pool, wherein the smaller the qps, tresp and U are, the smaller the dynamic expiration tolerance is, and 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 time, and originally, after an access token carried by a certain request expires, direct access to a protected resource is not allowed, but after the dynamic expiration tolerance is set, if the expiration time of the access token carried by the request is smaller than the corresponding dynamic expiration tolerance time, then the grace is obtained, and access to the protected resource is permitted.

Step 200, for the first request with the expired access token and the unexpired refresh token, if the expired access token time length of the corresponding request is within the corresponding dynamic expiration tolerance, setting a distributed lock for the request, triggering a token refresh mechanism, and releasing the distributed lock after the token refresh mechanism is executed. It should be noted that, in the scenario discussed in this embodiment, the scenario is basically a scenario in which the access token expires and the refresh token is not expired, and in this scenario, the first request carrying the expired access token needs to trigger the token refresh mechanism to reacquire the new access token, and the subsequent request can be judged according to the dynamic expiration tolerance to see whether the access to the protected resource can be granted.

Step 300, 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 refresh mechanism is not triggered, and normal access is directly allowed. It should be noted that, for the subsequent request of the first request, in the case that the first request triggers the token refresh mechanism, in order to avoid repeatedly triggering the token refresh mechanism, as long as the access token expiration time in the subsequent request is less than the corresponding dynamic expiration tolerance time, access to the protected resource may be granted without triggering the token refresh mechanism again.

Based on the steps, the embodiment of the invention integrates the server performance indexes acquired in multiple dimensions such as qps requests per second of the key API, response time Tresp of the key API, utilization rate U of a database connection pool and the like by constructing the dynamic expiration tolerance and combining the performance indexes of multiple dimensions of the back-end server, innovatively models the dynamic expiration tolerance, optimizes the pain points and problems that the expiration tolerance time parameter in the patent CN112003852B is fixed, the static configuration is inflexible and the pain points and problems are not linked with the resource utilization and the refined load of the current server. Further, by introducing a distributed lock, all scene and category problems of expired exception requests are covered comprehensively.

In some embodiments, the 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 U of the database connection pool specifically includes:

defining a system busy rate:

wherein i represents index identification of the current user, alpha, beta and gamma represent coefficients, and Tresp _aver represents 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:

wherein tolerance_t_window (i, U, qps) is dynamically valued at [ t_min, t_max ].

Through the above arrangement, when qps, tresp and U are smaller, the system performance is better, more requests can be accommodated, the value in log approaches 0, the value in tolerance_t_window (i, U, qps) approaches t_min, that is, the dynamic expiration tolerance is smaller, and the physical meaning of resource utilization is met. When qps, tresp and U are larger, the system performance is poorer, fewer requests can be accommodated, the response and processing speed is reduced, the numerical value in log approaches to 1, the whole expression approaches to T_max, namely the larger the dynamic expiration tolerance is, the more time is given to the system for authorization fault tolerance, and the physical meaning of resource utilization is met.

Through the above arrangement, for each request, the specific value of the expiration tolerance can be dynamically set according to the system performance at the corresponding moment, and the pain points and problems that the expiration tolerance time parameter is fixed, the static configuration is inflexible, and the current server resource utilization and the refined load are not linked in the patent CN112003852B are optimized.

In some embodiments, the token refresh mechanism specifically comprises acquiring a new access token and a new refresh token, setting the current access token as the last failed access token, and setting the new access token as the current access token. That is, two pieces of information are kept for the access token, one is the current access token information and the other is the last time spent access token information, and each time the token refreshing mechanism is executed, a new access token is generated as the current access token, and the original access token is used as the last time spent access token. This is arranged to distinguish between subsequent different expiration scenarios.

In some embodiments, refresh rules are set for requests, and are executed by selecting corresponding refresh rules within a dynamic expiration tolerance through distributed lock states, access token states of requests, and expiration durations. By combining the three information of the distributed lock state, the requested access token state and whether the expiration duration is within the dynamic expiration tolerance, different expiration scenarios and different rules can be uniquely determined.

In some embodiments, when the distributed lock state is that the distributed lock can be obtained, the requested access token state is the current access token, and the expiration duration is within the dynamic expiration tolerance, a first refresh rule is selected for execution, wherein the first refresh rule comprises setting the distributed lock for the request, triggering a token refresh mechanism, and releasing the distributed lock after the token refresh mechanism is executed. The scene corresponding to the first refreshing rule is the first scene carrying the expiration request. I.e. the scenario corresponding to the first request in step 200 in which the access token expires and the refresh token has not expired.

In addition, for the first refreshing rule, if the expiration time of the first initiated request is not within the dynamic expiration tolerance, the corresponding physical meaning or typical scenario is that a certain page needing authorization is not updated for a long time (for example, 2 days), a series of network requests are initiated by clicking the page, but the token is expired and is too long in expiration, the system does not let any request carrying the expired token pass, the page is redirected to a login interface, a user is prompted to reenter information such as a user name, a password, a verification code and the like, login is re-authorized, and any request carrying the expired token does not pass, so that the authorization security of the system is ensured.

In some embodiments, when the distributed lock state is occupied, the requested access token state is the current access token, and the expiration duration is within the dynamic expiration tolerance, a second refresh rule is selected for execution, wherein the second refresh rule comprises that a token refresh mechanism is not triggered for the request, and normal access is directly allowed. The scene corresponding to the second rule is a scene that the following 2~n th carries an expiration request, and the time of the request reaching the server is within the occupied duration time of the distributed lock. Some of the subsequent requests to the first request in step 300 correspond to the scenario.

In some embodiments, when the distributed lock state is that the distributed lock can be obtained, the requested access token state is that the access token is invalid last time, and the expiration time is within the dynamic expiration tolerance, a third refresh rule is selected for execution, wherein the third refresh rule comprises that a token refresh mechanism is not triggered for the request, and normal access is directly allowed. The scenario corresponding to the third rule is the subsequent 2~n th scenario carrying an expiration request, and the time when the request arrives at the server is after the distributed lock is released. Some of the subsequent requests to the first request in step 300 correspond to the scenario.

In addition, if the expiration time of the request initiated by 2~n is not within the dynamic expiration tolerance for the second refresh rule and the third refresh rule, the probability is lower, if the corresponding physical meaning or typical scene is that the page just expires, but the 2~n th request initiated is possibly due to network delay or network failure, the request does not arrive in time, and the expiration tolerance is found when the request arrives, and two alternative processing methods exist at the moment. The method 1 is that the request with the expired token and the expired tolerance is redirected to a login interface, so that a user inputs a user name, a password and a verification code again, login is authorized again, any request carrying the expired token is not passed, and the security of the system is ensured. The method 2 is that the request with expired token and expired tolerance is not passed but redirected to the login page, because the 1 st request is successful, the 2 nd-n requests fail, the page data is missing or incomplete, when the user initiates the request next time, the client side has cached the 1 st updated valid token, the client side carries the valid token which is updated locally, and the target resource can be accessed after refreshing again.

In some embodiments, when the requested access token state is the current access token and is not expired, a fourth refresh rule is selected for execution, the fourth refresh rule comprising allowing normal access directly without further determination. After the token refreshing mechanism is executed and the distributed lock is released, the client acquires a new access token and carries a request scene sent by the new access token, and the token carried by the request at the moment is the new access token, namely the current access token, and the current access token is just acquired and not expired, so that normal access can be directly carried out.

In summary, the embodiment of the invention provides a dual token grant refresh method based on dynamic expiration tolerance, which is characterized in that on the technical innovation point, critical resources are protected, the dynamic expiration tolerance is constructed, the server performance indexes acquired in multiple dimensions such as qps requests per second of key APIs, response time Tresp of the key APIs and utilization rate U of a database connection pool are integrated by combining the performance indexes of multiple dimensions of a back-end server, the dynamic expiration tolerance is innovatively modeled, and the pain points and problems that the expiration tolerance time parameter is fixed, static configuration is inflexible and the current server resource utilization and refined load are not linked are optimized in patent CN 112003852B.

Further, at the service innovation point, all scene and category problems of the expired exception request are covered comprehensively by introducing the distributed locks.

On the basis of the method, the embodiment further provides a dual-token authorized refreshing system based on dynamic expiration tolerance, and referring to fig. 2, the system comprises 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 for modeling the dynamic expiration tolerance according to the number qps of requests per second of a key API, response time Tresp of the key API and utilization ratio U of a 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 for setting a distributed lock for the first request with the access token expired and refreshing the first request with the access token not expired, and simultaneously triggering a token refreshing mechanism, releasing the distributed lock after the token refreshing mechanism is executed, and the subsequent request processing module is used for triggering the corresponding access token directly within the corresponding dynamic expiration tolerance if the access token is not expired. The specific implementation flow of each module may refer to the above method steps, which are not described herein.

Example 2:

On the basis of the dual token authorized refresh method based on the dynamic expiration tolerance provided in the above embodiment 1, embodiment 2 of the present invention provides a specific example for illustration.

The above scheme is exemplified as follows:

Firstly, a user initiates a login request of a web end or a mobile end on a page, a user name password is input, and login is completed. The operation can enable the server to query the user information and judge whether the user data is legal user id and password, the user id is named as user_id, if the user_id and the password do not meet the check rule, the error is prompted, and the subsequent flow is terminated. If the user_id and the password meet the verification rule, the server side performs the following operations:

The method comprises the steps of calling a token generation module to generate token information, storing a part of the token information in a token database management module while generating the token information, and caching the part of the token information in a token cache module while generating the token information.

The above-mentioned cache frame belongs to common general knowledge, has mature open source implementation, and the corresponding open source frame names are ehcache, memcache, redis, etc. in order, and the implementation principle of each open source frame is not repeated here. The redis is taken as the main method of server-side caching in the embodiment, and other more advanced and efficient server-side caching strategies and algorithms are not in the discussion scope of the embodiment.

One possible engineering strategy for server-side caching in this embodiment is to use redis. the token cache module caches the user information and the token information to the redis, wherein the redis reads the key by using a user_id, the cached information acesstoken _info_cache can be read through the redis key (the user id is used here, namely the user_id), the cache information acesstoken _info_cache comprises, but is not limited to, a curr_token (i), a token of a current user i, namely a current access token in embodiment 1, a prev_token (i), a last token of the current user i, namely a last disabled access token in embodiment 1, and a refresh_lock (i), and the current user i concurrently refreshes the distributed lock.

And the server side returns data carrying the curr_token and user information to the client side, wherein the returned information comprises the curr_token, user personal service information (such as user name, user gender, user province and other additional information).

Then, the web client caches the curr_token information in the above steps in the page, carries the token information when requesting resources, opens a page, and triggers the client to request the protected resources. Carrying token information, wherein in engineering implementation, header information called authentication is generally carried in an http header;

A method carried by a user to send a url request is denoted by a curl, and can be described as follows:

the above-mentioned-H "Authorization: bearer xxxx" means that the carrying xxxx string is curr_token as the extra header of the request;

http:// myhost port/protect_resource_path1 represents url corresponding to the resource of the protected request;

We name url1=http:// myhost: port/protect_resource_path1;

we mark the above request as a request (curr_token, url 1);

the above-mentioned protected request resource url is typically a web service protected by oauth2, such as http:// myhost: port/protect_resource_path;

If the request is not carried with the curr_token as an extra head of the request, the request cannot be authenticated, and the request returns error information such as unauthorized passing.

In the whole stage of acquiring the resources by the page, if the requested curr_token is not expired, the steps can smoothly acquire the corresponding static resources and service interface information of the page, and the page is opened.

If the page acquires the resource, the curr_token reserved by the client cache is expired. The expiration of the curr_token is also divided into a number of cases, which are analyzed and processed as follows. It should be noted that when the page is opened in the above steps, there are a large number of concurrent requests instead of one request in a short time, and the following conventions are made in this embodiment:

there are N requests to open a certain page, named:

request(curr_token,url(1),t(1));

request(curr_token,url(2),t(2));

request(curr_token,url(3),t(3));

......

request(curr_token,urlN,t(N));

Meanwhile, assuming that t (1) <=t (2) <=t (3) & gt;

a similar t (i) represents the instant of initiation of the ith request;

Similar url (i) represents the url of the i-th request;

it is apparent that request (curr_token, url (1), t (1)) is the first request for a local page open event.

If the curr_token has expired, refreshtoken has expired at the time of request (curr_token, url (1), t (1)), the user interface is directly given feedback to the login page to re-login.

If the curr_token has expired at the time of request (curr_token, url (1), t (1)), refreshtoken has not expired, then the DTARADETDL algorithm in the resource authorization core algorithm module is executed. The distributed lock based dynamic expiration tolerance dual token grant refresh algorithm (Dual-Token Authorization Refresh Algorithm with Dynamic Expiration Tolerance Based on Distributed Locks, is abbreviated as DTARADETDL) is described in detail below.

When the curr_token expires, clicking on the page triggers 1-n concurrent transactions with expired tokens in a short period. The embodiment performs modeling optimization and algorithm design for the above scenario.

The fastest arriving 1 st business transaction carrying an expired token may utilize Redission distributed locks to ensure atomicity of token refresh operations, preventing collisions. The first invalidation request is determined by rule 1, which triggers a token refresh.

In this embodiment, after the first invalidation request of the user i is determined by rule 1, a distributed lock is created by using Redission, so that the token refresh, curr_token (i), and prev_token (i) cache data update are ensured to perform an atomic operation. And releasing the distributed lock after the update of the token refreshing, curr_token (i) and prev_token (i) cache data is finished.

Thus, for the current concurrent request, the distributed lock duration of user i is the [ T1, T2] interval in FIG. 3, defining the distributed lock resource as RedissionLock (i). Obviously, the system can distinguish the 1 st request (which triggers the token refresh transaction) and the remaining n-1 requests (which does not need to refresh the token) initiated by the current user by rule 1 (lock state, token state, expiration time determination comprehensive determination) in the rule determination table. The subsequent 2-n requests (refresh_st=1) do not do synchronous blocking, but compare the buffered double-token information, and obtain the given request time, namely the dynamic grace time of the expiration tolerance according to the modeling result of the token dynamic expiration tolerance_t_window (i) of the user i. The request carrying an expired token but meeting tolerance_t_window (e.g., 30 seconds for some result of the dynamic calculation) is passed (the analog band identity card examinee is allowed to enter by 30 seconds). The algorithm can accurately distinguish the 1 st and 2~n st requests and conduct differentiation processing, and verify that 2~n subsequently arrived requests carrying expired tokens within the tolerance_time_window (for example, 30 seconds within the expiration tolerance period) are allowed to use prev_token or curr_token, so that the refresh flow of refreshtoken is prevented from being repeatedly triggered due to 2-n service request failures.

The definition of the 1 st request and the subsequent 2-n requests can be divided into a number of scenarios, see fig. 3 and the rule decision table below for details. Wherein each rule may be uniquely determined by a combination of lock state + token state + expiration time equations. The rule determination table is as follows:

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.

The DTARADETDL algorithm uses a double token (token) as a processing strategy in a token refresh request concurrent competition stage, and by setting a certain expiration tolerance (namely, allowing the expiration request of the same userid to be released within a short time of token expiration, such as the rest 2~n requests in the example), the time of the token_t_window (i, U, qps) is generally shorter, the safety of the tolerance in the process of releasing the requirements is also ensured, and the aim of solving the refreshtoken repeated refresh problem in the refresh token concurrent competition state is fulfilled.

In the embodiment, the open page has N requests, which can be divided into three types of requests, specifically, a 1 st request (accesstoken, url (1), t (1)) initiated for the first time is recorded as a type A request, a 2 nd request (accesstoken, url (2), t (2)) -a j-th request (accesstoken, url (j), t (j)) total j-1 requests and recorded as a type B request, and the rest j+1th to N requests, wherein N- (j+1) +1=N-j requests are recorded as a type C request.

A class A request triggering event eventA is matched with legal curr_token (i) but is invalid, a first invalidation request is judged through a rule 1, a first invalidation request of a user i triggers token refreshing, a distributed lock is created by Redission after the first invalidation request of the user i is judged through the rule 1, atomic operation is guaranteed to be carried out on the update of cached data of the token refreshing, curr_token (i) and prev_token (i), and the distributed lock is released after the update of the cached data of the token refreshing, curr_token (i) and prev_token (i) is finished. Thus, for the current concurrent request, the distributed lock duration of user i is the [ T1, T2] interval in FIG. 3, defining the distributed lock resource as RedissionLock (i). Obviously, the system can distinguish the 1 st request (which triggers the token refresh transaction) and the remaining n-1 requests (which does not need to refresh the token) initiated by the current user by rule 1 (lock state, token state, expiration time determination comprehensive determination) in the rule determination table.

For class B requests, triggering event eventB, which may or may not match legal curr_token but legal prev_token, and meets rule 2 and rule 3 requirements, although curr_token or prev_token fails, normal requests may still be made, no re-updates accesstoken and refreshtoken are needed at this time, and normal access to the protected resources is allowed to be requested.

And triggering event eventC for the C-type request, wherein the request meets rule 4, the token is not invalid and is in a normal state, and the request is allowed to normally access the protected resource.

The problem that refreshtoken is repeatedly obtained in a large number in a concurrent competition state after the token expires is solved through DTARADETDL algorithm, and the class A request, the class B request and the class C request can be executed efficiently, correctly and without errors.

There are various ways to model the dynamic expiration tolerance tolerance_t_window in the DTARADETDL algorithm, and the dynamic grace time is used to model tolerance_t_window according to the innovation of the embodiment.

Specifically, qps (requests per second) of the key APIs, the response time Tresp of the key APIs, and the utilization U of the database connection pool are integrated. We can define a system busy rate:

The symbolic meaning, physical meaning, and modeling logic in the server system busyness rate formula are as follows:

the method can model the relation between the utilization rate of the database connection pool and the busyness of the system, smoothly map the linear growth of U to a nonlinear growth space, and reflect the characteristics that the system grows faster when the utilization rate of the connection pool is low and slows down when the utilization rate is close to saturation.

The inputs can be (0, 1) -normalized nonlinear mapped with a sigmod-like activation function.

Thus (2)The association between the utilization rate of the database connection pool and the busyness of the system can be modeled, the U is increased,Also increases, and the value range is at (0, 1).

The number of the cells to be processed is increased,Also increases;

Analysis Can be obtained from the first derivative of (2)Is an increasing function;

Thus following The number of the cells to be processed is increased,Also increases and the variation interval is (0, 1);

The correlation of qps (requests per second) of the API, the response time Tresp of the critical API, and the system busyness can be modeled.

Weighting the factors to make the busy contribution degree be 0.5;

the final system busy rate expression can be obtained as follows:

The more busy the system, the slower the number of requests per unit time of response, and the longer the dynamic grace expiration time is needed, we assume that the maximum tolerance that can be tolerated is T_max (e.g., 100 s) and the minimum tolerance is T_min (e.g., 10 s);

We map this to the following formula:

Obviously, when U, qps and Tresp values are smaller, the system performance is better, more requests can be accommodated, the value in log approaches 0, the value in tolerance_t_window (i, U, qps) approaches T_min, the physical meaning of resource utilization is met, when U, qps and Tresp values are larger, the system performance is poorer, fewer requests can be accommodated, the response and processing rate are reduced, the value in log approaches 1, the whole expression approaches T_max, the authorization fault tolerance is carried out for more time of the system, the physical meaning of resource utilization is met, and the whole tolerance_t_window (i, U, qps) is dynamically valued in [ T_min, T_max ].

It should be noted that, in the above formula, the variable i represents the index identifier of the current user, because the request received by the back end is from a different user i. The alpha represents the characteristic of whether the utilization rate U of the database connection pool is accelerated when approaching saturation, the specific value of alpha is taken as alpha=1.5 in the embodiment, and parameter adjustment can be carried out according to the actual effect of engineering or the historical data of the system. In this embodiment, when β selects a reasonable value, for example, 6, the nonlinear adjustment effect is more obvious, and only the value near the specific area (for example, 0.5) of the database connection pool fluctuates greatly, but the change rate of U is not obvious when the machine is small (idle) and the machine is close to 1 (busy), in this embodiment, β=6 is selected, and the specific value of β can be adjusted according to the engineering actual effect or the system history data. The method comprises the steps of controlling the variation amplitude and range of response time Tresp, enabling smaller gamma to show significant variation rate for Tresp in a wider range, enabling larger gamma to be saturated and slowly increased in the vicinity of slightly less than 1 when Tresp is larger and shows variation, and enabling specific numerical values of gamma=1 in the embodiment to be subjected to parameter adjustment according to engineering actual effects or system historical data. The Tresp _aver parameter indicates that for key transactions, statistics is carried out to obtain an average request response time, for example, for an authorized transaction API interface of a core, big data statistics is carried out, the response time is analyzed, data cleaning is carried out, analysis is carried out, finally abnormal values are removed to obtain Tresp _aver as 0.5 seconds, and the real Tresp _aver parameter needs to be obtained through statistical analysis according to system historical data.

In general, the embodiment of the invention provides a dual-token authorization refreshing method based on dynamic expiration tolerance, which aims at protecting critical resources on the technical innovation point, builds the dynamic expiration tolerance, integrates the server performance indexes acquired in multiple dimensions such as qps requests per second of key APIs, response time Tresp of the key APIs and utilization rate U of a database connection pool by combining the performance indexes of multiple dimensions of a back-end server, models the dynamic expiration tolerance innovatively, optimizes the pain points and problems that the expiration tolerance time parameter is fixed, static configuration is inflexible and does not link with the resource utilization and refined load of the current server in the patent CN 112003852B.

Further, at the service innovation point, all scene and category problems of the expired exception request are covered comprehensively by introducing the distributed locks.

Example 3:

On the basis of the dual token grant refresh method based on the dynamic expiration tolerance provided in the above embodiment 1, the present invention further provides a dual token grant refresh device based on the dynamic expiration tolerance, which can be used to implement the above method and system, as shown in fig. 4, and is a schematic diagram of a device architecture according to an embodiment of the present invention. The dual token authorized refresh device based on dynamic expiration tolerance of the present embodiment includes one or more processors 21 and a memory 22. In fig. 4, a processor 21 is taken as an example.

The processor 21 and the memory 22 may be connected by a bus or otherwise, for example in fig. 4.

The memory 22 serves as a non-volatile computer readable storage medium for storing non-volatile software programs, non-volatile computer executable programs and modules, such as the dual token authorized refresh method based on dynamic expiration tolerance in example 1. The processor 21 executes various functional applications and data processing of the dual token grant refresh device based on the dynamic expiration tolerance by running non-volatile software programs, instructions and modules stored in the memory 22, i.e., implements the dual token grant refresh method based on the dynamic expiration tolerance of embodiment 1.

The memory 22 may include high-speed random access memory, and may also include non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other non-volatile solid-state storage device. In some embodiments, memory 22 may optionally include memory located remotely from processor 21, which may 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.

The program instructions/modules are stored in the memory 22 and when executed by the one or more processors 21 perform the dual token grant refresh method based on dynamic expiration tolerance of embodiment 1 described above, for example, performing the steps shown in fig. 1 described above.

The product can execute the method provided by the embodiment of the application, and has the corresponding functional modules and beneficial effects of the execution method. Technical details not described in detail in this embodiment may be found in the methods provided in the embodiments of the present application.

It should be noted that the above-described apparatus embodiments are merely illustrative, and the units described as separate units may or may not be physically separate, and units shown as units may or may not be physical units, may be located in one place, or may be distributed over a plurality of 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.

From the above description of embodiments, it will be apparent to those skilled in the art that the embodiments may be implemented by means of software plus a general purpose hardware platform, or may be implemented by hardware. Those skilled in the art will appreciate that all or part of the processes implementing the methods of the above embodiments may be implemented by a computer program for instructing relevant hardware, where the program may be stored in a computer readable storage medium, and the program may include processes of the embodiments of the methods described above when executed. The storage medium may be a magnetic disk, an optical disk, a Read Only Memory (ROM), a random access Memory (Random Access Memory, RAM), or the like.

Finally, it should be noted that the above embodiments are only for illustrating the technical solution of the present invention, and not for limiting the same, that the technical features of the above embodiments or different embodiments may be combined in any order, and that many other variations in different aspects of the present invention as described above exist, which are not provided in details for the sake of brevity, and that although the present invention is described in the detailed description with reference to the foregoing embodiments, it should be understood by those skilled in the art that it may still make modifications to the technical solution described in the foregoing embodiments or make equivalent substitutions to some of the technical features thereof, and that these modifications or substitutions do not depart from the essence of the corresponding technical solution from the scope of the technical solution of the embodiments of the present invention.

Claims (10)

1. A dual-token authorized refreshing method based on dynamic expiration tolerance is characterized by comprising the following steps:

Modeling the dynamic expiration tolerance according to the request per second qps of the key API, the response time Tresp of the key API and the utilization rate U of a database connection pool, wherein the smaller the qps, the Tresp and the U are, the smaller the dynamic expiration tolerance is, and the larger the qps, the Tresp and the U are;

For a first request with an expired access token and a non-expired refresh token, if the expiration time 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, and releasing the distributed lock after the token refresh mechanism is executed;

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.

2. The dual token grant refresh method based on dynamic expiration tolerance of claim 1, wherein 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 U of the database connection pool specifically comprises:

defining a system busy rate:

Wherein i represents index identification of the current user, alpha, beta and gamma are coefficients, and Tresp _aver represents 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:

wherein tolerance_t_window (i, U, qps) is dynamically valued at [ t_min, t_max ].

3. The dual token authorized refresh method based on dynamic expiration tolerance of claim 1, wherein the token refresh mechanism specifically comprises:

acquiring a new access token and a new refresh token;

setting the current access token as the last invalid access token;

the new access token is set to the current access token.

4. The dual token authorized refresh method based on dynamic expiration tolerance according to claim 3, wherein refresh rules are set for requests, and corresponding refresh rules are selected for execution by whether the distributed lock state, the requested access token state, and the expiration duration are within the dynamic expiration tolerance;

when the distributed lock state is that the distributed lock can be acquired, the requested access token state is the current access token, the expiration time is within the dynamic expiration tolerance, a first refreshing rule is selected for execution, and the first refreshing rule comprises setting the distributed lock for the request, triggering a token refreshing mechanism, and releasing the distributed lock after the token refreshing mechanism is executed.

5. The method for dual token authorized refresh based on dynamic expiration tolerance of claim 4, wherein when the distributed lock state is occupied, the requested access token state is the current access token, and the expiration duration is within the dynamic expiration tolerance, a second refresh rule is selected for execution, wherein the second refresh rule comprises not triggering a token refresh mechanism for the request and directly allowing normal access.

6. The method for dual token authorized refresh based on dynamic expiration tolerance according to claim 4, wherein when the state of the distributed lock is that the distributed lock can be obtained, the state of the requested access token is that the last time the access token is disabled, and the expiration time is within the dynamic expiration tolerance, a third refresh rule is selected for execution, and the third refresh rule comprises that the token refresh mechanism is not triggered for the request, and normal access is directly allowed.

7. The method for dual token authorized refresh based on dynamic expiration tolerance of claim 4, wherein when the requested access token status is current and not expired, a fourth refresh rule is selected for execution, the fourth refresh rule comprising directly allowing normal access without further determination.

8. A dual token authorized refresh device based on dynamic expiration tolerance, comprising at least one processor, and a memory communicatively coupled to the at least one processor, wherein the memory stores instructions executable by the at least one processor for executing the dual token authorized refresh method based on dynamic expiration tolerance of any one of claims 1-7.

9. A dual token grant refresh system based on dynamic expiration tolerance applying the dual token grant refresh method based on dynamic expiration tolerance according to any one of claims 1 to 7, wherein the system comprises 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 for modeling the dynamic expiration tolerance according to the number of requests per second of the key API qps, the response time Tresp of the key API and the utilization rate U of a database connection pool, wherein the smaller the qps, the Tresp and the U are, the smaller the dynamic expiration tolerance is, and the larger the qps, the Tresp and the U are;

The first request processing module is used for setting a distributed lock for a first request with an expired access token and an unexpired refresh token if the expired access token time length of the corresponding request is within the corresponding dynamic expiration tolerance, triggering a token refresh mechanism, and releasing the distributed lock after the token refresh mechanism is executed;

The subsequent request processing module is used for directly allowing normal access to the subsequent request of the first request if the expiration duration of the access token of the corresponding request is within the corresponding dynamic expiration tolerance without triggering a token refreshing mechanism.

10. A non-transitory computer storage medium storing computer-executable instructions for execution by one or more processors to perform the dynamic expiration tolerance-based dual token grant refresh method of any one of claims 1-7.