Cluster permission authentication method, client, server and storage medium

Abstract

The embodiment of the present application discloses a method, client, server and storage medium for cluster authority authentication, which is used to reduce the risk of token leakage, while improving cluster authentication capabilities and reducing network consumption. The embodiment of the present application method includes: receiving a target business data request initiated by a client, the target business data request includes a user token, a current timestamp, a target request token and a current URL; when the current timestamp is within the allowed range of the valid request time, generating a current unique token according to the current timestamp and a preset encryption rule; when the target request token and the current request token are the same, obtaining the current user information corresponding to the user token; according to the current user information corresponding to the user token, obtaining the URL permission list corresponding to all roles to which the current user belongs; if the current URL is in the URL permission list, obtaining the target business data according to the target business data request; sending the target business data to the client.

Description

Technical Field

[0001] The present application relates to the field of information technology security, and in particular to a cluster authority authentication method, client, server, and storage medium. Background Art

[0002] With the rise of the internet, more and more application systems have emerged to provide services. When faced with high traffic volumes, these systems require cluster deployment to offload traffic and improve concurrency. Current solutions face numerous challenges, including identifying the user who requested a request and their permissions, quickly refreshing the logged-in user's permissions, and effectively intercepting leaks. Summary of the Invention

[0003] The embodiments of the present application provide a cluster authority authentication method, client, server, and storage medium, which are used to reduce the risk of token leakage, while improving cluster authentication capabilities and reducing network consumption.

[0004] In a first aspect, the present application provides a cluster authority authentication method, which may include:

[0005] The client initiates a target business data request to the server, wherein the target business data request includes a user token, a current timestamp, a target request token, and a current URL. The target request token is generated based on the current timestamp. The user token, the current timestamp, the target request token, and the current URL are used to obtain the target business data.

[0006] The client receives the target service data sent by the server.

[0007] A second aspect of the present application provides a cluster authority authentication method, which may include:

[0008] The server receives a target service data request initiated by the client, wherein the target service data request includes a user token, a current timestamp, a target request token, and a current URL, wherein the target request token is generated according to the current timestamp;

[0009] When the current timestamp is within the valid request time range, the server generates a current request token according to the current timestamp and a preset encryption rule;

[0010] When the target request token is the same as the current request token, the server obtains user information corresponding to the user token;

[0011] The server obtains the URL permission list corresponding to all roles to which the current user belongs from the cache center according to the current user information corresponding to the user token;

[0012] If the current URL is in the URL authority list, the server obtains the target business data according to the target business data request;

[0013] The server sends the target service data to the client.

[0014] A third aspect of the present application provides a client, which may include:

[0015] An initiating module, configured to initiate a target business data request to a server, wherein the target business data request includes a user token, a current timestamp, a target request token, and a current URL, wherein the target request token is generated based on the current timestamp, and the user token, the current timestamp, the target request token, and the current URL are used to obtain target business data;

[0016] A receiving module is used to receive the target service data sent by the server.

[0017] A fourth aspect of the present application provides a client, which may include:

[0018] A receiving module, configured to receive a target service data request initiated by a client, wherein the target service data request includes a user token, a current timestamp, a target request token, and a current URL, wherein the target request token is generated according to the current timestamp;

[0019] The processing module is configured to generate a current request token based on the current timestamp and a preset encryption rule if the current timestamp is within the permitted range of the valid request time; obtain user information corresponding to the user token if the target request token and the current request token are the same; obtain a URL permission list corresponding to all roles to which the current user belongs from a cache center based on the current user information corresponding to the user token; and obtain target business data according to the target business data request if the current URL is in the URL permission list;

[0020] A sending module is used to send the target service data to the client.

[0021] In another aspect, the present application provides a client, which may include:

[0022] a memory storing executable program code;

[0023] a transceiver coupled to the memory;

[0024] The transceiver is used to execute the method described in the first aspect of this application.

[0025] In another aspect, the present application provides a client, which may include:

[0026] a memory storing executable program code;

[0027] a transceiver and a processor coupled to the memory;

[0028] The transceiver and the processor are used to correspondingly execute the method as described in the second aspect of the present application.

[0029] Another aspect of an embodiment of the present application provides a computer-readable storage medium, comprising instructions, which, when executed on a processor, enable the processor to execute the method described in the first aspect or the second aspect of the present application.

[0030] Yet another aspect of an embodiment of the present application discloses a computer program product. When the computer program product is run on a computer, the computer is enabled to execute the method described in the first aspect or the second aspect of the present application.

[0031] Another aspect of an embodiment of the present application discloses an application publishing platform, which is used to publish a computer program product. When the computer program product runs on a computer, the computer executes the method described in the first aspect or the second aspect of the present application.

[0032] It can be seen from the above technical solutions that the embodiments of the present application have the following advantages:

[0033] In an embodiment of the present application, a client initiates a target service data request to a server. The target service data request includes a user token, a current timestamp, a target request token, and a current URL. The target request token is generated based on the current timestamp and is used to obtain the target service data. The client then receives the target service data sent by the server. This reduces the risk of token leakage, improves cluster authentication capabilities, and reduces network consumption. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following briefly introduces the drawings required for use in the embodiments and the description of the prior art. Obviously, the drawings described below are only some embodiments of the present application, and other drawings can be obtained based on these drawings.

[0035] Figure 1 This is a diagram of the system architecture used in the embodiments of the present application;

[0036] Figure 2 A schematic diagram of an embodiment of a method for cluster authority authentication in an embodiment of the present application;

[0037] Figure 3 Flowchart of the improved solution for login storage and request authentication;

[0038] Figure 4 Flowchart for role permission change and verification for this application;

[0039] Figure 5 This is a schematic diagram of an embodiment of a client in an embodiment of the present application;

[0040] Figure 6 This is a schematic diagram of an embodiment of the server in the embodiment of the present application;

[0041] Figure 7 This is another embodiment diagram of the client in the embodiment of the present application;

[0042] Figure 8 This is another schematic diagram of an embodiment of the server in the embodiment of the present application. DETAILED DESCRIPTION

[0043] The embodiments of the present application provide a cluster authority authentication method, client, server, and storage medium, which are used to reduce the risk of token leakage, while improving cluster authentication capabilities and reducing network consumption.

[0044] In order to enable those skilled in the art to better understand the present invention, the technical solutions in the embodiments of the present invention will be described below in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. All embodiments in the present invention should fall within the scope of protection of the present invention.

[0045] The following is a brief description of some of the terms involved in this application:

[0046] JWT, short for JSON Web Tokens, is a popular cross-domain authentication solution. It's a JSON-based token used to assert certain claims on the web. JWT authentication encrypts user information to generate a token. Each request to the server only needs to verify the correctness of the token using a stored key, eliminating the need to store any session data. This makes the server stateless and easily scalable.

[0047] In computer authentication, "token" means a temporary token, and in lexical analysis, it means a mark. It is generally used for invitations and login systems.

[0048] With the rise of the Internet, more and more application systems have emerged to provide services. When faced with large traffic flows, these systems also need to adopt cluster deployment to divert traffic and improve concurrency. How to identify the user that a request belongs to and what permissions they have? The currently known permission authentication solutions are as follows:

[0049] Based on the cookie-based session identification, after the client successfully logs in, the server binds the session to the cookie information; the client's subsequent requests carry the cookie information, and the server identifies the specific user based on the cookie.

[0050] Based on JWT, after the client successfully logs in, the server returns an encrypted token string containing user information and expiration time. The client then sends the token to subsequent requests. The server decrypts the token to identify the user and then obtains the user's specific permission information from the unified cache storage center.

[0051] Other token authentications are similar to JWT, but do not carry expiration time or user information, and the server does not need to decrypt them.

[0052] However, existing technical solutions face various drawbacks when facing large-volume client requests:

[0053] 1. Cookie-based solutions may fail to work on some clients that do not support cookies. If a unified session management center is not used for management, the cluster system will not be able to identify the specific logged-in user. Cookie data may also be forged. Currently, the cookie solution has been gradually abandoned by the industry.

[0054] 2. Although the JWT-based solution solves problems such as unified session identification and clustering, it increases network transmission information and increases network loss. In actual business use, a unified permission center is still required to access other information and permission lists of requesting users. It is impossible to put all this information into the JWT information. At the same time, the separate fixed expiration time of JWT is not conducive to rapid expiration and exit marking of users. The most critical thing is that after the token is leaked, the server cannot identify whether it is a legitimate request.

[0055] 3. Other token solutions also face the problem of being unable to identify illegal requests after token leakage.

[0056] 4. After successful authorization, if the user's corresponding role permissions are changed, if the existing solution does not modify the logged-in user's permission information in real time according to the role permission changes, it will lead to the security risk of expired permissions being used.

[0057] Based on the shortcomings of existing authentication schemes such as lack of cluster support, token leakage risk, and inability to quickly refresh permissions, this application takes cluster system permission authentication as the starting point and designs a dual-token three-stage permission verification scheme, providing a more secure and efficient permission authentication method. Figure 1 The following is a diagram of the system architecture used in the embodiment of the present application. Figure 1 The figure mainly describes the architectural approach for service cluster deployment. This application introduces a unified Cache Center (HC) to quickly store and access permission information. HC can utilize common caching middleware such as Redis. The overall process involves storing the user associated with the token and the permission associated with the role after a successful login. Upon subsequent requests, the user and permission information corresponding to the token is retrieved from the HC for authentication. When role permissions change, the corresponding role information in the HC is updated.

[0058] This application introduces HC to solve the problem of non-sharing of cluster deployment sessions encountered in some existing solutions; at the same time, the token information transmitted by this application is relatively short (for example, a dual token is usually less than 80 characters), unlike the existing jwt solution that carries a lot of information (for example, normal business requires at least more than 500 characters), thereby reducing network consumption during transmission; and storing tokens can also achieve the effect of invalidating tokens at any time, thereby improving security.

[0059] like Figure 2 FIG. 1 is a schematic diagram of an embodiment of a method for cluster authority authentication in an embodiment of the present application, which may include:

[0060] 201. The client sends a login request to the server, where the login request includes the login information of the current user.

[0061] The server receives a login request sent by the client, where the login request includes login information of the current user.

[0062] Optionally, the login information includes user information and role authority information.

[0063] For example, Figure 3 The figure shows the flow chart of the improved solution for logging in, storing and requesting authentication. Figure 3 As shown, if the client wants to request to obtain the server interface data, it must first perform login authentication. There are many specific login schemes here, such as: username + password + verification code login, mobile phone number + verification code login, three-party authorization login, etc., all of which can achieve the login effect. This application does not limit the specific login scheme.

[0064] 202. The server verifies the login information and generates a user token for the current user if the verification is successful.

[0065] After the client initiates a target business data request to the server with the login information (the URL (uniform resource locator) of the target business data request must exclude permission filtering), the server verifies whether the current login information is legal and correct. If the verification fails, an error message is prompted to the client; if the verification passes, the server generates a unique token Token (T1, also known as the user token) corresponding to the current user, stores the user information and permissions in the cache center HC, and returns T1 to the client.

[0066] Specific storage details such as Figure 4 As shown in the first node: the association between T1 and user information is stored, where the user information includes all role identifiers (IDs) owned by the current user. At the same time, if there is no corresponding role identifier information in the cache center, the URL permission information corresponding to the role identifier is queried and the URL permission list corresponding to the role ID is stored. This application uses the association between roles and permissions for storage, which is different from the traditional method of directly associating permission information with token information. It is mainly to consider that after subsequent role permissions are changed, the permissions of all users corresponding to the role can be quickly updated.

[0067] 203. The server sends a user token of the current user to the client, where the user token is used by the client to initiate a target service data request.

[0068] The client receives the user token of the current user sent by the server.

[0069] It can be understood that steps 201-203 can be considered as the login request phase B1: after the client successfully logs in, the server saves the user information and role permission information of the currently logged-in user, and then generates and returns a user token (T1) to the client, which can be stored locally on the client.

[0070] 204. The client initiates a target service data request to the server. The target service data request includes a user token, a current timestamp, a target request token, and a current URL. The target request token is generated according to the current timestamp.

[0071] The server receives a target service data request initiated by the client, wherein the target service data request includes a user token, a current timestamp, a target request token and a current URL, and the target request token is generated according to the current timestamp.

[0072] Optionally, the target request token is generated according to the current timestamp and the user token.

[0073] It is understood that before initiating a target service data request from the server, the client can generate a target request token based on the current timestamp, or generate a target request token based on the current timestamp and user token. The client then initiates a target service data request from the server, carrying the target request token. Regardless of whether the client generates the target request token based on the current timestamp or the current timestamp and user token, both generate the target request token based on the current timestamp and the agreed-upon encryption rules.

[0074] For example, after the client successfully logs in, it obtains T1, which needs to be stored locally. Subsequent target business data requests must carry this token value to identify the user's identity. Since T1 may be leaked during the transmission process, it may be illegally used during a long period of validity. Therefore, this application designs a dual token mechanism: when initiating a target business data request, T2 (target request token), the current timestamp (S1) and the current URL must also be transmitted. S1 is used to generate T2. The generation rules of T2 can be customized according to different clients, but S1 must be added. For example: T2 = md5 (S1 + T1 + fixed key), which means that after the character string is spliced according to the rules, it is encrypted using an irreversible encryption algorithm such as md5 to obtain a new character string Token (T2).

[0075] In the encryption rules of this application, the use of the current timestamp can effectively control the timeliness of the request and reduce the risk of leakage; the use of T1 can avoid the same T2 for different users; the use of a fixed key and splicing followed by MD5 irreversible encryption are all intended to increase the difficulty of algorithm guessing and reduce risks.

[0076] 205. When the current timestamp is within the allowed range of the valid request time, the server generates a current request token according to the current timestamp and a preset encryption rule.

[0077] It can be understood that after the server receives the target business data request from the client, it first determines whether the URL of the target business data request requires authorization verification. If not, it continues to obtain subsequent business data. If verification is required, T1, T2, and S1 are obtained from the target business data request. Among them, S1 is only used to calculate the string Z1 that should be generated according to the encryption rules. If any of T1, T2, and S1 is empty, it means that the request is illegal.

[0078] For example, the server first determines the timeliness of the request: based on the current timestamp S1 carried by the target business data request, it determines whether the target business data request time is within the allowed range of valid request time (customized). For example, if the server time S2-S1>3 seconds, or S2-S1<0 seconds, the target business data request is judged to be illegal, which is equivalent to a target business data request allowing a valid time of 0-3 seconds (including transmission delay time). If it does not meet the requirements, an error message is returned to the client. If it meets the requirements, proceed to the next step.

[0079] 206. When the target request token and the current request token are the same, the server obtains user information corresponding to the user token.

[0080] Exemplarily, the server determines that the second stage is T2 correctness judgment: based on S1 of the target business data request and the agreed encryption rules, generate the current request token Z1 (for example: Z1 = md5 (S1 + T1 + fixed key)), and judge whether the current request token Z1 is equal to the target request token T2 carried by the target business data request. Since the agreed encryption rules are used, it stands to reason that the current request token Z1 should be equal to the target request token T2. If they are not equal, it means that the data of the target business data request has been forged. If they are equal, proceed to the next step.

[0081] 207. The server obtains the URL permission list corresponding to all roles to which the current user belongs from the cache center according to the current user information corresponding to the user token.

[0082] 208. If the current URL is in the URL authority list, the server obtains target business data according to the target business data request.

[0083] Exemplarily, the server determines that the third stage is to verify URL permissions: obtain the user information corresponding to the user token T1. If the user login information is obtained and has not expired, continue to obtain the URL permissions corresponding to all roles to which the user belongs from the cache center, perform a union, and obtain a URL permission list corresponding to all roles. Then, determine whether the target business data request URL is in the role URL permission list. If so, continue with subsequent business data acquisition.

[0084] It can be seen that the server, through the above three steps, mainly uses the two tokens of user token T1 and target request token T2, combined with the request time limit of the target business data to judge the legitimacy of the request, and completes the permission verification process through the three-stage verification of the server, which can effectively solve the risk of token leakage. For example, the existing solution only transmits T1 and does not control the request time limit. After T1 is stolen, it will be used by the thief to forge data within the valid login time of T1 (not the request time limit, usually more than half an hour). This application uses dual-token three-stage authentication. If T1 is leaked, the thief cannot pass the verification. Even if T2 and S1 are also leaked, the time that can be used is only a few seconds. It can be seen that the technical solution of this application has greatly improved security compared to the current common permission system.

[0085] It is understandable that steps 204-208 can be considered as request verification phase B2:

[0086] Step B2-1: In addition to the token (T1) returned by B1, the client's subsequent target business data request must also carry the current timestamp (S1) and the token (T2) encrypted according to the agreed encryption rules and transmitted to the server; after receiving the request information, the server first verifies whether S1 is within the reasonable valid request time range, and then determines whether to continue the subsequent verification.

[0087] Step B2-2: The server encrypts a new string Z1 according to the agreed encryption rules and compares Z1 with the requested T2 to see if they are equal. Since the agreed encryption rules are used, Z1 should be equal to T2. If they are not equal, it means that the data requested by the target business data has been forged. If they are equal, proceed to the next step.

[0088] Step B2-3: After the legitimacy check succeeds, the server can continue to obtain the current user information and permission list from the unified permission cache center HC according to T1. Based on the current user information, the server can determine the timeliness of the login, and based on the permission list, it can determine whether it has the permission to the target request URL. If the authentication in this step is successful, the service data information can be obtained.

[0089] 209. The server sends the target service data to the client.

[0090] The client receives the target service data sent by the server.

[0091] Optionally, the method may further include: after detecting a change in role permissions, the server synchronously updates the cache center to obtain a URL permission list corresponding to all roles to which the current user belongs.

[0092] It can be understood that this implementation is equivalent to the permission change stage: when the role permission is changed, refreshing the permission cache information of the corresponding role in HC can quickly and promptly refresh the permissions of all users associated with the role.

[0093] For example, the specific steps of the improvement scheme for fast refresh during the permission change phase are as follows:

[0094] like Figure 4 The following is a flowchart of the role permission change and verification for this application. Figure 4 The figure shows the improved solution process for quickly refreshing permissions changes. HC stores the URL permission list corresponding to the role ID. When the URL permission corresponding to a role is modified, the server updates the corresponding role's permission list in HC in real time. This way, when a new request comes in, the permission list retrieved from HC during the third verification phase will contain the latest permissions available to the current user, preventing the issue of old permissions still being used.

[0095] In the existing technical solution, after the user logs in, the permissions are bound to T1. If the role permissions change, all users associated with the current role must be found. If there is no association between the user and T1, the permissions of the logged-in user of the current role cannot be updated, and the permissions can only be changed after re-login. If it is stored, it is necessary to traverse all T1s for a long update operation. Especially when there are many users, it is even more impossible to update permissions in time, resulting in the risk of expired permissions being used. This application is to associate through role transfer during the third stage of verification, so that the latest permission set can be obtained quickly and timely.

[0096] This application, based on cluster system authorization authentication, designs a dual-token, three-stage authorization verification scheme, providing a more secure and efficient authorization authentication method. Through the detailed description of the three improvements above, it can be seen that this application can enhance cluster authentication capabilities, reduce network consumption, reduce the risk of token leakage, and solve the problem of inability to quickly and timely update authorizations. This includes improvements to the login, verification, storage, request, and authentication phases, as well as improvements to the rapid refresh scheme during the authorization change phase.

[0097] like Figure 5 FIG. 1 is a schematic diagram of an embodiment of a client in an embodiment of the present application, which may include:

[0098] An initiating module 501 is configured to initiate a target business data request to a server, wherein the target business data request includes a user token, a current timestamp, a target request token, and a current URL. The target request token is generated based on the current timestamp, and the user token, the current timestamp, the target request token, and the current URL are used to obtain target business data.

[0099] The receiving module 502 is configured to receive the target service data sent by the server.

[0100] Optionally, the initiating module 501 is further configured to send a login request to the server, wherein the login request includes login information of the current user;

[0101] The receiving module 502 is further configured to receive a user token of the current user sent by the server.

[0102] Optionally, the target request token is generated according to the current timestamp and the user token.

[0103] like Figure 6 The figure is a schematic diagram of an embodiment of the server in the embodiment of the present application, which may include:

[0104] Receiving module 601, configured to receive a target service data request initiated by a client, wherein the target service data request includes a user token, a current timestamp, a target request token, and a current URL, wherein the target request token is generated according to the current timestamp;

[0105] Processing module 602 is configured to generate a current request token based on the current timestamp and preset encryption rules if the current timestamp is within the valid request time range; obtain user information corresponding to the user token if the target request token and the current request token are the same; obtain a URL permission list corresponding to all roles to which the current user belongs from a cache center based on the current user information corresponding to the user token; and obtain target business data according to the target business data request if the current URL is in the URL permission list;

[0106] The sending module 603 is configured to send the target service data to the client.

[0107] Optionally, the receiving module 601 is further configured to receive a login request sent by the client, where the login request includes login information of the current user;

[0108] The processing module 602 is further configured to verify the login information and, if the verification is successful, generate a user token for the current user;

[0109] The sending module 603 is further configured to send a user token of the current user to the client, where the user token is used by the client to initiate a target service data request.

[0110] Optionally, the processing module 602 is further configured to, after detecting a change in role permissions, synchronously update the cache center to obtain a URL permission list corresponding to all roles to which the current user belongs.

[0111] Optionally, the target request token is generated according to the current timestamp and the user token.

[0112] like Figure 7 FIG. 1 is a schematic diagram of another embodiment of the client in the embodiment of the present application, which may include:

[0113] A memory 701 storing executable program code;

[0114] a transceiver 702 coupled to the memory 701;

[0115] Transceiver 702 is used to initiate a target business data request to the server, wherein the target business data request includes a user token, a current timestamp, a target request token and a current URL, wherein the target request token is generated based on the current timestamp, and the user token, the current timestamp, the target request token and the current URL are used to obtain the target business data; and receive the target business data sent by the server.

[0116] Optionally, the transceiver 702 is further configured to send a login request to the server, where the login request includes login information of the current user; and receive a user token regarding the current user sent by the server.

[0117] Optionally, the target request token is generated according to the current timestamp and the user token.

[0118] like Figure 8 FIG. 1 is a schematic diagram of another embodiment of the server in the embodiment of the present application, which may include:

[0119] A memory 801 storing executable program code;

[0120] a transceiver 802 and a processor 803 coupled to the memory 801;

[0121] The transceiver 802 is configured to receive a target service data request initiated by a client, wherein the target service data request includes a user token, a current timestamp, a target request token, and a current URL, wherein the target request token is generated according to the current timestamp;

[0122] Processor 803 is configured to generate a current request token based on the current timestamp and preset encryption rules if the current timestamp is within the permitted range of the valid request time; obtain user information corresponding to the user token if the target request token and the current request token are the same; obtain a URL permission list corresponding to all roles to which the current user belongs from a cache center based on the current user information corresponding to the user token; and obtain target business data according to the target business data request if the current URL is in the URL permission list;

[0123] The transceiver 802 is configured to send the target service data to the client.

[0124] Optionally, the transceiver 802 is further configured to receive a login request sent by the client, where the login request includes login information of the current user;

[0125] The processor 803 is further configured to verify the login information and, if the verification is successful, generate a user token for the current user;

[0126] The transceiver 802 is further configured to send a user token of the current user to the client, where the user token is used by the client to initiate a target service data request.

[0127] Optionally, the processor 803 is further configured to, after detecting a change in role permissions, synchronously update the cache center to obtain a URL permission list corresponding to all roles to which the current user belongs.

[0128] Optionally, the target request token is generated according to the current timestamp and the user token.

[0129] In the above embodiments, all or part of the embodiments can be implemented by software, hardware, firmware, or any combination thereof. When implemented using software, all or part of the embodiments can be implemented in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of the present invention are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium can be any available medium that a computer can store or a data storage device such as a server or data center that includes one or more available media integrated therein. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state drive (SSD)).

[0130] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0131] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0132] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0133] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0134] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0135] As described above, the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the above embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the above embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A cluster authority authentication method, characterized in that: include: The client initiates a target business data request to the server, so that the server performs a dual-token three-stage authentication based on the target business data request; The target service data request includes a user token T1, a current timestamp S1, a target request token T2 and a current URL, wherein the target request token is generated according to the current timestamp, and the user token, the current timestamp, the target request token and the current URL are used to obtain the target service data; The user token is the unique token corresponding to the current user; The client receives the target service data sent by the server; The server performs dual-token three-stage authentication based on the target business data request, specifically including: The server determines the timeliness of the request: the server determines whether the target service data request time is within the valid request time range based on the current timestamp S1 carried by the target service data request. If the current timestamp is not within the valid request time range, the server returns an error message to the client; if the current timestamp is within the valid request time range, the server generates a current request token Z1 based on the current timestamp and preset encryption rules; The server verifies the correctness of the target request token T2: determines whether the current request token Z1 is equal to the target request token T2 carried in the target business data request; if the target request token T2 and the current request token Z1 are the same, the server obtains the user information corresponding to the user token T1; The server verifies URL permissions: obtains the user information corresponding to the user token T1. If the user login information is obtained and has not expired, it continues to obtain the URL permissions corresponding to all roles to which the user belongs from the cache center, performs a union, and obtains a URL permission list corresponding to all roles. It then determines whether the target business data request URL is in the role URL permission list; if the current URL is in the URL permission list, the server obtains the target business data according to the target business data request.

2. The method according to claim 1, characterized in that The method further comprises: The client sends a login request to the server, where the login request includes the login information of the current user; The client receives the user token of the current user sent by the server.

3. The method according to claim 1 or 2, characterized in that The target request token is generated according to the current timestamp and the user token.

4. A cluster authority authentication method, characterized in that: include: The server receives a target service data request initiated by the client, wherein the target service data request includes a user token T1, a current timestamp S1, a target request token T2, and a current URL. The target request token is generated according to the current timestamp. The user token is the unique token corresponding to the current user; The server determines the timeliness of the request: the server determines whether the target business data request time is within the valid request time range based on the current timestamp S1 carried by the target business data request. If the current timestamp is not within the valid request time range, the server returns an error message to the client. If the current timestamp is within the valid request time range, the server generates a current request token Z1 according to the current timestamp and the preset encryption rule; The server verifies the correctness of the target request token T2: Based on the current timestamp S1 of the target business data request and the agreed encryption rules, it generates the current request token Z1 and determines whether the current request token Z1 is equal to the target request token T2 carried by the target business data request; In the case that the target request token T2 is the same as the current request token Z1, the server obtains the user information corresponding to the user token T1; The server verifies URL permissions: obtains the user information corresponding to the user token T1. If the user login information is obtained and has not expired, it continues to obtain the URL permissions corresponding to all roles to which the user belongs from the cache center, performs a union, and obtains the URL permission list corresponding to all roles. It then determines whether the target business data request URL is in the role URL permission list. If the current URL is in the URL authority list, the server obtains the target business data according to the target business data request; The server sends the target service data to the client.

5. The method according to claim 4, characterized in that The method further comprises: The server receives a login request sent by the client, where the login request includes login information of the current user; The server verifies the login information and generates a user token for the current user if the verification is successful; The server sends a user token of the current user to the client, and the user token is used by the client to initiate a target service data request.

6. The method according to claim 4 or 5, characterized in that The method further comprises: After detecting the role permission change, the server synchronously updates the cache center to obtain the URL permission list corresponding to all roles to which the current user belongs.

7. The method according to claim 4 or 5, characterized in that The target request token is generated according to the current timestamp and the user token.

8. A client, characterized in that: include: The initiation module is used to initiate a target business data request to the server, so that the server performs a dual-token three-stage authentication according to the target business data request; The target service data request includes a user token T1, a current timestamp S1, a target request token T2 and a current URL; The target request token is generated according to the current timestamp, and the user token, the current timestamp, the target request token and the current URL are used to obtain target business data; The user token is the unique token corresponding to the current user; A receiving module, configured to receive the target service data sent by the server; The server performs dual-token three-stage authentication based on the target business data request, specifically including: The server determines the timeliness of the request: the server determines whether the target service data request time is within the valid request time range based on the current timestamp S1 carried by the target service data request. If the current timestamp is not within the valid request time range, the server returns an error message to the client; if the current timestamp is within the valid request time range, the server generates a current request token Z1 based on the current timestamp and preset encryption rules; The server verifies the correctness of the target request token T2: determines whether the current request token Z1 is equal to the target request token T2 carried in the target business data request; if the target request token T2 and the current request token Z1 are the same, the server obtains the user information corresponding to the user token T1; The server verifies URL permissions: obtains the user information corresponding to the user token T1. If the user login information is obtained and has not expired, it continues to obtain the URL permissions corresponding to all roles to which the user belongs from the cache center, performs a union, and obtains a URL permission list corresponding to all roles. It then determines whether the target business data request URL is in the role URL permission list; if the current URL is in the URL permission list, the server obtains the target business data according to the target business data request.

9. A server, characterized in that: include: A receiving module is configured to receive a target service data request initiated by a client, wherein the target service data request includes a user token T1, a current timestamp S1, a target request token T2, and a current URL, wherein the target request token is generated according to the current timestamp; The user token is the unique token corresponding to the current user; The authentication processing module is used to perform dual-token three-stage authentication based on the target business data request, specifically including: The server determines the timeliness of the request: the server determines whether the target service data request time is within the valid request time range based on the current timestamp S1 carried by the target service data request. If the current timestamp is not within the valid request time range, the server returns an error message to the client; if the current timestamp is within the valid request time range, the server generates a current request token Z1 based on the current timestamp and preset encryption rules; The server verifies the correctness of the target request token T2: determines whether the current request token Z1 is equal to the target request token T2 carried in the target business data request; if the target request token T2 and the current request token Z1 are the same, the server obtains the user information corresponding to the user token T1; The server verifies URL permissions: obtains the user information corresponding to the user token T1. If the user login information is obtained and has not expired, it continues to obtain the URL permissions corresponding to all roles to which the user belongs from the cache center, performs a union, and obtains a URL permission list corresponding to all roles. It then determines whether the target business data request URL is in the role URL permission list; if the current URL is in the URL permission list, the server obtains the target business data according to the target business data request; A sending module is used to send the target service data to the client.

10. A computer-readable storage medium comprising instructions, which, when executed on a processor, causes the processor to perform the method according to any one of claims 1 to 3, or any one of claims 4 to 7.

Images