Token verification method and system
By integrating the server SDK to the account center SDK, long connections are established and resource occupancy is monitored, local checksums are realized when resource occupancy is high, centralized checksum when resource occupancy is low, solving the problem of excessive resource occupancy in the account center, and improving the efficiency and performance balance of token verification.
Patent Information
- Application Number
- CN202411547094.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-11-01
- Publication Date
- 2025-03-18
AI Technical Summary
In the prior art, when the account center performs centralized token verification, the resource occupancy rate is too high, resulting in performance degradation and inefficiency.
By integrating the individual SDKs on each server into the central SDK of the account center, a long connection is established and resource occupancy is monitored in real time. When the resource occupancy rate exceeds a certain threshold, local verification is enabled and token verification is used using local cache; when the resource occupancy rate decreases, centralized verification is restored.
It reduces the resource occupancy rate of the account center, alleviates its pressure, realizes automatic balance between security and performance, and improves the efficiency of token verification.
Smart Images
Figure CN119652529A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of computer technology, and in particular to a token verification method and system. Background Art
[0002] Currently, all large systems have an account center, which provides account registration and various login functions. In order to ensure the security of the system interface, a token information will be returned after the account login, and an encrypted string will be generated through certain encryption rules and attached to each interface. When the client requests the server interface, it will bring these encrypted strings. When the server receives the request, it will send the encrypted string to the account center module for verification. When the verification is passed, the subsequent logic of the interface will be carried out.
[0003] Due to security considerations, the above verification is usually performed in a centralized manner, that is, all clients and their token information are verified at the account center. Although centralized verification can indeed improve security, the account center needs to occupy huge resources and bear huge pressure. At the same time, it also places high demands on the performance of the account center, which leads to certain limitations in centralized verification and affects the efficiency of token verification. Summary of the invention
[0004] The technical problem to be solved by the present invention is: the present invention provides a token verification method and system, which reduces the resource occupancy rate of the account center, relieves the pressure of the account center, achieves automatic balance between security and performance, and improves the efficiency of token verification.
[0005] In order to solve the above technical problems, the technical solution adopted by the present invention is:
[0006] In a first aspect, the present invention provides a token verification method, comprising:
[0007] Obtain the central SDK of the account center and the individual SDK of each server, and integrate all the individual SDKs into the central SDK to establish a persistent connection between the account center and each server;
[0008] The resource utilization rate of the account center is obtained in real time, and it is determined whether the resource utilization rate exceeds a first threshold. If so, a first instruction is sent to the individual SDK through the long connection. The individual SDK receives and starts local verification according to the first instruction. The individual SDK stores the received token information in a local cache, and verifies through the local cache when receiving a token verification request. If not, the individual SDK forwards the token verification request to the account center through the long connection for verification when receiving the token verification request.
[0009] The beneficial effects of the present invention are as follows: by integrating the individual SDK of each server into the central SDK of the account center, the inheritance of the central SDK of the account center by each server is achieved, so that when the resource occupancy rate exceeds the first threshold, local verification can be enabled, and the verification of the token verification request is achieved through local cache, that is, the centralized verification method based on the account center is converted into local verification of multiple points, which relieves the pressure on the account center and controls the resource occupancy rate of the account center. The centralized verification method of the account center is not completely abandoned, and local verification is started only when the resource occupancy rate exceeds the first threshold. Therefore, an automatic balance between security and performance is achieved, and the efficiency of token verification is improved.
[0010] Optionally, the individual SDK stores the received token information in a local cache, and performs verification through the local cache upon receiving a token verification request, including:
[0011] Determine whether token information corresponding to the token verification request exists in the local cache; if not, send a first request to the account center through the long connection to obtain token information corresponding to the token verification request, and store the obtained token information corresponding to the token verification request in the local cache for verification through the local cache; if exists, directly filter out the token information corresponding to the token verification request from the local cache for verification.
[0012] According to the above description, when performing local verification, that is, when verifying through the local cache, if the token information corresponding to the token verification request does not exist in the local cache, it will be obtained from the account center to ensure the smooth progress of local verification and improve verification efficiency.
[0013] Optionally, the individual SDK stores the received token information in a local cache, and performs verification through the local cache when receiving a token verification request, including:
[0014] The resource utilization rate is monitored in real time. When it is monitored that the resource utilization rate does not exceed the first threshold, a second instruction is sent to the individual SDK through the long connection. The individual SDK receives and closes local verification according to the second instruction, and forwards the token verification request to the account center for verification through the long connection when a token verification request is received.
[0015] According to the above description, after local verification is enabled, once the resource utilization rate is monitored to be reduced to less than the first threshold, it will automatically restore to the centralized verification method of the account center, achieving an automatic balance between security and performance and improving the efficiency of token verification.
[0016] Optionally, the token information includes a login token and an encryption key corresponding to the login token.
[0017] According to the above description, the integrity of the token information ensures the smooth progress of the verification.
[0018] Optionally, the first threshold is [80,85].
[0019] In a second aspect, the present invention provides a token verification system, comprising: an acquisition module, for acquiring a central SDK of an account center and an individual SDK of each server, and integrating all the individual SDKs into the central SDK to establish a long connection between the account center and each server;
[0020] A verification module is used to obtain the resource utilization rate of the account center in real time, and determine whether the resource utilization rate exceeds a first threshold. If so, a first instruction is sent to the individual SDK through the long connection. The individual SDK receives and starts local verification according to the first instruction. The individual SDK stores the received token information in a local cache, and verifies through the local cache when receiving a token verification request. If not, the individual SDK forwards the token verification request to the account center through the long connection for verification when receiving the token verification request.
[0021] The beneficial effects of the present invention are as follows: by integrating the individual SDK of each server into the central SDK of the account center, the inheritance of the central SDK of the account center by each server is achieved, so that when the resource occupancy rate exceeds the first threshold, local verification can be enabled, and the verification of the token verification request is achieved through local cache, that is, the centralized verification method based on the account center is converted into local verification of multiple points, which relieves the pressure on the account center and controls the resource occupancy rate of the account center. The centralized verification method of the account center is not completely abandoned, and local verification is started only when the resource occupancy rate exceeds the first threshold. Therefore, an automatic balance between security and performance is achieved, and the efficiency of token verification is improved.
[0022] Optionally, the verification module is specifically:
[0023] Determine whether token information corresponding to the token verification request exists in the local cache; if not, send a first request to the account center through the long connection to obtain token information corresponding to the token verification request, and store the obtained token information corresponding to the token verification request in the local cache for verification through the local cache; if exists, directly filter out the token information corresponding to the token verification request from the local cache for verification.
[0024] According to the above description, when performing local verification, that is, when verifying through the local cache, if the token information corresponding to the token verification request does not exist in the local cache, it will be obtained from the account center to ensure the smooth progress of local verification and improve verification efficiency.
[0025] Optionally, the verification module is specifically:
[0026] The resource utilization rate is monitored in real time. When it is monitored that the resource utilization rate does not exceed the first threshold, a second instruction is sent to the individual SDK through the long connection. The individual SDK receives and closes local verification according to the second instruction, and forwards the token verification request to the account center for verification through the long connection when a token verification request is received.
[0027] According to the above description, after local verification is enabled, once the resource utilization rate is monitored to be reduced to less than the first threshold, it will automatically restore to the centralized verification method of the account center, achieving an automatic balance between security and performance and improving the efficiency of token verification.
[0028] Optionally, the token information includes a login token and an encryption key corresponding to the login token.
[0029] According to the above description, the integrity of the token information ensures the smooth progress of the verification.
[0030] Optionally, the first threshold is [80,85]. BRIEF DESCRIPTION OF THE DRAWINGS
[0031] Figure 1 A flowchart of a token verification method provided by this embodiment;
[0032] Figure 2 A schematic diagram of the overall flow of a token verification method provided in this embodiment;
[0033] Figure 3 A schematic diagram of the structure of a token verification system provided in this embodiment.
[0034] [Description of Reference Numerals]
[0035] 1. A token verification system;
[0036] 2. Get the module;
[0037] 3. Verification module. DETAILED DESCRIPTION
[0038] In order to better understand the above technical solution, exemplary embodiments of the present invention will be described in more detail below with reference to the accompanying drawings. Although exemplary embodiments of the present invention are shown in the accompanying drawings, it should be understood that the present invention can be implemented in various forms and should not be limited by the embodiments described herein. On the contrary, these embodiments are provided to enable a clearer and more thorough understanding of the present invention and to fully convey the scope of the present invention to those skilled in the art.
[0039] Embodiment 1
[0040] Please refer to Figure 1 to Figure 2 The present invention provides a token verification method, comprising the steps of:
[0041] S1. Obtain the central SDK of the account center and the individual SDK of each server, and integrate all the individual SDKs into the central SDK to establish a long connection between the account center and each server;
[0042] In this embodiment, if Figure 2 As shown, the central SDK of the account center is accessed by all external servers. The individual SDKs of all servers are integrated into the central SDK of the account center to establish a long connection between the account center and each server. That is, subsequent communications between the account center and all external servers are achieved through this long connection.
[0043] S2. Obtain the resource utilization rate of the account center in real time, and determine whether the resource utilization rate exceeds a first threshold. If so, send a first instruction to the individual SDK through the long connection. The individual SDK receives and starts local verification according to the first instruction. The individual SDK stores the received token information in a local cache, and verifies through the local cache when receiving a token verification request. If not, the individual SDK forwards the token verification request to the account center through the long connection for verification when receiving the token verification request.
[0044] In this embodiment, if Figure 2 As shown, the resource occupancy rate of the account center is obtained in real time. When the resource occupancy rate exceeds the first threshold, the account center sends a first instruction to the individual SDK through the long connection established in step S1. At this time, the first threshold is [80,85], and the priority first threshold is 83. The individual SDK starts local verification according to the received first instruction and stores the received token information in the local cache. The token information includes the login token and the encryption key corresponding to the login token. When a token verification request is received, it is verified locally, that is, the token information in the local cache is verified. If the resource occupancy rate does not exceed the first threshold, a centralized verification method is adopted, that is, verification is performed through the account center.
[0045] At this time, in step S2, the individual SDK stores the received token information in a local cache, and performs verification through the local cache when receiving a token verification request, including:
[0046] S21. Determine whether there is token information corresponding to the token verification request in the local cache. If not, send a first request to the account center through the long connection to obtain the token information corresponding to the token verification request, and store the obtained token information corresponding to the token verification request in the local cache for verification through the local cache. If it exists, directly filter out the token information corresponding to the token verification request from the local cache for verification.
[0047] In this embodiment, if Figure 2 As shown, when performing local verification, the local cache will be queried first to see whether there is token information corresponding to the token verification request, that is, to determine whether there is token information corresponding to the token verification request in the local cache. If not, a first request will be sent to the account center through a long connection to obtain the token information corresponding to the token verification request to implement local verification. If it exists, the token information corresponding to the token verification request will be directly filtered out from the local cache for verification.
[0048] At this time, in step S2, the individual SDK stores the received token information in a local cache, and performs verification through the local cache when receiving a token verification request, including:
[0049] S22. Monitor the resource utilization rate in real time. When it is monitored that the resource utilization rate does not exceed the first threshold, send a second instruction to the individual SDK through the long connection. The individual SDK receives and closes local verification according to the second instruction, and forwards the token verification request to the account center through the long connection for verification when receiving the token verification request.
[0050] In this embodiment, if Figure 2 As shown, the resource utilization rate is monitored in real time. When it is detected that the resource utilization rate has decreased and has dropped from exceeding the first threshold to not exceeding the first threshold, the centralized verification of the account center is restored, that is, the second instruction is sent to the individual SDK through a long connection, and the individual SDK closes the local verification according to the received second instruction, and forwards all subsequently received token verification requests to the account center through the long connection for verification.
[0051] Embodiment 2
[0052] Please refer to Figure 3 The present invention provides a token verification system 1, including: an acquisition module 2 and a verification module 3.
[0053] The acquisition module 2 is used to acquire the central SDK of the account center and the individual SDK of each server, and integrate all the individual SDKs into the central SDK to establish a long connection between the account center and each server;
[0054] Verification module 3 is used to obtain the resource utilization rate of the account center in real time, and determine whether the resource utilization rate exceeds a first threshold. If so, a first instruction is sent to the individual SDK through the long connection. The individual SDK receives and starts local verification according to the first instruction. The individual SDK stores the received token information in a local cache, and verifies through the local cache when receiving a token verification request. If not, the individual SDK forwards the token verification request to the account center through the long connection for verification when receiving the token verification request.
[0055] Specifically, the verification module 3 is specifically:
[0056] Determine whether token information corresponding to the token verification request exists in the local cache; if not, send a first request to the account center through the long connection to obtain token information corresponding to the token verification request, and store the obtained token information corresponding to the token verification request in the local cache for verification through the local cache; if exists, directly filter out the token information corresponding to the token verification request from the local cache for verification.
[0057] Specifically, the verification module 3 is specifically:
[0058] The resource utilization rate is monitored in real time. When it is monitored that the resource utilization rate does not exceed the first threshold, a second instruction is sent to the individual SDK through the long connection. The individual SDK receives and closes local verification according to the second instruction, and forwards the token verification request to the account center for verification through the long connection when a token verification request is received.
[0059] Specifically, the token information includes a login token and an encryption key corresponding to the login token.
[0060] Specifically, the first threshold is [80,85].
[0061] Since the system / device described in the above embodiments of the present invention is a system / device used to implement the method of the above embodiments of the present invention, a person skilled in the art can understand the specific structure and deformation of the system / device based on the method described in the above embodiments of the present invention, and thus will not be described in detail here. All systems / devices used in the method of the above embodiments of the present invention belong to the scope of protection of the present invention.
[0062] It will be appreciated by those skilled in the art that embodiments of the present invention may be provided as methods, systems or computer program products. Therefore, the present invention may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Furthermore, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.
[0063] The present invention is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems) and computer program products according to the embodiments of the present invention. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions.
[0064] It should be noted that in the claims, any reference numerals placed between brackets shall not be construed as limiting the claims. The word "comprising" does not exclude the presence of components or steps not listed in the claims. The word "a" or "an" preceding a component does not exclude the presence of a plurality of such components. The invention may be implemented by means of hardware comprising several different components and by means of a suitably programmed computer. In the claims enumerating several means, several of these means may be embodied by the same hardware. The use of the words first, second, third, etc., is for convenience of expression only and does not indicate any order. These words may be understood as part of the component name.
[0065] In addition, it should be noted that, in the description of this specification, the description of the terms "one embodiment", "some embodiments", "embodiment", "example", "specific example" or "some examples" etc. means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present invention. In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described may be combined in any one or more embodiments or examples in a suitable manner. In addition, those skilled in the art may combine and combine the different embodiments or examples described in this specification and the features of the different embodiments or examples, unless they are contradictory.
[0066] Although the preferred embodiments of the present invention have been described, those skilled in the art may make other changes and modifications to these embodiments after knowing the basic creative concept. Therefore, the claims should be interpreted as including the preferred embodiments and all changes and modifications falling within the scope of the present invention.
[0067] Obviously, those skilled in the art can make various modifications and variations to the present invention without departing from the spirit and scope of the present invention. Thus, if these modifications and variations of the present invention fall within the scope of the claims of the present invention and their equivalents, the present invention should also include these modifications and variations.
Claims
1. A token verification method, characterized in that: include: Obtain the central SDK of the account center and the individual SDK of each server, and integrate all the individual SDKs into the central SDK to establish a persistent connection between the account center and each server; The resource utilization rate of the account center is obtained in real time, and it is determined whether the resource utilization rate exceeds a first threshold. If so, a first instruction is sent to the individual SDK through the long connection. The individual SDK receives and starts local verification according to the first instruction. The individual SDK stores the received token information in a local cache, and verifies through the local cache when receiving a token verification request. If not, the individual SDK forwards the token verification request to the account center through the long connection for verification when receiving the token verification request.
2. A token verification method as claimed in claim 1, characterized in that: The individual SDK stores the received token information in a local cache, and performs verification through the local cache upon receiving a token verification request, including: Determine whether token information corresponding to the token verification request exists in the local cache; if not, send a first request to the account center through the long connection to obtain token information corresponding to the token verification request, and store the obtained token information corresponding to the token verification request in the local cache for verification through the local cache; if exists, directly filter out the token information corresponding to the token verification request from the local cache for verification.
3. A token verification method as claimed in claim 1, characterized in that: The individual SDK stores the received token information in a local cache, and performs verification through the local cache upon receiving a token verification request, including: The resource utilization rate is monitored in real time. When it is monitored that the resource utilization rate does not exceed the first threshold, a second instruction is sent to the individual SDK through the long connection. The individual SDK receives and closes local verification according to the second instruction, and forwards the token verification request to the account center for verification through the long connection when a token verification request is received.
4. A token verification method as claimed in claim 1, characterized in that: The token information includes a login token and an encryption key corresponding to the login token.
5. A token verification method as claimed in claim 1, characterized in that: The first threshold is [80,85].
6. A token verification system, characterized in that: include: An acquisition module, used to acquire the central SDK of the account center and the individual SDK of each server, and integrate all the individual SDKs into the central SDK to establish a long connection between the account center and each server; A verification module is used to obtain the resource utilization rate of the account center in real time, and determine whether the resource utilization rate exceeds a first threshold. If so, a first instruction is sent to the individual SDK through the long connection. The individual SDK receives and starts local verification according to the first instruction. The individual SDK stores the received token information in a local cache, and verifies through the local cache when receiving a token verification request. If not, the individual SDK forwards the token verification request to the account center through the long connection for verification when receiving the token verification request.
7. A token verification system as claimed in claim 6, characterized in that: The verification module is specifically: Determine whether token information corresponding to the token verification request exists in the local cache; if not, send a first request to the account center through the long connection to obtain token information corresponding to the token verification request, and store the obtained token information corresponding to the token verification request in the local cache for verification through the local cache; if exists, directly filter out the token information corresponding to the token verification request from the local cache for verification.
8. A token verification module as claimed in claim 6, characterized in that: The verification module is specifically: The resource utilization rate is monitored in real time. When it is monitored that the resource utilization rate does not exceed the first threshold, a second instruction is sent to the individual SDK through the long connection. The individual SDK receives and closes local verification according to the second instruction, and forwards the token verification request to the account center for verification through the long connection when a token verification request is received.
9. A token verification module as claimed in claim 6, characterized in that: The token information includes a login token and an encryption key corresponding to the login token.
10. A token verification module as claimed in claim 6, characterized in that: The first threshold is [80,85].