Token management method, device, system, equipment, storage medium and program product

The token management system addresses resource access issues in distributed systems by implementing client-side and server-side verification, enhancing access efficiency and stability through secure token management.

CN115396119BActive Publication Date: 2024-12-24CCB FINTECH CO LTD
View PDF 6 Cites 0 Cited by

Patent Information

Application Number
CN202211052968.X
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2022-08-31
Publication Date
2024-12-24
Estimated Expiration
2042-08-31

AI Technical Summary

Technical Problem

Existing distributed systems face issues with resource confusion, process damage, and excessive contention due to uncontrolled access to shared resources, which can lead to system instability and performance degradation.

Method used

A token management system that employs client-side and server-side signature verification methods to control access to shared resources, utilizing a local token pool and a server-managed available token pool to manage and verify tokens, ensuring secure and efficient resource access.

Benefits of technology

Enhances resource access efficiency, improves system performance and stability by effectively controlling access operations and reducing server load through secure token verification and management.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN115396119B_ABST
    Figure CN115396119B_ABST
Patent Text Reader

Abstract

The present invention relates to the field of access control technology, and specifically to a token management method, device, system, equipment, storage medium and program product, wherein the method is applied to a client, and the method comprises: when an operation request for a target resource is detected, obtaining a token corresponding to the operation request, wherein the target resource is a shared resource of a distributed system, and the token comprises a signature verification rule, wherein the signature verification rule comprises a signature verification method for verifying the token; parsing the token to determine the signature verification method of the token, wherein the signature verification method is one of client signature verification and server signature verification; verifying the token based on the signature verification method, and responding to the operation request according to the signature verification result. The method provided by the present invention can not only realize secure access to resources, but also improve the token verification efficiency by adopting different signature verification methods for different types of tokens, thereby improving the resource access efficiency of the entire system.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention relates to the field of access control technology, and in particular to a token management method, device, system, equipment, storage medium and program product. Background Art

[0002] A distributed system is built on a network basis. It is a system composed of multiple independent nodes that are geographically and physically dispersed. The multiple nodes are connected together to achieve sharing of different resources. A distributed system is equivalent to a unified whole.

[0003] For distributed systems, multiple nodes in the system are running in parallel. At the same time, multiple nodes or multiple processes on the same node may initiate access to the same shared resource. If it is not controlled, it may cause abnormal conditions such as resource confusion and process damage. In addition, when the number of concurrent accesses to the same shared resource is too high, it may also cause excessive resource contention or system avalanche, seriously affecting the stable operation of the system. Therefore, it is necessary to reasonably control the access of distributed systems to shared resources and limit the amount of resource access to ensure the normal operation of distributed systems.

[0004] At present, locks are a common means of implementing access control. Distributed locks are a way to control the access of distributed systems to shared resources. Commonly used implementations include redis and zookeeper. Redis implements synchronous access control to shared resources by judging the existence of key-value pairs, and zookeeper implements synchronous access control to shared resources by judging the viability of document nodes. However, the above implementations can only provide a single lock and can only implement synchronous access control to resources. The system also needs to implement complex lock management. If the lock is lost, the system will be unable to access resources. Summary of the invention

[0005] In view of the above-mentioned problems in the prior art, the object of the present invention is to provide a token management method, apparatus, system, device, storage medium and program product, which can realize secure access to resources and improve the resource access efficiency of the system.

[0006] In order to solve the above problems, the present invention provides a token management method, which is applied to a client, and the method comprises:

[0007] When an operation request for a target resource is detected, a token corresponding to the operation request is obtained, wherein the target resource is a shared resource of a distributed system, and the token includes a signature verification rule, wherein the signature verification rule includes a signature verification method for verifying the token;

[0008] Parse the token to determine a verification method for the token, where the verification method is one of client verification and server verification;

[0009] The token is verified based on the verification method, and the operation request is responded to according to the verification result.

[0010] Further, when an operation request for a target resource is detected, obtaining a token corresponding to the operation request includes:

[0011] When an operation request for a target resource is detected, a token corresponding to the operation request is obtained;

[0012] or,

[0013] When an operation request for a target resource sent by another client is detected, a token carried in the operation request is obtained.

[0014] Further, verifying the token based on the signature verification method and responding to the operation request according to the signature verification result includes:

[0015] When the signature verification mode is client-side signature verification, a signature verification operation is performed on the token to obtain a signature verification result; when the signature verification result is that the signature verification is passed, the operation requested by the operation request is allowed to be executed;

[0016] When the signature verification method is server-side signature verification, the token is sent to the server so that the server performs a signature verification operation on the token, obtains and returns a signature verification result; the signature verification result sent by the server is received, and when the signature verification result is passed, the operation requested by the operation request is allowed to be executed.

[0017] Furthermore, the method further comprises:

[0018] When an operation request for a target resource needs to be initiated, a token is applied for the operation request.

[0019] Further, applying for a token for the operation request includes:

[0020] Determine whether a token of a type corresponding to the operation request is stored in a local token pool;

[0021] When a token of a type corresponding to the operation request is stored in the local token pool, taking the token from the local token pool;

[0022] When the local token pool does not store a token of the type corresponding to the operation request, sending a token acquisition request to the server, where the token acquisition request corresponds to the operation request;

[0023] Receiving a token sent by the server, where the token is a token of a type corresponding to the operation request issued by the server from an available token pool in response to the token acquisition request;

[0024] The available token pool stores at least one token of a type corresponding to the operation request.

[0025] Furthermore, the method further comprises:

[0026] Sending heartbeat data to the server at every first preset time interval;

[0027] Record the first time interval between the last successful sending of heartbeat data and the current time;

[0028] When the first time interval is greater than or equal to a second preset time interval, destroying all tokens in the local token pool;

[0029] Wherein, the second preset time interval is greater than the first preset time interval.

[0030] Another aspect of the present invention provides a token management method, which is applied to a token management system, wherein the system includes a client and a server, and the method includes:

[0031] When the client detects an operation request for a target resource, a token corresponding to the operation request is obtained, where the target resource is a shared resource of a distributed system, and the token includes a signature verification rule, where the signature verification rule includes a signature verification method for verifying the token;

[0032] The client parses the token to determine a verification method for the token, where the verification method is one of client verification and server verification;

[0033] When the signature verification mode is client-side signature verification, the client performs a signature verification operation on the token to obtain a signature verification result; when the signature verification result is that the signature verification is passed, the client allows the execution of the operation requested by the operation request;

[0034] When the signature verification method is server-side signature verification, the client sends the token to the server;

[0035] The server receives the token sent by the client, performs a signature verification operation on the token to obtain a signature verification result, and sends the signature verification result to the client;

[0036] The client receives the signature verification result sent by the server, and when the signature verification result is passed, allows the operation requested by the operation request to be executed.

[0037] Furthermore, the method further comprises:

[0038] The server receives a token acquisition request sent by the client, where the token acquisition request corresponds to an operation request for a target resource that the client needs to initiate;

[0039] The server issues a token of a type corresponding to the operation request from an available token pool in response to the token acquisition request, and sends the token to the client;

[0040] The available token pool stores at least one token of a type corresponding to the operation request.

[0041] Furthermore, the method further comprises:

[0042] The server receives the heartbeat data sent by the client at every first preset time interval;

[0043] The server records a second time interval between the time when the heartbeat data was last successfully received and the current time;

[0044] When the second time interval is greater than or equal to a second preset time interval, the server destroys all tokens associated with the client in the available token pool;

[0045] Wherein, the second preset time interval is greater than the first preset time interval.

[0046] Furthermore, the method further comprises:

[0047] The server sends a token verification instruction to the client;

[0048] The server receives valid token information sent by the client in response to the token verification instruction;

[0049] The server manages the tokens in the available token pool according to the valid token information.

[0050] Another aspect of the present invention provides a token management device, which is arranged at a client, and the device comprises:

[0051] An acquisition module, configured to acquire a token corresponding to an operation request for a target resource when an operation request for the target resource is detected, wherein the target resource is a shared resource of a distributed system, and the token includes a signature verification rule, wherein the signature verification rule includes a signature verification method for verifying the token;

[0052] A determination module, used to parse the token to determine a verification method of the token, where the verification method is one of client verification and server verification;

[0053] The processing module is used to verify the signature of the token based on the signature verification method, and respond to the operation request according to the signature verification result.

[0054] Another aspect of the present invention provides a token management system, including a client and a server;

[0055] The client is used to, when detecting an operation request for a target resource, obtain a token corresponding to the operation request, the target resource being a shared resource of a distributed system, the token including a signature verification rule, the signature verification rule including a signature verification method for verifying the token; parsing the token to determine a signature verification method for the token, the signature verification method being one of client-side signature verification and server-side signature verification;

[0056] The client is further configured to, when the signature verification mode is client signature verification, perform a signature verification operation on the token to obtain a signature verification result; when the signature verification result is signature verification passed, allow execution of the operation requested by the operation request;

[0057] The client is further used to send the token to the server when the signature verification method is server-side signature verification;

[0058] The server is used to receive the token sent by the client, perform a signature verification operation on the token to obtain a signature verification result, and send the signature verification result to the client;

[0059] The client is also used to receive the signature verification result sent by the server, and when the signature verification result is that the signature verification is passed, the operation requested by the operation request is allowed to be executed.

[0060] Another aspect of the present invention provides an electronic device, including a processor and a memory, wherein the memory stores at least one instruction or at least one program, and the at least one instruction or the at least one program is loaded and executed by the processor to implement the token management method as described above.

[0061] Another aspect of the present invention provides a computer-readable storage medium, in which at least one instruction or at least one program is stored, and the at least one instruction or the at least one program is loaded and executed by a processor to implement the token management method as described above.

[0062] Another aspect of the present invention provides a computer program product, comprising a computer program / instruction, which implements the steps of the token management method as described above when executed by a processor.

[0063] Due to the above technical solution, the present invention has the following beneficial effects:

[0064] According to the token management method of the embodiment of the present invention, when an operation request for a target resource is detected, the token corresponding to the operation request is parsed, and it is determined whether the token verification method is client verification or server verification, and the token is verified based on the verification method, and the operation request is responded to according to the verification result. By adopting different verification methods for different types of tokens, not only can various access operations to resources be effectively controlled to achieve secure access to resources, but also the verification efficiency of the token can be improved, thereby improving the resource access efficiency of the entire system, while reducing the pressure on the server and improving system performance and stability. BRIEF DESCRIPTION OF THE DRAWINGS

[0065] In order to more clearly illustrate the technical solution of the present invention, the following briefly introduces the drawings required for use in the embodiments or prior art descriptions. Obviously, the drawings described below are only some embodiments of the present invention, and for those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative work.

[0066] Figure 1 It is a schematic diagram of an implementation environment provided by an embodiment of the present invention;

[0067] Figure 2 is a flow chart of a token management method provided by an embodiment of the present invention;

[0068] Figure 3 is a flow chart of a token management method provided by another embodiment of the present invention;

[0069] Figure 4 is a flow chart of a token management method provided by another embodiment of the present invention;

[0070] Figure 5 is a schematic diagram of the structure of a token management device provided by an embodiment of the present invention;

[0071] Figure 6 It is a schematic diagram of the structure of a token management system provided by an embodiment of the present invention;

[0072] Figure 7 It is a schematic diagram of the structure of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0073] In order to enable those skilled in the art to better understand the scheme of the present invention, the technical scheme in the embodiments of the present invention will be clearly and completely described below in conjunction with the 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 ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0074] It should be noted that the terms "first", "second", etc. in the specification and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged where appropriate, so that the embodiments of the present invention described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, device, product or equipment that includes a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or equipment.

[0075] In order to make the purpose, technical solution and advantages disclosed in the embodiments of the present invention more clear, the embodiments of the present invention are further described in detail in combination with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the embodiments of the present invention and are not used to limit the embodiments of the present invention. The acquisition, storage, use and processing of data in the technical solutions of the embodiments of the present invention are in compliance with the relevant provisions of national laws and regulations.

[0076] Reference Manual Attached Figure 1 , which shows a schematic diagram of the implementation environment of the token management method provided by an embodiment of the present invention. It should be noted that, Figure 1 The examples shown are only examples of implementation environments in which the embodiments of the present invention can be applied, to help those skilled in the art understand the technical content of the present invention, but do not mean that the embodiments of the present invention cannot be used in other devices, systems, environments or scenarios. Figure 1 As shown, the implementation environment may include at least a token management node 110 and at least one application service node 120. The token management node 110 and each application service node 120 may be directly or indirectly connected via wired or wireless communication, which is not limited in this embodiment of the present invention.

[0077] The token management node 110 and each of the application service nodes 120 may include physical devices such as smart phones, tablet computers, laptops, desktop computers, vehicle terminals, servers, etc., and may also include software running in physical devices, such as applications, etc., but are not limited thereto. The operating systems running on the token management node 110 and each of the application service nodes 120 may include, but are not limited to, Android systems, iOS systems, Linux systems, Windows systems, etc.

[0078] In the embodiment of the present invention, the token management node 110 may be provided with a token management server, and the application service node 120 may be provided with at least one client. The server may be used to manage the client and the token, and be responsible for the allocation and recovery of the token, etc. The client may be responsible for the application, management and use of the token, etc. Through the reasonable allocation of tokens, the purpose of synchronous access to resources or limiting the amount of resource access can be achieved, and the token management work is convenient and simple.

[0079] It should be noted that Figure 1 It is just an example. Those skilled in the art will understand that although Figure 1 Only two application service nodes 120 are shown, but this does not constitute a limitation on the embodiment of the present invention. According to actual needs, there may be any number of application service nodes 120.

[0080] Reference Manual Attached Figure 2 , which shows the process of a token management method provided by an embodiment of the present invention, which can be applied to Figure 1 The client in the application service node in the specific example Figure 2 As shown, the method may include the following steps:

[0081] S210: When an operation request for a target resource is detected, a token corresponding to the operation request is obtained, where the target resource is a shared resource of a distributed system, and the token includes a signature verification rule, where the signature verification rule includes a signature verification method for verifying the token.

[0082] In an embodiment of the present invention, the target resource may be a shared resource of a distributed system, such as a customer resource, a list resource, account information, etc.; the operation request may be a query request, a download request, or a change request (such as a modification request, a deletion request), etc. for the target resource. The embodiment of the present invention does not limit the type of the target resource and the type of the operation request.

[0083] In a possible embodiment, when an operation request for a target resource is detected, obtaining a token corresponding to the operation request may include:

[0084] When an operation request for a target resource is detected, a token corresponding to the operation request is obtained;

[0085] or,

[0086] When an operation request for a target resource sent by another client is detected, a token carried in the operation request is obtained.

[0087] In actual applications, operation requests for shared resources can be initiated in the following two ways: the first is a local call method, in which the client itself initiates an operation request for the target resource to call the local application service to perform the operation requested by the operation request; the second is a distributed call method, in which the caller client initiates an operation request for the target resource, and sends the operation request and the token corresponding to the operation request to the called party client to call the application service of the called party client to perform the operation requested by the operation request. Specifically, the client (caller client) can initiate an operation request for the target resource in response to an operation instruction input by the user for the target resource, or it can initiate an operation request for the target resource at a fixed time.

[0088] It should be noted that the above-mentioned method of initiating an operation request for a target resource is only an example and does not constitute a limitation to the embodiments of the present invention. In practical applications, other methods may also be used to initiate an operation request for the target resource.

[0089] In the first mode, when the client detects that it has initiated an operation request for the target resource, the method provided by the embodiment of the present invention can be used to verify the token corresponding to the operation request, and respond to the operation request according to the verification result. That is to say, the executor of the token management method provided by the embodiment of the present invention can be the client that initiates the operation request for the target resource; in the second mode, when the called party client detects the operation request for the target resource sent by the calling client, the method provided by the embodiment of the present invention can be used to verify the token carried by the operation request, and respond to the operation request according to the verification result. That is to say, the executor of the token management method provided by the embodiment of the present invention can be the called party client.

[0090] In a possible embodiment, before the client initiates an operation request for the target resource, the following steps may also be included:

[0091] When an operation request for a target resource needs to be initiated, a token is applied for the operation request.

[0092] In the embodiment of the present invention, when the client program needs to access the target resource, it needs to apply for a token first. After the client obtains the token, it can access the target resource. Specifically, applying for a token for the operation request may include:

[0093] Determine whether a token of a type corresponding to the operation request is stored in a local token pool;

[0094] When a token of a type corresponding to the operation request is stored in the local token pool, taking the token from the local token pool;

[0095] When the local token pool does not store a token of the type corresponding to the operation request, sending a token acquisition request to the server, where the token acquisition request corresponds to the operation request;

[0096] Receiving a token sent by the server, where the token is a token of a type corresponding to the operation request issued by the server from an available token pool in response to the token acquisition request;

[0097] The available token pool stores at least one token of a type corresponding to the operation request.

[0098] Specifically, the client can maintain a local token pool, and the client will not recycle the token immediately after using it, but store it in the local token pool. When the client applies for this type of token again, it can directly use the token stored in the local token pool without applying to the server for issuance. Therefore, when the client applies for a token for the operation request, it can first determine whether the local token pool stores a token of the type corresponding to the operation request. If so, the token in the local token pool is used. If not, the server is requested to issue a token.

[0099] Specifically, when the client applies to the server for issuing a token, it can send a token acquisition request to the server, and the token acquisition request corresponds to the operation request. Accordingly, the server can respond to the token acquisition request, issue at least one token of the type corresponding to the operation request from the available token pool, and send the token to the client.

[0100] Specifically, the token acquisition request can carry the name of the token to be issued. The server can determine whether there are any available tokens in the available token pool based on whether the client is online and the token name provided in the token acquisition request. If the client is online and there are available tokens, at least one token will be issued to the client. If the client is not online or there is no available token, no token will be issued and the client will fail to acquire the token.

[0101] For example, if the client needs to access the list resource, it needs to apply for a list resource access token first. At this time, it can first determine whether the list resource access token is stored in the local token pool. If so, the list resource access token in the local token pool is used. If not, apply for the list resource access token from the server. If the server determines that the client is online and there are available list resource access tokens in the available token pool, it will issue a list resource access token to the client.

[0102] It can be understood that by maintaining a local token pool, the client can store the applied token locally. When the token is needed again, it can directly use the token in the local token pool without applying for issuance from the server. This can improve resource access efficiency and reduce the burden on the server.

[0103] S220: Parse the token to determine a signature verification method for the token, where the signature verification method is one of client-side signature verification and server-side signature verification.

[0104] In an embodiment of the present invention, the token may include but is not limited to one or more of the following information: token identification (ID), token validity configuration information, server Internet Protocol (IP), client IP, signature verification rules, and token validity encryption string.

[0105] Among them, the validity configuration information of the token can be used to verify the validity of the token, and may include but is not limited to one or more of the information such as the validity period of the token, the number of valid uses and the valid usage scenarios; the signature verification rule represents the rule for verifying the token, and the signature verification rule may include the signature verification method for verifying the token, and the signature verification method may be client-side verification or server-side verification; the token validity encrypted string can be used to verify the authenticity of the token, and may include but is not limited to the encrypted string obtained by encrypting information such as the current client startup time and the token ID.

[0106] In a possible embodiment, the validity configuration information of the token can be pre-set by the server according to actual needs, the token validity encryption string can be generated by the server when issuing the token, and the token verification rule can be determined according to the usage scenario of the token. For usage scenarios with a higher security level, such as various operation scenarios of confidential resources or privacy resources, the verification method of the corresponding token can be set to server verification; for usage scenarios with a lower security level, such as various operation scenarios of general resources, the verification method of the corresponding token can be set to client verification.

[0107] Specifically, after the token is obtained, the token may be parsed to determine the token verification rule, thereby determining whether the token verification method is server-side verification or client-side verification.

[0108] S230: Verify the token based on the signature verification method, and respond to the operation request according to the signature verification result.

[0109] In a distributed system, there may be multiple application service nodes or multiple client processes of the same application service node at the same time, initiating access operations to shared resources. In order to avoid abnormal situations such as resource confusion and process damage, access control to shared resources and limiting resource access can be achieved by allocating tokens and verifying the validity of tokens, thereby ensuring the normal operation of the system.

[0110] In an embodiment of the present invention, when the signature verification method is client-side signature verification, the client can directly verify the token to obtain a verification result. When the signature verification method is server-side signature verification, the client can send the token to the server for verification to obtain a verification result.

[0111] In a possible embodiment, in conjunction with the reference specification, Figure 3 , verifying the token based on the signature verification method, and responding to the operation request according to the signature verification result may include:

[0112] S231: When the signature verification mode is client-side signature verification, a signature verification operation is performed on the token to obtain a signature verification result.

[0113] S232: When the signature verification result is passed, the operation requested by the operation request is allowed to be executed.

[0114] Specifically, when the client verifies the token, it can first parse the token to obtain information such as the validity configuration information of the token, the client IP, the verification rule, and the token validity encryption string. The client can verify the authenticity of the token based on the token validity encryption string to determine whether the token has been tampered with; the client can verify the validity of the token based on the validity configuration information and the verification rule to determine whether the token is valid; the client can also determine whether the client that initiates the operation request has the corresponding operation authority based on the client IP. When the token has not been tampered with, the token is valid, and the client that initiates the operation request has the corresponding operation authority, the verification result can be determined to be a verification pass; when the token has been tampered with, the token is invalid, or the client that initiates the operation request does not have the corresponding operation authority, the verification result can be determined to be a verification failure.

[0115] Specifically, the method of verifying the authenticity of the token based on the token validity encryption string is a prior art and will not be described in detail in the embodiments of the present invention.

[0116] Specifically, verifying the validity of the token may include determining whether the current time is within the validity period of the token, determining whether the number of times the token is used is less than the valid number of times the token is used, and / or determining whether the current scenario is a valid usage scenario for the token. If the current time is within the validity period of the token, the number of times the token is used is less than the valid number of times the token is used, and / or the current scenario is a valid usage scenario for the token, then it can be determined that the token is valid; otherwise, it can be determined that the token is invalid.

[0117] Specifically, it can be determined whether the IP of the client initiating the operation request is the same as the client IP. If they are the same, it can be determined that the client initiating the operation request has the corresponding operation authority. Otherwise, it can be determined that the client initiating the operation request does not have the corresponding operation authority.

[0118] S233: When the signature verification method is server-side signature verification, the token is sent to the server, so that the server performs a signature verification operation on the token, obtains and returns a signature verification result.

[0119] S234: receiving the signature verification result sent by the server, and when the signature verification result is passed, allowing execution of the operation requested by the operation request.

[0120] Specifically, when the signature verification method is server-side signature verification, the client can parse the token, obtain the server IP of the token, and send the token to the corresponding server. When the server verifies the token, it can first parse the token to obtain the validity configuration information of the token, the client IP, the signature verification rules, the token validity encryption string and other information, and verify the token based on the above information. The specific method is similar to the method of the client verifying the token, and the embodiment of the present invention will not be repeated here.

[0121] In a possible embodiment, the server can also modify the validity configuration information of the token in response to the user's instructions or according to the actual situation to change the verification result of the token, or directly modify the verification result of the token, so as to achieve real-time customized control of the access volume of the target resource. Exemplarily, when the access volume of the target resource is already large, if there are still clients initiating operation requests for the target resource, at this time, after the server receives the token corresponding to the operation request, even if the token has not been tampered with, the token is valid, and the client initiating the operation request has the corresponding operation authority, the verification result of the token can be modified to fail the verification, and the client is not allowed to perform the operation requested by the operation request.

[0122] It can be understood that by verifying the authenticity, validity and client permissions of the token, the token can be prevented from being tampered with or misused, ensuring the security of shared resources. At the same time, the access to shared resources can be effectively controlled to ensure the stable operation of the system.

[0123] In an embodiment of the present invention, the signature verification result may include signature verification passed and signature verification failed. When the signature verification result is signature verification passed, it indicates that the token is authentic and valid, and the operation requested by the operation request can be executed. When the signature verification result is signature verification failed, it indicates that the token is invalid and the operation requested by the operation request is not allowed to be executed.

[0124] In an embodiment of the present invention, when the signature verification result is a signature verification failure, the process ends abnormally and the token can be destroyed. Specifically, if the current application scenario is a local call scenario, when the client determines that the signature verification result is a signature verification failure, the token can be destroyed immediately, and a token recovery request can be sent to the server. After the server receives the token recovery request, the token can be destroyed and a new available token can be replenished into the available token pool. If the current application scenario is a distributed call scenario, the server can also send the signature verification result to the caller client (i.e., the other client). If the caller client determines that the signature verification result is a signature verification failure, the token can be destroyed immediately, and a token recovery request can be sent to the server. After the server receives the token recovery request, the token can be destroyed and a new available token can be replenished into the available token pool.

[0125] In one possible embodiment, after the client uses the token to complete access to the target resource, the token can be recycled into the local token pool and the token retention time can be set. During the token retention time, the client retains the token; after the token retention time is exceeded, the client can destroy the token and send a token recovery request to the server to notify the server to recover the token. After receiving the token recovery request, the server can destroy the token and replenish a new available token to the available token pool. It can be understood that by setting the token retention time, when the token retention time is exceeded, the client automatically returns the token, which can achieve orderly management of tokens and better meet the resource access requirements of distributed systems.

[0126] Optionally, the holding time of the token may be configured by the server according to actual needs, and sent to the client together with the token when issuing the token. The embodiment of the present invention does not limit the length of the holding time.

[0127] In a possible embodiment, the method may further include the following steps:

[0128] Sending heartbeat data to the server at every first preset time interval;

[0129] Record the first time interval between the last successful sending of heartbeat data and the current time;

[0130] When the first time interval is greater than or equal to a second preset time interval, destroying all tokens in the local token pool;

[0131] Wherein, the second preset time interval is greater than the first preset time interval.

[0132] Specifically, after startup, the client can send heartbeat data to the server at every first preset time interval, and record the time of the last successful sending of heartbeat data. If the heartbeat data cannot be sent successfully within the second preset time interval, all tokens in the local token pool of the client are destroyed. The first preset time interval and the second preset time interval can be set according to actual needs. For example, the first preset time interval can be set to n seconds (n is greater than or equal to 1), and the second preset time interval can be set to 3n+1 seconds. The embodiment of the present invention does not limit this.

[0133] Accordingly, the server can monitor the heartbeat data sent by the client and record the time of the last successful receipt of the heartbeat data. If no heartbeat data is received within a second preset time interval, the client can be removed from the online client list, all tokens associated with the client in the available token pool can be destroyed, and new available tokens can be added to the available token pool.

[0134] It can be understood that the client can ensure normal communication with the server by sending heartbeat data to the server at regular intervals. When the client loses communication with the server, the server destroys all tokens associated with the client, avoiding the situation where the token cannot be returned due to network anomalies, which in turn causes other clients to be unable to access resources, thereby improving the utilization rate of the token.

[0135] In summary, according to the token management method of an embodiment of the present invention, when an operation request for a target resource is detected, the token corresponding to the operation request is parsed, and it is determined whether the verification method of the token is client verification or server verification, and the token is verified based on the verification method, and the operation request is responded to according to the verification result. By adopting different verification methods for different types of tokens, not only can various access operations to resources be effectively controlled and secure access to resources be achieved, but also the verification efficiency of the token can be improved, thereby improving the resource access efficiency of the entire system, while reducing the pressure on the server and improving system performance and stability.

[0136] Reference Manual Attached Figure 4 , which shows a process of a token management method provided by another embodiment of the present invention. The method can be applied to a token management system, wherein the system includes a client and a server. Specifically, Figure 4 As shown, the method may include the following steps:

[0137] S410: When the client detects an operation request for a target resource, a token corresponding to the operation request is obtained, where the target resource is a shared resource of a distributed system, and the token includes a signature verification rule, where the signature verification rule includes a signature verification method for verifying the token.

[0138] S420: The client parses the token to determine a verification method for the token, where the verification method is one of client verification and server verification.

[0139] S430: When the signature verification mode is client-side signature verification, the client performs a signature verification operation on the token to obtain a signature verification result.

[0140] S440: When the signature verification result is passed, the client allows execution of the operation requested by the operation request.

[0141] S450: When the signature verification method is server-side signature verification, the client sends the token to the server.

[0142] S460: The server receives the token sent by the client, and performs a signature verification operation on the token to obtain a signature verification result.

[0143] S470: The server sends the signature verification result to the client.

[0144] S480: The client receives the signature verification result sent by the server, and when the signature verification result is passed, allows the operation requested by the operation request to be executed.

[0145] The specific contents of steps S410 to S480 can be referred to as follows. Figure 2 The contents of the method embodiment shown are not repeated here in the embodiment of the present invention.

[0146] In an embodiment of the present invention, the server can maintain an available token pool, which can store different types of tokens configured for different businesses and different scenarios, as well as basic information of each type of token, including token name, token quantity, allocation rules and verification rules, etc., wherein the token quantity represents the maximum number of such tokens that the client can apply for, and the allocation rules represent the rules for issuing tokens to the client, for example, it may include assigning a password to each client, sharing a password for all clients, etc., and the verification rules represent the rules for verifying such tokens, and may include a verification method for verifying such tokens, and the verification method may be client verification or server verification. It should be noted that the types of tokens in the available token pool and the basic information of each type of token can be set according to actual needs, and the embodiment of the present invention does not limit this.

[0147] It can be understood that by maintaining the available token pool, configuring different types of tokens for different businesses and different scenarios, and the basic information of each type of token, the complex token management work is optimized, so that the application only needs to focus on the application and use of the token, which is more convenient for the server to manage the token. Among them, the number of each type of token can be set to one or more, so the token management method provided in the embodiment of the present invention is suitable for allocating a single token (distributed lock) and allocating multiple tokens (restricted access to shared resources). Through the reasonable sharding of tokens, it can not only achieve synchronous access to resources, but also limit the amount of resource access, and has a wide range of applications and is easy to manage.

[0148] In actual applications, the server can be started first. After the server is started, all tokens can be initialized and all available tokens can be filled into the available token pool according to the corresponding quantity. Then the client instance is started. After the client is started, the corresponding client server information including but not limited to IP, port, start time, Media Access Control (MAC) address and other information can be registered to the server. The server can use database, zookeeper and other storage media to save the client's registration information, and feedback to the client whether the registration is successful. When the client is successfully registered, the server can add the client to the online client list, and the server has the information including the online client list and the available token pool. When the client registration fails, the client startup fails and needs to be restarted.

[0149] In a possible embodiment, the method may further include:

[0150] The server receives a token acquisition request sent by the client, where the token acquisition request corresponds to an operation request for a target resource that the client needs to initiate;

[0151] The server issues a token of a type corresponding to the operation request from an available token pool in response to the token acquisition request, and sends the token to the client;

[0152] The available token pool stores at least one token of a type corresponding to the operation request.

[0153] Specifically, when the client program needs to initiate an operation request for a target resource, it needs to apply for a token first. After the client obtains the token, it can access the target resource. When applying for a token, the client can first determine whether the local token pool stores a token of the type corresponding to the operation request. If so, the token in the local token pool is used. If not, the client applies to the server for issuing a token.

[0154] Specifically, when the client applies to the server for issuing a token, it can send a token acquisition request to the server. The token acquisition request can carry the name of the token to be issued. The server can determine whether there are any available tokens in the available token pool based on whether the client is online and the token name provided in the token acquisition request. If the client is online and there are available tokens, at least one token is issued to the client. If the client is not online or there is no available token, no token is issued and the client fails to obtain the token.

[0155] In a possible embodiment, the method may further include:

[0156] The server receives the heartbeat data sent by the client at every first preset time interval;

[0157] The server records a second time interval between the time when the heartbeat data was last successfully received and the current time;

[0158] When the second time interval is greater than or equal to a second preset time interval, the server destroys all tokens associated with the client in the available token pool;

[0159] Wherein, the second preset time interval is greater than the first preset time interval.

[0160] Specifically, after startup, the client can send heartbeat data to the server every first preset time interval. Accordingly, the server can monitor the heartbeat data sent by the client and record the time of the last successful reception of the heartbeat data. If the heartbeat data is not received after a second preset time interval, the client can be removed from the online client list, and all tokens associated with the client in the available token pool are destroyed, and new available tokens are added to the available token pool. Among them, the first preset time interval and the second preset time interval can be set according to actual needs. For example, the first preset time interval can be set to n seconds (n is greater than or equal to 1), and the second preset time interval can be set to 3n+1 seconds. This is not limited in the embodiment of the present invention.

[0161] It can be understood that the client can ensure normal communication with the server by sending heartbeat data to the server at regular intervals. When the client loses communication with the server, the server destroys all tokens associated with the client, avoiding the situation where the token cannot be returned due to network anomalies, which in turn causes other clients to be unable to access resources, thereby improving the utilization rate of the token.

[0162] In a possible embodiment, the method may further include:

[0163] The server sends a token verification instruction to the client;

[0164] The server receives valid token information sent by the client in response to the token verification instruction;

[0165] The server manages the tokens in the available token pool according to the valid token information.

[0166] Specifically, after the server is restarted or at regular intervals, it can send a token verification instruction to the online client, requiring the client to feedback a full amount of valid tokens. Accordingly, the client can send valid token information to the server in response to the token verification instruction. After the server obtains the valid token information, it can compare it with the list of issued tokens in the available token pool to determine the tokens that have expired on the client but failed to successfully notify the server, remove and destroy these tokens from the list of issued tokens, and replenish new available tokens to the available token pool. After the server obtains the valid token information, it can also restore the tokens that were accidentally destroyed by the server based on the valid token information.

[0167] It is understandable that after an exception or downtime occurs on the server side, the system can automatically check to obtain valid token information of each client, and restore or destroy tokens in the available token pool based on the valid token information, thereby ensuring the robustness of the system.

[0168] In a possible embodiment, the server may also receive a token recovery request sent by the client. After receiving the token recovery request, the server may destroy the token and replenish a new available token into the available token pool.

[0169] In one possible embodiment, when a client goes offline, the client can actively destroy all tokens in the local token pool and send an offline notification to the server. After receiving the offline notification, the server can destroy all tokens issued to the client in the available token pool, add new available tokens to the available token pool, and remove the client from the online client list.

[0170] In summary, according to the token management method of an embodiment of the present invention, by adopting the client / server mode, the server is responsible for the management, allocation and recovery of tokens, and the client is responsible for the application and use of tokens. When the client detects an operation request for a target resource, the token corresponding to the operation request is parsed, and it is determined whether the verification method of the token is client verification or server verification, and the token is verified based on the verification method, and the operation request is responded to according to the verification result. By adopting different verification methods for different types of tokens, not only can various access operations to resources be effectively controlled and secure access to resources be achieved, but also the verification efficiency of the token can be improved, thereby improving the resource access efficiency of the entire system, while reducing the pressure on the server and improving system performance and stability.

[0171] Reference Manual Attached Figure 5, which shows the structure of a token management device 500 provided by an embodiment of the present invention, wherein the token management device 500 is arranged at the client, such as Figure 5 As shown, the token management device 500 may include:

[0172] The acquisition module 510 is used to acquire a token corresponding to the operation request when an operation request for a target resource is detected, the target resource is a shared resource of a distributed system, the token includes a signature verification rule, and the signature verification rule includes a signature verification method for verifying the token;

[0173] A determination module 520 is used to parse the token to determine a verification method of the token, where the verification method is one of client verification and server verification;

[0174] The processing module 530 is used to verify the signature of the token based on the signature verification method, and respond to the operation request according to the signature verification result.

[0175] In a possible embodiment, the token management device 500 may further include:

[0176] The token application module is used to apply for a token for an operation request when an operation request for a target resource needs to be initiated.

[0177] In a possible embodiment, the token management device 500 may further include:

[0178] A data sending module, used for sending heartbeat data to the server at every first preset time interval;

[0179] A time recording module, used to record the first time interval between the time when the heartbeat data was last successfully sent and the current time;

[0180] A token destruction module, configured to destroy all tokens in a local token pool when the first time interval is greater than or equal to a second preset time interval;

[0181] Wherein, the second preset time interval is greater than the first preset time interval.

[0182] Reference Manual Attached Figure 6 , which shows the structure of a token management system 600 provided by an embodiment of the present invention, such as Figure 6 As shown, the token management system 600 may include a client 610 and a server 620;

[0183] The client 610 may be used to obtain a token corresponding to the operation request when an operation request for a target resource is detected, the target resource being a shared resource of a distributed system, the token including a signature verification rule, the signature verification rule including a signature verification method for verifying the token; the token is parsed to determine a signature verification method for the token, the signature verification method being one of client signature verification and server signature verification;

[0184] The client 610 may also be used to perform a signature verification operation on the token to obtain a signature verification result when the signature verification mode is client signature verification; when the signature verification result is signature verification passed, allow the operation requested by the operation request to be executed;

[0185] The client 610 may also be used to send the token to the server when the signature verification method is server-side signature verification;

[0186] The server 620 may be configured to receive a token sent by the client, perform a signature verification operation on the token to obtain a signature verification result, and send the signature verification result to the client;

[0187] The client 610 may also be used to receive a signature verification result sent by the server, and when the signature verification result is that the signature verification is passed, the operation requested by the operation request is allowed to be executed.

[0188] In a possible embodiment, the server 620 can also be used to receive a token acquisition request sent by the client, wherein the token acquisition request corresponds to an operation request that the client needs to initiate for the target resource; in response to the token acquisition request, a token of the type corresponding to the operation request is issued from an available token pool, and the token is sent to the client; wherein the available token pool stores at least one token of the type corresponding to the operation request.

[0189] In a possible embodiment, the server 620 can also be used to receive heartbeat data sent by the client every first preset time interval; record a second time interval between the time when the heartbeat data was last successfully received and the current time; when the second time interval is greater than or equal to the second preset time interval, destroy all tokens associated with the client in the available token pool; wherein the second preset time interval is greater than the first preset time interval.

[0190] In a possible embodiment, the server 620 may also be used to send a token verification instruction to the client; receive valid token information sent by the client in response to the token verification instruction; and manage tokens in the available token pool according to the valid token information.

[0191] It should be noted that the device provided in the above embodiment, when implementing its functions, only uses the division of the above functional modules as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device is divided into different functional modules to complete all or part of the functions described above. In addition, the device provided in the above embodiment and the corresponding method embodiment belong to the same concept, and the specific implementation process is detailed in the corresponding method embodiment, which will not be repeated here.

[0192] An embodiment of the present invention also provides an electronic device, which includes a processor and a memory, wherein the memory stores at least one instruction or at least one program, and the at least one instruction or the at least one program is loaded and executed by the processor to implement a token management method provided in the above method embodiment.

[0193] The memory can be used to store software programs and modules. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory. The memory can mainly include a program storage area and a data storage area, wherein the program storage area can store an operating system, application programs required for functions, etc.; the data storage area can store data created according to the use of the device, etc. In addition, the memory can include a high-speed random access memory and can also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other volatile solid-state storage devices. Accordingly, the memory can also include a memory controller to provide the processor with access to the memory.

[0194] In conjunction with the reference manual Figure 7 , which is a block diagram of an electronic device 700 according to an embodiment of the present invention. The electronic device 700 may include one or more processors 702, a system control logic 708 connected to at least one of the processors 702, a system memory 704 connected to the system control logic 708, a non-volatile memory (NVM) 706 connected to the system control logic 708, and a network interface 710 connected to the system control logic 708.

[0195] The processor 702 may include one or more single-core or multi-core processors. The processor 702 may include any combination of general-purpose processors and special-purpose processors (e.g., graphics processors, application processors, baseband processors, etc.). In the embodiments of the present invention, the processor 702 may be configured to execute the following operations: Figures 2 to 4 One or more of the various embodiments shown.

[0196] In some embodiments, system control logic 708 may include any suitable interface controller to provide any suitable interface to at least one of processors 702 and / or any suitable device or component in communication with system control logic 708 .

[0197] In some embodiments, the system control logic 708 may include one or more memory controllers to provide an interface to the system memory 704. The system memory 704 may be used to load and store data and / or instructions. In some embodiments, the memory 704 of the device 700 may include any suitable volatile memory, such as a suitable dynamic random access memory (DRAM).

[0198] NVM / memory 706 may include one or more tangible, non-transitory computer-readable media for storing data and / or instructions. In some embodiments, NVM / memory 706 may include any suitable non-volatile memory such as flash memory and / or any suitable non-volatile storage device, such as at least one of a HDD (Hard Disk Drive), a CD (Compact Disc) drive, and a DVD (Digital Versatile Disc) drive.

[0199] NVM / storage 706 may include a portion of storage resources installed on a device of apparatus 700, or it may be accessible to the apparatus but not necessarily a part of the apparatus. For example, NVM / storage 706 may be accessed over a network via network interface 710.

[0200] In particular, system memory 704 and NVM / storage 706 may include, respectively, a temporary copy and a permanent copy of instructions 720. Instructions 720 may include instructions that, when executed by at least one of processors 702, cause device 700 to perform the following operations: Figures 2 to 4 Instructions of the token management method shown. In some embodiments, instructions 720, hardware, firmware and / or software components thereof may be additionally / alternatively placed in system control logic 708, network interface 710 and / or processor 702.

[0201] The network interface 710 may include a transceiver for providing a radio interface for the device 700 to communicate with any other suitable device (such as a front-end module, an antenna, etc.) through one or more networks. In some embodiments, the network interface 710 may be integrated with other components of the device 700. For example, the network interface 710 may be integrated with at least one of a communication module of the processor 702, a system memory 704, an NVM / storage 706, and a firmware device (not shown) having instructions. When at least one of the processors 702 executes the instructions, the device 700 implements Figures 2 to 4 One or more of the various embodiments shown.

[0202] The network interface 710 may further include any suitable hardware and / or firmware to provide a multiple-input multiple-output radio interface. For example, the network interface 710 may be a network adapter, a wireless network adapter, a telephone modem and / or a wireless modem.

[0203] In one embodiment, at least one of the processors 702 may be packaged together with logic for one or more controllers of the system control logic 708 to form a system in package (SiP). In one embodiment, at least one of the processors 702 may be integrated on the same die with logic for one or more controllers of the system control logic 708 to form a system on a chip (SoC).

[0204] The device 700 may further include an input / output (I / O) device 712. The I / O device 712 may include a user interface to enable a user to interact with the device 700; the design of the peripheral component interface enables the peripheral components to interact with the device 700. In some embodiments, the device 700 further includes a sensor for determining at least one of an environmental condition and location information related to the device 700.

[0205] In some embodiments, the user interface may include, but is not limited to, a display (e.g., an LCD display, a touch screen display, etc.), a speaker, a microphone, one or more cameras (e.g., a still image camera and / or a video camera), a flashlight (e.g., an LED flash), and a keyboard.

[0206] In some embodiments, the peripheral component interface may include, but is not limited to, a non-volatile memory port, an audio jack, and a power interface.

[0207] In some embodiments, the sensors may include, but are not limited to, gyroscope sensors, accelerometers, proximity sensors, ambient light sensors, and positioning units. The positioning unit may also be part of or interact with the network interface 710 to communicate with components of a positioning network (e.g., global positioning system (GPS) satellites).

[0208] It is to be understood that the structure illustrated in the embodiment of the present invention does not constitute a specific limitation on the electronic device 700. In other embodiments of the present invention, the electronic device 700 may include more or fewer components than shown in the figure, or combine some components, or separate some components, or arrange the components differently. The components shown in the figure may be implemented in hardware, software, or a combination of software and hardware.

[0209] An embodiment of the present invention also provides a computer-readable storage medium, which can be set in an electronic device to store at least one instruction or at least one program related to implementing a token management method. The at least one instruction or the at least one program is loaded and executed by the processor to implement the token management method provided by the above method embodiment.

[0210] Optionally, in an embodiment of the present invention, the above-mentioned storage medium may include but is not limited to: a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk, and other media that can store program codes.

[0211] One embodiment of the present invention also provides a computer program product, which includes a computer program / instructions. When the computer program product runs on an electronic device, the computer program / instructions are loaded and executed by a processor to implement the steps of the token management method provided in the above-mentioned various optional embodiments.

[0212] It should be noted that the sequence of the embodiments of the present invention described above is for description only and does not represent the advantages and disadvantages of the embodiments. The above describes specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in an order different from that in the embodiments and still achieve the desired results. In addition, the processes depicted in the drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0213] Each embodiment in this specification is described in a progressive manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the device embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0214] A person skilled in the art will understand that all or part of the steps to implement the above embodiments may be accomplished by hardware or by instructing related hardware through a program, and the program may be stored in a computer-readable storage medium, and the above-mentioned storage medium may be a read-only memory, a disk or an optical disk, etc.

[0215] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principle of the present invention should be included in the protection scope of the present invention.

Claims

1. A token management method, applied to a client, characterized in that: The method comprises: When an operation request for a target resource is detected, a token corresponding to the operation request is obtained, wherein the target resource is a shared resource of a distributed system, and the token includes a signature verification rule, wherein the signature verification rule includes a signature verification method for verifying the token; Parse the token to determine a verification method for the token, where the verification method is one of client verification and server verification; Verifying the token based on the verification method, and responding to the operation request according to the verification result, including: When the signature verification mode is client-side signature verification, a signature verification operation is performed on the token to obtain a signature verification result; when the signature verification result is that the signature verification is passed, the operation requested by the operation request is allowed to be executed; When the signature verification method is server-side signature verification, the token is sent to the server so that the server performs a signature verification operation on the token, obtains and returns a signature verification result; the signature verification result sent by the server is received, and when the signature verification result is passed, the operation requested by the operation request is allowed to be executed.

2. The method according to claim 1, characterized in that When an operation request for a target resource is detected, obtaining a token corresponding to the operation request includes: When an operation request for a target resource is detected, a token corresponding to the operation request is obtained; or, When an operation request for a target resource sent by another client is detected, a token carried in the operation request is obtained.

3. The method according to claim 1 or 2, characterized in that: The method further comprises: When an operation request for a target resource needs to be initiated, a token is applied for the operation request.

4. The method according to claim 3, characterized in that The applying for a token for the operation request comprises: Determine whether a token of a type corresponding to the operation request is stored in a local token pool; When a token of a type corresponding to the operation request is stored in the local token pool, taking the token from the local token pool; When the local token pool does not store a token of the type corresponding to the operation request, sending a token acquisition request to the server, where the token acquisition request corresponds to the operation request; Receiving a token sent by the server, where the token is a token of a type corresponding to the operation request issued by the server from an available token pool in response to the token acquisition request; The available token pool stores at least one token of a type corresponding to the operation request.

5. The method according to claim 1 or 2, characterized in that: The method further comprises: Sending heartbeat data to the server at every first preset time interval; Record the first time interval between the last successful sending of heartbeat data and the current time; When the first time interval is greater than or equal to a second preset time interval, destroying all tokens in the local token pool; Wherein, the second preset time interval is greater than the first preset time interval.

6. A token management method, applied to a token management system, the system comprising a client and a server, characterized in that: The method comprises: When the client detects an operation request for a target resource, a token corresponding to the operation request is obtained, where the target resource is a shared resource of a distributed system, and the token includes a signature verification rule, where the signature verification rule includes a signature verification method for verifying the token; The client parses the token to determine a verification method for the token, where the verification method is one of client verification and server verification; When the signature verification mode is client-side signature verification, the client performs a signature verification operation on the token to obtain a signature verification result; when the signature verification result is that the signature verification is passed, the client allows the execution of the operation requested by the operation request; When the signature verification method is server-side signature verification, the client sends the token to the server; The server receives the token sent by the client, performs a signature verification operation on the token to obtain a signature verification result, and sends the signature verification result to the client; The client receives the signature verification result sent by the server, and when the signature verification result is passed, allows the operation requested by the operation request to be executed.

7. The method according to claim 6, characterized in that The method further comprises: The server receives a token acquisition request sent by the client, where the token acquisition request corresponds to an operation request for a target resource that the client needs to initiate; The server issues a token of a type corresponding to the operation request from an available token pool in response to the token acquisition request, and sends the token to the client; The available token pool stores at least one token of a type corresponding to the operation request.

8. The method according to claim 6, characterized in that The method further comprises: The server receives the heartbeat data sent by the client at every first preset time interval; The server records a second time interval between the time when the heartbeat data was last successfully received and the current time; When the second time interval is greater than or equal to a second preset time interval, the server destroys all tokens associated with the client in the available token pool; Wherein, the second preset time interval is greater than the first preset time interval.

9. The method according to claim 6, characterized in that The method further comprises: The server sends a token verification instruction to the client; The server receives valid token information sent by the client in response to the token verification instruction; The server manages the tokens in the available token pool according to the valid token information.

10. A token management device, arranged at a client, characterized in that: The device comprises: An acquisition module, configured to acquire a token corresponding to a target resource when an operation request for the target resource is detected, wherein the target resource is a shared resource of a distributed system, and the token includes a signature verification rule, wherein the signature verification rule includes a signature verification method for verifying the token; A determination module, used to parse the token to determine a verification method of the token, where the verification method is one of client verification and server verification; A processing module, configured to verify the signature of the token based on the signature verification method, and respond to the operation request according to the signature verification result, including: When the signature verification mode is client-side signature verification, a signature verification operation is performed on the token to obtain a signature verification result; when the signature verification result is that the signature verification is passed, the operation requested by the operation request is allowed to be executed; When the signature verification method is server-side signature verification, the token is sent to the server so that the server performs a signature verification operation on the token, obtains and returns a signature verification result; the signature verification result sent by the server is received, and when the signature verification result is passed, the operation requested by the operation request is allowed to be executed.

11. A token management system, characterized in that: Including client and server; The client is used to obtain a token corresponding to the operation request when an operation request for a target resource is detected, the target resource is a shared resource of a distributed system, the token includes a signature verification rule, and the signature verification rule includes a signature verification method for verifying the token; Parse the token to determine a verification method for the token, where the verification method is one of client verification and server verification; The client is further configured to, when the signature verification mode is client signature verification, perform a signature verification operation on the token to obtain a signature verification result; when the signature verification result is signature verification passed, allow execution of the operation requested by the operation request; The client is further used to send the token to the server when the signature verification method is server-side signature verification; The server is used to receive the token sent by the client, perform a signature verification operation on the token to obtain a signature verification result, and send the signature verification result to the client; The client is also used to receive the signature verification result sent by the server, and when the signature verification result is that the signature verification is passed, the operation requested by the operation request is allowed to be executed.

12. An electronic device, characterized in that: The electronic device includes a processor and a memory, wherein the memory stores at least one instruction or at least one program, and the at least one instruction or the at least one program is loaded and executed by the processor to implement the token management method as described in any one of claims 1-9.

13. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores at least one instruction or at least one program, and the at least one instruction or at least one program is loaded and executed by a processor to implement the token management method according to any one of claims 1 to 9.

14. A computer program product comprising a computer program / instructions, characterized in that When the computer program / instructions are executed by a processor, the steps of the token management method described in any one of claims 1 to 9 are implemented.

Citation Information

Patent Citations

  • Local Device Authentication

    CN107070863A

  • Bypass signature verification method and system, server, signature management platform and medium

    CN110730073A

  • Location-based access to controlled access resources

    CN111869179A

  • Access token generation and verification method and device, electronic equipment and storage medium

    CN113922968A

  • Secure token refresh

    US20210288808A1