A method and system for processing repeated refresh tokens

Abstract

The present invention provides a processing method and system for repeatedly refreshing tokens, by sending multiple resource requests with access tokens to a server; receiving a status code fed back by the server, the status code being generated according to a flag bit of the access token corresponding to the first sequential resource request in the multiple resource requests; judging whether to enable a network request interceptor to intercept subsequent resource requests with the access token according to the status code; after enabling the network request interceptor, judging whether the access token is consistent with a locally cached access token; if they are consistent, sending a refresh token to the server, receiving a new refresh token and a new access token generated according to the refresh token fed back by the server, and storing them in a local cache. The method solves the problem that when there are multiple access requests, repeated refreshing of tokens wastes the request resources and processing time of the interface, and reduces the request authorization efficiency of the terminal and the server.

Description

Technical Field

[0001] The invention proposes a processing method and system for repeatedly refreshing tokens, belonging to the field of Internet security. Background Art

[0002] In order to avoid frequent user logins that affect the user experience during terminal use, users are usually not required to log in again for a long time after logging in once. In order to maintain the AccessToken information corresponding to the user's login status, the terminal usually uses the AccessToken automatic renewal method to extend the validity period of the AccessToken information.

[0003] Most terminals follow the OAuth2 protocol for user login and AccessToken renewal. Although the details of each terminal are different and may even be extended based on the OAuth2 protocol, the process is generally the same. The main process in the OAuth2 protocol is that after the user successfully logs in, he accesses the OAuth2 authorization server to obtain the AccessToken and RefreshToken, and then uses the AccessToken to access restricted resources. The role of RefreshToken is that when the server returns that the AccessToken is expired when accessing resources through the AccessToken, the refreshed AccessToken and RefreshToken can be obtained from the OAuth2 authorization server through the RefreshToken, so that the authorized resources can be accessed normally next time. At this time, if there are multiple requests to access the authorized resources at the same time and the AccessToken is expired, multiple requests to refresh the token based on the RefreshToken will be triggered, and only the first request to refresh the RefreshToken will succeed, and the remaining requests will fail because the RefreshToken has been refreshed. This situation wastes the request resources and processing time of the interface, thereby reducing the request authorization efficiency between the terminal and the OAuth2 authorization server.

[0004] Therefore, the present invention provides a method for processing repeated refresh tokens, an electronic device and a storage medium, which are used to solve the problem that repeated refresh tokens waste interface request resources and processing time, and reduce the request authorization efficiency of the terminal and the server. Summary of the invention

[0005] In view of this, in order to solve the problem of repeatedly refreshing tokens, wasting interface request resources and processing time, and reducing the request authorization efficiency of the terminal and the server.

[0006] The present invention provides a method for processing repeated refresh tokens, which is applied to a terminal and includes:

[0007] Send multiple resource requests with access tokens to the server;

[0008] Receive a status code fed back by the server, where the status code is generated according to a flag bit of an access token corresponding to a first sequential resource request among the multiple resource requests;

[0009] Determine whether to enable the network request interceptor based on the status code to intercept subsequent resource requests with access tokens;

[0010] After the network request interceptor is turned on, determine whether the access token is consistent with the locally cached access token; if they are consistent, send a refresh token to the server, and receive a new refresh token and a new access token generated based on the refresh token from the server, and store them in the local cache.

[0011] In some possible implementations, a method for processing repeated refresh tokens, applied on the server side, includes:

[0012] The server receives multiple resource requests with access tokens;

[0013] The server determines the flag bit of the access token according to the issuance time of the access token carried in the first resource request, the current time and the validity period of the access token;

[0014] The server generates a status code according to the flag bit and feeds it back to the terminal.

[0015] In some possible implementations, the method is applied to the server side, and the flag bit of the access token is determined according to the issuance time of the access token carried by the first resource request, the current time, and the validity period of the access token, including:

[0016] The server determines whether the access token has expired based on the issuance time of the access token carried in the first resource request, the current time, and the validity period of the access token;

[0017] When the access token expires, an "invalid" flag is given to the access token;

[0018] When the access token is not expired, a "valid" flag is given to the access token.

[0019] In some possible implementations, the method is applied to a server, where the server generates a status code according to the flag bit and feeds it back to the terminal, including:

[0020] When the flag bit of the access token is "invalid", the server feeds back an invalid status code to the terminal;

[0021] When the flag bit of the access token is "valid", the server feeds back a valid status code to the terminal.

[0022] In some possible implementations, the server is applied to determine whether to enable a network request interceptor based on the status code to intercept subsequent resource requests with access tokens, including:

[0023] When the status code is a valid status code, the network request interceptor is not enabled;

[0024] Enable the network request interceptor when the status code is an invalid status code.

[0025] In some possible implementations, the terminal is applied to, after the network request interceptor is turned on, determine whether the access token is consistent with the locally cached access token; if they are consistent, send a refresh token to the server, and receive a new refresh token and a new access token generated according to the refresh token fed back by the server, and store them in the local cache, including:

[0026] When the access token is consistent with the access token in the local cache, a refresh token is sent to the server. When the refresh token is valid, the terminal receives a new access token and a new refresh token sent by the server and stores them in the local cache. The terminal closes the network request interceptor and compares the access token in subsequent resource requests with the new access token in the local cache of the terminal.

[0027] When the refresh token expires, the terminal jumps to the login page.

[0028] In some possible implementations, when the refresh token is valid, the terminal receives a new access token and a new refresh token sent by the server and stores them in a local cache. The terminal closes the network request interceptor and compares the access token in subsequent resource requests with the new access token in the local cache of the terminal, including:

[0029] When the refresh token is valid, the terminal receives the new access token and the new refresh token sent by the server and stores them in the local cache. The terminal closes the network request interceptor and compares the access token in the subsequent resource request with the new access token in the local cache of the terminal. When the access token in the subsequent resource request is inconsistent with the access token in the local cache, the access token in the subsequent resource request is updated to the new access token based on the local cache of the terminal and resent to the server.

[0030] When the access token in the subsequent resource request is consistent with the new access token in the local cache, the terminal initiates sending a refresh token to the server, and obtains a new refresh token and a new access token stored in the local cache of the terminal.

[0031] In some possible implementations, applied to a terminal, when the access token in a subsequent resource request is consistent with the new access token in the local cache, the terminal initiates sending a refresh token to the server, and obtains a new refresh token and a new access token stored in the local cache of the terminal, including:

[0032] When the access tokens are inconsistent, the access tokens in subsequent resource requests are updated to new access tokens based on the local cache of the terminal, and resource requests carrying the new access tokens are resent to the server.

[0033] The receiving server responds to the resource request with the new access token.

[0034] In some possible implementations, the network request interceptor is not enabled when the status code is a valid status code, including:

[0035] When the status code is a valid status code, the network request interceptor is not enabled, and subsequent resource requests carrying access tokens are sent to the server.

[0036] Receive resource requests from the server.

[0037] On the other hand, the present invention also provides a system for processing repeated refresh tokens, comprising: a terminal and a server;

[0038] The terminal is used to send multiple resource requests with access tokens to the server;

[0039] Receive a status code fed back by the server, where the status code is generated according to a flag bit of an access token corresponding to a first sequential resource request among the multiple resource requests;

[0040] Determine whether to enable the network request interceptor based on the status code to intercept subsequent resource requests with access tokens;

[0041] After the network request interceptor is turned on, determine whether the access token is consistent with the locally cached access token; if they are consistent, send a refresh token to the server, receive a new refresh token and a new access token generated based on the refresh token from the server, and store them in the local cache;

[0042] The server is used to receive multiple resource requests with access tokens;

[0043] Determine the flag bit of the access token according to the issuance time of the access token carried by the first resource request, the current time and the validity period of the access token;

[0044] A status code is generated according to the flag bit and fed back to the terminal.

[0045] Compared with the prior art, the beneficial effects of the present invention include: sending multiple resource requests with access tokens to the server side; receiving a status code fed back by the server side, the status code being generated according to the flag bit of the access token corresponding to the first sequential resource request in the multiple resource requests; judging whether to enable a network request interceptor to intercept subsequent resource requests with access tokens according to the status code; after enabling the network request interceptor, judging whether the access token is consistent with the locally cached access token; if they are consistent, sending a refresh token to the server side, receiving a new refresh token and a new access token generated according to the refresh token fed back by the server side, and storing them in the local cache. This solves the problem of wasting interface request resources and processing time when multiple access requests are made and reducing the request authorization efficiency of the terminal and the server side. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] Figure 1 A flowchart of an embodiment of a method for repeatedly refreshing a token provided by the present invention applied to a terminal;

[0047] Figure 2 A flowchart of an embodiment of a method for repeatedly refreshing a token provided by the present invention and applied to a server side;

[0048] Figure 3 A schematic structural diagram of an embodiment of a system for processing repeated refresh tokens provided by the present invention. DETAILED DESCRIPTION

[0049] The technical solutions in the embodiments of the present invention will be described clearly and completely below in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present invention.

[0050] It should be understood that the schematic drawings are not drawn to scale. The flow chart used in the present invention shows the operations implemented according to some embodiments of the present invention. It should be understood that the operations of the flow chart can be implemented out of order, and the steps without logical context can be reversed or implemented simultaneously. In addition, those skilled in the art can add one or more other operations to the flow chart under the guidance of the content of the present invention, and can also remove one or more operations from the flow chart.

[0051] Some of the block diagrams shown in the accompanying drawings are functional entities that do not necessarily correspond to physically or logically independent entities. These functional entities can be implemented in software form, or in one or more hardware modules or integrated circuits, or in different networks and / or processor systems and / or microcontroller systems.

[0052] Reference to an "embodiment" herein means that a particular feature, structure, or characteristic described in conjunction with the embodiment may be included in at least one embodiment of the present invention. The appearance of the phrase in various places in the specification does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment that is mutually exclusive with other embodiments. It is explicitly and implicitly understood by those skilled in the art that the embodiments described herein may be combined with other embodiments.

[0053] The embodiments of the present invention provide a method for processing repeated refresh tokens, which is described below.

[0054] Figure 1 A flowchart of an embodiment of a method for repeatedly refreshing a token provided by the present invention applied to a terminal includes the following steps:

[0055] S101, sending multiple resource requests with access tokens to the server;

[0056] S102, receiving a status code fed back by the server, where the status code is generated according to a flag bit of an access token corresponding to a first sequential resource request among the multiple resource requests;

[0057] S103, judging whether to enable a network request interceptor according to the status code to intercept subsequent resource requests with access tokens;

[0058] S104. After the network request interceptor is turned on, determine whether the access token is consistent with the locally cached access token; if they are consistent, send a refresh token to the server, receive a new refresh token and a new access token generated based on the refresh token from the server, and store them in the local cache.

[0059] In a specific embodiment, after determining not to enable the network request interceptor according to the status code, the terminal normally sends a resource request with an access token to the server.

[0060] It should be noted that AccessToken is a globally unique ID that marks the user's login status. For example, after user A successfully logs in, the server will generate an AccessToken for user A. The server will also record the generation time and validity period of AccessToken. After receiving AccessToken, the client will save it in the local cache.

[0061] It is further necessary to explain that the refresh token (RefreshToken) is used to request the OAuth2 authorization server to obtain a new AccessToken when the AccessToken expires. The validity period of the RefreshToken is generally longer than the validity period of the AccessToken.

[0062] Compared with the prior art, the present invention sends multiple resource requests with access tokens to the server;

[0063] Receive the status code fed back by the server, the status code is generated according to the flag bit of the access token corresponding to the first sequential resource request among the multiple resource requests; determine whether to enable the network request interceptor to intercept subsequent resource requests with the access token according to the status code; after enabling the network request interceptor, determine whether the access token is consistent with the locally cached access token; if they are consistent, send a refresh token to the server, receive the new refresh token and new access token generated according to the refresh token fed back by the server, and store them in the local cache. This solves the problem of wasting interface request resources and processing time when multiple access requests are made, and reduces the request authorization efficiency of the terminal and the server.

[0064] In the embodiment of the present invention, Figure 2 , Figure 2 A flowchart of an embodiment of a method for repeatedly refreshing a token provided by the present invention and applying the server side includes the following steps:

[0065] S201, the server receives multiple resource requests with access tokens;

[0066] S202: The server determines the flag of the access token according to the issuance time of the access token carried in the first resource request, the current time, and the validity period of the access token;

[0067] S203: The server generates a status code according to the flag bit and feeds it back to the terminal.

[0068] In an embodiment of the present invention, applied to the server side, judging the flag bit of the access token according to the issuance time of the access token carried by the first resource request, the current time and the validity time of the access token includes:

[0069] The server determines whether the access token has expired based on the issuance time of the access token carried in the first resource request, the current time, and the validity period of the access token;

[0070] When the access token expires, an "invalid" flag is given to the access token;

[0071] When the access token is not expired, a "valid" flag is given to the access token.

[0072] In an embodiment of the present invention, the method is applied to a server side, and generates a status code according to the flag bit and feeds it back to the terminal, including:

[0073] When the flag bit of the access token is "invalid", the server feeds back an invalid status code to the terminal;

[0074] When the flag bit of the access token is "valid", the server feeds back a valid status code to the terminal.

[0075] In an embodiment of the present invention, the server is applied to determine whether to enable a network request interceptor according to the status code to intercept subsequent resource requests with access tokens, including:

[0076] When the status code is a valid status code, the network request interceptor is not enabled;

[0077] Enable the network request interceptor when the status code is an invalid status code.

[0078] In a specific embodiment, when the status code is invalid, the network request interceptor is opened, and the global lock in the network request interceptor is immediately opened to restrict the subsequent requests from continuing to execute. Since the subsequent resource request holds the lock, the subsequent resource request will wait in this step until the first resource request information requests to release the global lock.

[0079] It should be noted that the global lock is a synchronization mechanism used to implement mutually exclusive access to shared resources by multiple threads.

[0080] In an embodiment of the present invention, the terminal is applied to determine whether the access token is consistent with the local cache access token after the network request interceptor is turned on; if they are consistent, a refresh token is sent to the server, and a new refresh token and a new access token generated according to the refresh token are received from the server, and stored in the local cache, including:

[0081] When the access token is consistent with the access token in the local cache, a refresh token is sent to the server. When the refresh token is valid, the terminal receives a new access token and a new refresh token sent by the server and stores them in the local cache. The terminal closes the network request interceptor and compares the access token in subsequent resource requests with the new access token in the local cache of the terminal.

[0082] When the refresh token expires, the terminal jumps to the login page.

[0083] In a specific embodiment, when the terminal determines whether the first access token is consistent with the access token cached locally in the terminal, if they are consistent, the terminal initiates sending a refresh token to the server, and the terminal obtains the RefreshToken stored in the local cache, and initiates a refresh token request to the OAuth2 authorization server with the RefreshToken. If the OAuth2 authorization server returns a new AccessToken and RefreshToken normally.

[0084] If the refresh token is invalid, that is, the OAuth2 authorization server fails to authorize, the terminal jumps to the login page.

[0085] It should be noted that the OAuth2 protocol: The OAuth2 (Open Authorization) protocol is an open standard that allows users to allow third-party applications to access private resources stored by the user on a website (such as photos, videos, contact lists) without providing the username and password to the third-party application's authorization protocol.

[0086] OAuth2 authorization server: The OAuth2 authorization server refers to the server that provides authentication and authorization services to clients that follow the OAuth2 protocol.

[0087] In the embodiment of the present invention, when the refresh token is valid, the terminal receives a new access token and a new refresh token sent by the server and stores them in a local cache. The terminal closes the network request interceptor and compares the access token in the subsequent resource request with the new access token in the local cache of the terminal, including:

[0088] When the refresh token is valid, the terminal receives the new access token and the new refresh token sent by the server and stores them in the local cache. The terminal closes the network request interceptor and compares the access token in the subsequent resource request with the new access token in the local cache of the terminal. When the access token in the subsequent resource request is inconsistent with the access token in the local cache, the access token in the subsequent resource request is updated to the new access token based on the local cache of the terminal and resent to the server.

[0089] When the access token in the subsequent resource request is consistent with the new access token in the local cache, the terminal initiates sending a refresh token to the server, and obtains a new refresh token and a new access token stored in the local cache of the terminal.

[0090] In an embodiment of the present invention, applied to a terminal, when the access token in a subsequent resource request is consistent with the new access token in the local cache, the terminal initiates sending a refresh token to the server, and obtains a new refresh token and a new access token stored in the local cache of the terminal, including:

[0091] When the access tokens are inconsistent, the access tokens in subsequent resource requests are updated to new access tokens based on the local cache of the terminal, and resource requests carrying the new access tokens are resent to the server.

[0092] The receiving server responds to the resource request with the new access token.

[0093] In an embodiment of the present invention, when the status code is a valid status code, the network request interceptor is not enabled, including:

[0094] When the status code is a valid status code, the network request interceptor is not enabled, and subsequent resource requests carrying access tokens are sent to the server.

[0095] Receive resource requests from the server.

[0096] The embodiment of the present invention also provides a processing system 400 for repeatedly refreshing tokens, such as Figure 3 , Figure 3 A schematic diagram of the structure of an embodiment of a system for processing repeated refresh tokens provided by the present invention, comprising: a terminal 401 and a server 402;

[0097] The terminal 401 is used to send multiple resource requests with access tokens to the server side 402; receive a status code fed back by the server side 402, the status code being generated based on a flag bit of the access token corresponding to the first sequential resource request among the multiple resource requests; determine, based on the status code, whether to enable a network request interceptor to intercept subsequent resource requests with the access token; after enabling the network request interceptor, determine whether the access token is consistent with a locally cached access token; if they are consistent, send a refresh token to the server side 402, receive a new refresh token and a new access token generated based on the refresh token fed back by the server side 402, and store them in a local cache.

[0098] The server end 402 is used to receive multiple resource requests with access tokens; determine the flag of the access token according to the issuance time of the access token carried by the first resource request, the current time and the validity period of the access token; and generate a status code based on the flag and feed it back to the terminal.

[0099] The present invention sends multiple resource requests with access tokens to the server side; receives a status code fed back by the server side, the status code is generated according to the flag bit of the access token corresponding to the first sequential resource request in the multiple resource requests; determines whether to enable a network request interceptor to intercept subsequent resource requests with access tokens according to the status code; after enabling the network request interceptor, determines whether the access token is consistent with the local cache access token; if they are consistent, sends a refresh token to the server side, receives a new refresh token and a new access token generated according to the refresh token fed back by the server side, and stores them in the local cache. The problem of repeatedly refreshing the token when multiple access requests are made is solved, which wastes the request resources and processing time of the interface and reduces the request authorization efficiency of the terminal and the server side.

[0100] The above is a detailed introduction to the processing method and system for repeatedly refreshing tokens provided by the present invention. Specific examples are used in this article to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only used to help understand the method of the present invention and its core idea; at the same time, for technical personnel in this field, according to the idea of ​​the present invention, there will be changes in the specific implementation method and application scope. The above is only a preferred specific implementation method of the present invention, but the protection scope of the present invention is not limited to this. Any changes or replacements that can be easily thought of by any technical personnel familiar with the technical field within the technical scope disclosed by the present invention should be covered within the protection scope of the present invention.

Claims

1. A method for repeatedly refreshing a token, applied to a terminal, characterized in that: include: Send multiple resource requests with access tokens to the server; Receive a status code fed back by the server, where the status code is generated according to a flag bit of an access token corresponding to a first sequential resource request among the multiple resource requests; Determine whether to enable the network request interceptor based on the status code to intercept subsequent resource requests with access tokens; After the network request interceptor is enabled, determine whether the access token is consistent with the locally cached access token; If they are consistent, the refresh token is sent to the server, and a new refresh token and a new access token generated according to the refresh token are received and stored in the local cache.

2. A method for processing repeated refresh tokens according to claim 1, applied to a server, characterized in that: include: Receive multiple resource requests with access tokens; Determine the flag bit of the access token according to the issuance time of the access token carried by the first resource request, the current time and the validity period of the access token; A status code is generated according to the flag bit and fed back to the terminal.

3. A method for processing repeated refresh tokens according to claim 2, applied to a server, characterized in that: The flag bit of the access token is determined according to the issuing time of the access token carried by the first resource request, the current time and the valid time of the access token, including: Determine whether the access token is expired based on the issuance time of the access token carried in the first resource request, the current time, and the validity period of the access token; When the access token expires, an "invalid" flag is given to the access token; When the access token is not expired, a "valid" flag is given to the access token.

4. A method for processing repeated refresh tokens according to claim 2, applied to a server, characterized in that: Generating a status code according to the flag bit and feeding it back to the terminal includes: When the flag bit of the access token is "invalid", the server feeds back an invalid status code to the terminal; When the flag bit of the access token is "valid", the server feeds back a valid status code to the terminal.

5. A method for processing repeated refresh tokens according to claim 1, applied to a server, characterized in that: Determine whether to enable the network request interceptor based on the status code to intercept subsequent resource requests with access tokens, including: When the status code is a valid status code, the network request interceptor is not enabled; Enable the network request interceptor when the status code is an invalid status code.

6. A method for processing repeated refresh tokens according to claim 1, applied to a terminal, characterized in that: After the network request interceptor is enabled, determine whether the access token is consistent with the locally cached access token; If they are consistent, the refresh token is sent to the server, and a new refresh token and a new access token generated according to the refresh token are received from the server, and stored in the local cache, including: When the access token is consistent with the access token in the local cache, a refresh token is sent to the server. When the refresh token is valid, a new access token and a new refresh token sent by the server are received and stored in the local cache. The terminal closes the network request interceptor and compares the access token in subsequent resource requests with the new access token in the local cache of the terminal. When the refresh token expires, the terminal jumps to the login page.

7. A method for processing repeated refresh tokens according to claim 6, applied to a terminal, characterized in that: When the refresh token is valid, the new access token and the new refresh token sent by the server are received and stored in the local cache. The terminal closes the network request interceptor and compares the access token in subsequent resource requests with the new access token in the terminal's local cache, including: When the refresh token is valid, the new access token and the new refresh token sent by the server are received and stored in the local cache. The network request interceptor is closed, and the access token in the subsequent resource request is compared with the new access token in the local cache. When the access token in the subsequent resource request is inconsistent with the access token in the local cache, the access token in the subsequent resource request is updated to the new access token based on the local cache and resent to the server. When the access token in the subsequent resource request is consistent with the new access token in the local cache, a refresh token is sent to the server, and a new refresh token and a new access token are obtained and stored in the local cache of the terminal.

8. A method for processing repeated refresh tokens according to claim 7, applied to a terminal, characterized in that: When the access token in the subsequent resource request is consistent with the new access token in the local cache, the client sends a refresh token to the server and obtains a new refresh token and a new access token stored in the local cache of the terminal, including: When the access token is inconsistent, the access token in the subsequent resource request is updated to a new access token based on the local cache, and the resource request carrying the new access token is resent to the server; The receiving server responds to the resource request with the new access token.

9. A method for processing repeated refresh tokens according to claim 5, characterized in that: Applied to the terminal, when the status code is a valid status code, the network request interceptor is not enabled, including: When the status code is a valid status code, the network request interceptor is not enabled, and subsequent resource requests carrying access tokens are sent to the server. Receive resource requests from the server.

10. A system for processing repeated refresh tokens, characterized in that: Including server and terminal: The terminal is used to send multiple resource requests with access tokens to the server; Receive a status code fed back by the server, where the status code is generated according to a flag bit of an access token corresponding to a first sequential resource request among the multiple resource requests; Determine whether to enable the network request interceptor based on the status code to intercept subsequent resource requests with access tokens; After the network request interceptor is enabled, determine whether the access token is consistent with the locally cached access token; If they are consistent, a refresh token is sent to the server, and a new refresh token and a new access token generated according to the refresh token are received from the server, and stored in a local cache; The server is used to receive multiple resource requests with access tokens; Determine the flag bit of the access token according to the issuance time of the access token carried by the first resource request, the current time and the validity period of the access token; A status code is generated according to the flag bit and fed back to the terminal.

Images