An authentication method, authentication server, client, and storage medium

Abstract

This application provides an authentication method, authentication server, client, and storage medium. The method includes: obtaining a token to be authenticated; wherein the token to be authenticated is carried in a service request message sent by the client; when a token identical to the token to be authenticated is stored locally, authenticating the token to be authenticated based on locally pre-stored authentication information. Since the authentication server itself stores authentication information, the authentication process relies entirely on the authentication information pre-stored by the authentication server. Therefore, the token to be authenticated in the service request message sent by the client does not need to carry the aforementioned authentication information, thus ensuring that even if the token to be authenticated is intercepted by an attacker, the authentication information used for authentication will not be leaked, and the attacker cannot tamper with or use the authentication information.

Description

Technical Field

[0001] This application relates to the field of network security technology, and more specifically, to an authentication method, an authentication server, a client, and a storage medium. Background Technology

[0002] Token verification is a common server authentication method. The client stores the token issued by the server and carries the token for verification every time it makes a business request.

[0003] Currently, tokens carry authentication information such as user identifier, issuance time, validity period, number of uses, and permission information. Once a token is intercepted by an attacker, the authentication information it carries will be leaked. Attackers can easily tamper with and use the authentication information, which greatly affects network data security. Summary of the Invention

[0004] The purpose of this application is to provide an authentication method, authentication server, client, and storage medium to effectively address the threat to network data security posed by intercepted tokens.

[0005] This invention is implemented as follows:

[0006] In a first aspect, embodiments of this application provide an authentication method applied to an authentication server. The method includes: obtaining a token to be authenticated; wherein the token to be authenticated is carried in a business request message sent by a client; and when a token identical to the token to be authenticated is stored locally, authenticating the token to be authenticated based on locally pre-stored authentication information.

[0007] In this embodiment, since the authentication server stores its own authentication information, the authentication process relies entirely on this pre-stored information. Therefore, the authentication token in the client's service request message does not need to carry this authentication information. This ensures that even if the authentication token is intercepted by an attacker, the authentication information used for authentication will not be leaked, and the attacker cannot tamper with or use it. Furthermore, even if the authentication token in the client's service request message carries authentication information, this information is not used in the actual authentication process. Therefore, attackers cannot interfere with the authentication process, thus greatly ensuring network data security.

[0008] In conjunction with the technical solution provided in the first aspect above, in some possible implementations, the authentication information includes the number of times the token to be authenticated has been used, and the authentication of the token to be authenticated based on the locally pre-stored authentication information includes: authenticating the token to be authenticated based on the number of times the token to be authenticated has been used; wherein, if the number of times the token to be authenticated has been used is not less than a preset number, it indicates that the authentication has failed.

[0009] In this embodiment, the authentication server locally stores the number of times the token has been used, thereby enabling effective authentication of the token.

[0010] In conjunction with the technical solution provided in the first aspect above, in some possible implementations, when the number of times the token to be authenticated is used is less than the preset number of times, the method further includes: setting the validity period of the token to be authenticated based on the number of times the token to be authenticated is used; wherein the validity period of the token to be authenticated decreases as the number of times the token to be authenticated is used increases; and after the validity period of the token to be authenticated is reached, deleting the token that is the same as the token to be authenticated stored locally.

[0011] In this embodiment, the authentication server sets the validity period of the authentication token based on the number of times the authentication token is used, and deletes the locally stored token that is the same as the authentication token after the validity period is reached. This can effectively cope with extreme network conditions such as concurrent operations of clients.

[0012] In conjunction with the technical solution provided in the first aspect above, in some possible implementations, after the authentication token is successfully authenticated and the authentication token is being used for the first time, the method further includes: generating a sub-token based on the authentication token; sending the sub-token to the client, so that the client replaces the stored authentication token based on the sub-token.

[0013] In this embodiment of the application, by using the above-mentioned token update method, the token in the business request message sent by the client can be constantly changed, thereby further solving the threat to the authentication server caused by the interception of the token.

[0014] In conjunction with the technical solution provided in the first aspect above, in some possible implementations, the token to be authenticated includes version information, and the step of generating a sub-token based on the token to be authenticated includes: obtaining the version information of the token to be authenticated; constructing the sub-token, wherein the version information of the sub-token is obtained by calculating the version information of the token to be authenticated.

[0015] In conjunction with the technical solution provided in the first aspect above, in some possible implementations, the token to be authenticated includes a header field, a middle field, and a tail field. The header field includes user information, the middle field includes preset characters, and the tail field includes version information. Generating a sub-token based on the token to be authenticated includes: obtaining the user information, preset characters, and version information from the token to be authenticated; constructing the sub-token, wherein the header field of the sub-token includes the user information, the information in the middle field of the sub-token is obtained by calculating the preset characters and version information of the token to be authenticated using a preset algorithm, and the information in the tail field of the sub-token is obtained by calculating the version information of the token to be authenticated.

[0016] In this embodiment of the application, updating the middle field can increase the complexity of the update, thereby preventing attackers from cracking the update rules.

[0017] In conjunction with the technical solution provided in the first aspect above, in some possible implementations, the method further includes: determining whether a parent token corresponding to the token to be authenticated is stored locally; wherein the token to be authenticated is generated based on the parent token; if it exists, reducing the validity period of the parent token; when the usage period of the parent token reaches the reduced validity period, deleting the parent token stored locally.

[0018] In this embodiment, when the authentication server determines that a token to be authenticated is already in use, it can check whether the parent token of that token is stored locally. Since the token to be authenticated is essentially an updated token, the validity period of the parent token can be reduced to expiry as quickly as possible. This method allows the old token to be deleted promptly when a new token appears during the authentication process, further improving the security of the authentication process and reducing the threat to the authentication server if the parent token is intercepted.

[0019] In conjunction with the technical solution provided in the first aspect above, in some possible implementations, when the token to be authenticated is not being used for the first time, the method further includes: determining whether a sub-token corresponding to the token to be authenticated is stored locally; if it does not exist, generating the sub-token based on the token to be authenticated; and sending the sub-token to the client so that the client replaces the stored token to be authenticated based on the sub-token; if it exists, sending the sub-token to the client so that the client replaces the stored token to be authenticated based on the sub-token.

[0020] In this embodiment, when the token to be authenticated is not being used for the first time, the authentication server first determines whether a sub-token corresponding to the token to be authenticated has already been generated locally. If it does not exist, the sub-token is generated first and then sent to the client. If it exists, the sub-token is directly returned to the client. Through the above process, accurate updates to the token to be authenticated are achieved.

[0021] In conjunction with the technical solution provided in the first aspect above, in some possible implementations, before obtaining the authentication token, the method further includes: receiving a login request message sent by the client; wherein the login request message carries user information; generating an initial token based on the user information, and sending the initial token to the client; wherein the initial token is used by the client to carry in a business request message to be sent, so that the authentication server authenticates the initial token.

[0022] In this embodiment of the application, an initial token is generated based solely on user information, thereby ensuring that the token does not carry authentication information and thus preventing the leakage of authentication information.

[0023] In conjunction with the technical solution provided in the first aspect above, in some possible implementations, the step of generating an initial token based on the user information includes: generating dynamic characters based on the user information; generating an unencrypted initial token based on the user information; encrypting the unencrypted initial token based on a key composed of the dynamic characters and fixed characters to generate the initial token; wherein, the fixed characters are predetermined by the authentication server and the client.

[0024] Since each user's information is different, in this embodiment of the application, a unique key can be obtained by generating dynamic characters based on user information and combining them with fixed characters. The security of the token transmission process can be further enhanced by the unique key.

[0025] In conjunction with the technical solution provided in the first aspect above, in some possible implementations, the authentication information includes permission information, and the method further includes: changing the permission scope of the permission information of the user information corresponding to the authentication token.

[0026] By storing permission information locally on the authentication server, it becomes easier to manage user business functions.

[0027] Secondly, embodiments of this application provide an authentication method applied to a client. The method includes: sending a service request message to enable an authentication server to obtain a token to be authenticated carried in the service request message, and when the authentication server has a token identical to the token to be authenticated stored locally, authenticating the token to be authenticated based on locally stored authentication information.

[0028] In conjunction with the technical solution provided in the second aspect above, in some possible implementations, after sending the service request message, the method further includes: receiving a service response message; wherein the service response message carries a sub-token; wherein the sub-token is generated by the authentication server based on the token to be authenticated; and replacing the token to be authenticated stored in its own memory with the sub-token.

[0029] Thirdly, embodiments of this application provide an authentication device applied to an authentication server. The device includes: an acquisition module for acquiring a token to be authenticated; wherein the token to be authenticated is carried in a business request message sent by a client.

[0030] The authentication module is used to authenticate the token to be authenticated based on the authentication information pre-stored locally when a token identical to the token to be authenticated is stored locally.

[0031] Fourthly, this application provides an authentication device applied to a client. The device includes a sending module, configured to send a service request message so that the authentication server obtains the authentication token carried in the service request message, and when the authentication server has a token identical to the authentication token stored locally, authenticates the authentication token based on the authentication information stored locally.

[0032] Fifthly, embodiments of this application provide an authentication server, including: a processor and a memory, the processor and the memory being connected; the memory being used to store a program; the processor being used to invoke the program stored in the memory to execute the method provided by the embodiments of the first aspect described above and / or some possible implementations of the embodiments of the first aspect described above.

[0033] In a sixth aspect, embodiments of this application provide a client, including: a processor and a memory, the processor and the memory being connected; the memory being used to store a program; the processor being used to invoke the program stored in the memory to execute the method provided by the embodiments of the first aspect described above and / or some possible implementations of the embodiments of the first aspect described above.

[0034] In a seventh aspect, embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, the computer program executing the method provided in the first aspect embodiment or the second aspect embodiment when run by a processor.

[0035] Eighthly, embodiments of this application provide a computer program product, including a computer program / instructions, which are executed by a processor as described in the first aspect embodiment or the second aspect embodiment. Attached Figure Description

[0036] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0037] Figure 1 A flowchart illustrating the steps of the first authentication method provided in this application embodiment.

[0038] Figure 2 A flowchart illustrating the steps of the second authentication method provided in this application embodiment.

[0039] Figure 3 A flowchart illustrating the steps of the third authentication method provided in this application embodiment.

[0040] Figure 4 A flowchart illustrating the steps of the fourth authentication method provided in this application embodiment.

[0041] Figure 5 A flowchart illustrating the steps of the fifth authentication method provided in this application embodiment.

[0042] Figure 6 A block diagram of a first communication system provided in an embodiment of this application.

[0043] Figure 7 This is a block diagram of an authentication server provided in an embodiment of this application.

[0044] Figure 8 A block diagram of a second communication system provided in an embodiment of this application.

[0045] Icons: 10 - Communication System; 100 - Authentication Server; 110 - Processor; 120 - Memory; 200 - Client; 300 - Gateway; 400 - Business Server. Detailed Implementation

[0046] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0047] Please see Figure 1 The authentication method provided in this application includes steps S101-S103.

[0048] Step S101: The client sends a service request message.

[0049] The business request message carries an authentication token. This authentication token is provided by the authentication server. The authentication token can be placed in the request header of the business request message.

[0050] To facilitate understanding of this scheme, the process of obtaining the authentication token for the client will be explained first. Please refer to [link / reference]. Figure 2 The process includes steps S201 to S203.

[0051] Step S201: The client sends a login request message to the authentication server.

[0052] The login request message carries user information. This information may include the user ID (identity document) and the user password.

[0053] Step S202: The authentication server receives the login request message and generates an initial token based on the user information carried in it.

[0054] Upon receiving a login request message, the authentication server extracts user information. The server can first verify this information by checking if it exists in the database. If it does, it generates an initial token based on that information.

[0055] In this embodiment, the generated initial token includes the user information. The generated initial token may not include authentication information, which may include, but is not limited to, lifespan, usage count, and permission information. After generating the initial token, the authentication server locally stores the initial token and the authentication information corresponding to it. For example, it may retrieve the user's permission information from a database and store it locally, or it may set the lifespan of the initial token, for example, setting it to 15 days and storing it locally with a lifespan of 15 days.

[0056] In one embodiment, the initial token generated by the authentication server based on user information is an unencrypted token.

[0057] In another embodiment, to ensure the security of the initial token transmission, the token generation process may specifically include: generating dynamic characters based on user information; generating an unencrypted initial token based on user information; encrypting the unencrypted initial token based on a key composed of dynamic characters and fixed characters to generate the initial token.

[0058] It should be noted that the aforementioned fixed characters can be predetermined by the authentication server and the client. For example, the authentication server and the client determine the fixed characters when they first establish communication. The fixed characters are stored in the client and the authentication server respectively.

[0059] Since each user's information is unique, a unique key can be obtained by generating dynamic characters based on user information and combining them with fixed characters. This unique key can further enhance the security of the token transmission process.

[0060] The above-mentioned generation of dynamic characters based on user information can be achieved by extracting user information and then directly using the user information as dynamic characters, or by combining a random algorithm to process the user information and using the processed user information as dynamic characters. Of course, any existing algorithm can also be used to process the user information to obtain the dynamic characters, and this application does not limit it.

[0061] Of course, in other embodiments, the authentication server and the client may predetermine fixed characters as the key for encryption, and this application does not limit this.

[0062] In addition, when the login request message sent by the client is transmitted, it will first pass through the gateway, where the gateway will perform authentication. If it is found that the login request message does not need to be authenticated (this can be identified through the interface, such as the login request message passing through the authorization interface), the login request message will be allowed to pass directly, and then the login request message will be forwarded to the authentication server.

[0063] Step S203: The authentication server sends the initial token to the client.

[0064] Finally, the authentication server sends the initial token to the client. For example, the authentication server can construct a login response message and then put the initial token in the response header of the login response message.

[0065] After receiving the login response message, the client extracts the initial token from the response header and saves the initial token locally.

[0066] It should be noted that when the initial token is encrypted, the client first generates dynamic characters based on its own user information, and then combines these with a pre-determined fixed character set by the authentication server as a key for decryption. Finally, the decrypted initial token is saved locally.

[0067] When the client sends a service request message next time, it will put the initial token into the request header of the service request message. The initial token put into the request header of the service request message can be the authentication token in step S101.

[0068] Step S102: The authentication server obtains the authentication token carried in the business request message.

[0069] After the client sends a service request message carrying a token to be authenticated, the authentication server uses it to obtain the token to be authenticated carried in the service request message.

[0070] Please see Figure 3 It should be noted that during the transmission of the business request message sent by the client, it will first be intercepted by the gateway, which will then perform authentication. When the gateway recognizes that the business request message is a message that requires authentication, it will extract the token to be authenticated from the business request message and send the token to be authenticated to the authentication server so that the authentication server can obtain the token to be authenticated.

[0071] In this approach, the gateway can determine whether a message requires authentication by checking if the request header contains an authentication token. Alternatively, the gateway can identify the interface receiving the service request message as one that requires authentication, thus determining whether the message needs authentication in this way.

[0072] It should be noted that the gateway does not forward business request messages before receiving the authentication result from the authentication server.

[0073] Step S103: When the authentication server determines that there is a token that is the same as the token to be authenticated stored locally, it authenticates the token to be authenticated based on the authentication information pre-stored locally.

[0074] After receiving the token to be authenticated, the authentication server first checks whether it has a token that is identical to the token to be authenticated stored locally. If it does not exist, it means that the authentication has failed. At this time, it returns an error code to the client to indicate that the authentication has failed.

[0075] Specifically, the authentication server first sends the error code to the gateway. After receiving the error code, the gateway forwards it to the client. At this time, the transmission of the business request message is interrupted, and the gateway will not forward it to the corresponding business server.

[0076] When the authentication server determines that it has a token that matches the one to be authenticated in its local storage, it then authenticates the token based on the authentication information pre-stored locally. If authentication is successful, it sends an authentication success indication to the gateway, causing the gateway to forward the service request message to the corresponding service server.

[0077] As can be seen from the embodiments of this application, since the authentication server itself stores authentication information, the authentication process relies entirely on the authentication information pre-stored by the authentication server. Therefore, the authentication token in the business request message sent by the client does not need to carry the aforementioned authentication information. Consequently, even if the authentication token is intercepted by an attacker, the authentication information used for authentication will not be leaked, and the attacker cannot tamper with or use the authentication information. Furthermore, even if the authentication token in the business request message sent by the client carries authentication information, the authentication information carried by the authentication token will not be used in the actual authentication process. Therefore, attackers cannot interfere with the authentication process, thereby greatly ensuring network data security.

[0078] In one embodiment, the pre-stored authentication information is the number of times it has been used. The authentication server can specifically authenticate the token to be authenticated based on the locally pre-stored authentication information by: authenticating the token to be authenticated based on the number of times it has been used.

[0079] Specifically, when the authentication server determines that it has a token identical to the one to be authenticated in its local storage, it determines the number of times the token to be authenticated has been used based on the locally stored identical tokens. For example, the authentication server can count the usage information of the tokens stored locally; that is, whenever the authentication server obtains a token to be authenticated that is identical to the one stored locally, it increments the usage information of the identical token by one. For example, if the token to be authenticated is A, and assuming that the authentication server also stores token A locally, it will extract the usage information of token A. For example, if the usage information of token A is 10 times, then the number of times the token to be authenticated has been used is determined to be 10 times.

[0080] The authentication process involves several steps. If the number of times the authentication token has been used is not less than a preset number, authentication fails, and an error code is returned to the client. Conversely, if the number of times the authentication token has been used is less than the preset number, authentication succeeds. If authentication is successful, the authentication server can send a success notification to the gateway, allowing the gateway to forward the service request message to the corresponding service server.

[0081] The preset number of times mentioned above can be set according to actual needs. For example, the preset number of times can be twenty or thirty times. This application does not limit it.

[0082] In one embodiment, when the number of times the token to be authenticated is used is less than a preset number, the method further includes: setting an effective duration for the token to be authenticated based on the number of times it is used; and deleting the token that is the same as the token to be authenticated stored locally after the effective duration has been reached.

[0083] The validity period of the authentication token decreases as the number of times the authentication token is used increases.

[0084] For example, if the authentication token is used for the first time, the validity period can be set to one hour; if the authentication token is used for the second time, the validity period can be set to five minutes; if the authentication token is used for the third time, the validity period can be set to one minute, and so on.

[0085] The rules for setting the number of uses mentioned above can be customized according to actual needs. For example, the effective duration of each subsequent use can be half the effective duration of the previous use. Following this rule, the usage duration can be set to 40 minutes, 20 minutes, 10 minutes, 5 minutes, and so on. Of course, the difference between two adjacent effective durations can also be a fixed value. Following this rule, the usage duration can be set to 40 minutes, 35 minutes, 30 minutes, 25 minutes, and so on.

[0086] After setting the validity period of the token to be authenticated, the authentication server can monitor the usage time of identical tokens stored locally in real time. When the usage time reaches the validity period, the token will be deleted. Once the authentication server deletes the token locally, subsequent attempts to obtain an identical token to be authenticated will fail.

[0087] It should be noted that in this embodiment of the application, the validity period of the authentication token is set by the number of times the authentication token is used, and after the validity period of the authentication token is reached, the tokens stored locally that are the same as the authentication token are deleted. This can effectively cope with extreme network conditions such as concurrent operations of the client.

[0088] In one embodiment, this application also provides a method for dynamically updating tokens. Specifically, after the token to be authenticated is successfully authenticated and it is being used for the first time, the method further includes: the authentication server generating a sub-token based on the token to be authenticated; and sending the sub-token to the client, so that the client replaces the stored token to be authenticated based on the sub-token.

[0089] It should be noted that the sub-token generated based on the token to be authenticated carries information about the token to be authenticated, and the token to be authenticated acts as the parent token of the sub-token. After the authentication server sends the sub-token to the client, the client needs to replace its own stored token. Subsequently, when the client constructs a business request message, it includes the new, replaced token in the business request message.

[0090] Of course, the sub-token generated by the authentication server can be an unencrypted token or an encrypted token. The specific encryption method can be found in the processing of the initial token. To avoid redundancy, it will not be elaborated here.

[0091] As can be seen, by updating the token as described above, the token in the business request message sent by the client can be constantly changed, thereby further mitigating the threat to the authentication server caused by the interception of the token.

[0092] It should be noted that the above-described method of dynamically updating tokens is combined with the scheme of setting the validity period of the token to be authenticated in the aforementioned embodiments. Since the token is continuously updated during the authentication process, even if the client receives an authentication failure result for a business request message, it can first determine whether it has received an updated token. If so, it can use the updated token to reconstruct the business request message, without having to resend the login request message to the authentication server to obtain a new initial token. Furthermore, by combining these two methods, the entire process continuously involves generating new tokens and deleting old ones. Therefore, even if an attacker intercepts a token at a certain time, it can only be used for a short period.

[0093] It should be noted that after the authentication server determines the token to be authenticated and generates a sub-token, it sends the sub-token to the gateway. The gateway can then add the sub-token to the request header of the business request message. The original request message's header now contains the token to be authenticated, which the gateway has now extracted. The gateway then forwards the business request message to the corresponding business server. Next, when the gateway receives the business response message from the business server, it forwards it to the client. This response message also contains the sub-token in its request header. Upon receiving the response message, the client extracts the sub-token from its request header and checks if it matches the token it already stores. If they don't match, the client replaces the sub-token.

[0094] In one embodiment, each token includes version information. Therefore, the token can be updated based on the version information. Specifically, the authentication server generates a sub-token based on the token to be authenticated, which can specifically include: the authentication server obtaining the version information of the token to be authenticated; and then constructing the sub-token, wherein the version information of the sub-token is obtained by calculating the version information of the token to be authenticated.

[0095] The above calculation method can be auto-incrementing. For example, if the version information of the token to be authenticated includes a version number, and the version number is 111, then the version number in the sub-token's version information will be the version number 111 plus a preset value. For example, if the preset value is 1, then the version number in the sub-token's version information will be 112. Of course, the preset value can also be 111, in which case the version number in the sub-token's version information will be 222.

[0096] After the token is updated in the above manner, the client, upon receiving the business response message, compares the version information of the sub-token in the request header of the business response message with the version information of the token stored in its own memory. If they do not match, the client replaces the stored token with the sub-token; if they match, no replacement is required.

[0097] The above calculation method can also employ other methods, and these methods can also process other characters in the version information. For example, if the version information of the token to be authenticated is A111, after the above calculation, the version information of the sub-token is B222. This application does not limit this.

[0098] In one embodiment, the token includes a header field, a middle field, and a tail field. The header field includes user information, the middle field includes preset characters, and the tail field includes version information.

[0099] Of course, the header fields may also include platform information corresponding to the user information, which is not limited in this application.

[0100] In the initial token, the preset characters can be generated by a fixed algorithm, and the preset characters can have a specific length. For example, if the fixed algorithm is a random algorithm, a fixed-length string generated by the random algorithm will be used to fill the middle field. During subsequent token updates, the preset characters in the middle field and the version information in the tail field will both be updated.

[0101] Specifically, the authentication server generates a sub-token based on the token to be authenticated, which may include: obtaining user information, preset characters, and version information from the token to be authenticated; constructing the sub-token, wherein the header field of the sub-token includes user information, the information in the middle field of the sub-token is obtained by calculating the preset characters and version information of the token to be authenticated using a preset algorithm, and the information in the tail field of the sub-token is obtained by calculating the version information of the token to be authenticated.

[0102] It should be noted that the header fields of a child token can inherit information from the header fields of its parent token.

[0103] The information in the middle field of the child token is calculated from the preset characters in the middle field of the parent token and the version information in the tail field. The calculation process uses a preset algorithm. For example, the preset algorithm can be a character replacement algorithm, such as replacing the first three characters in the preset characters in the middle field with the three characters in the version information in the tail field. This application does not limit this.

[0104] The update method for the tail field of the sub-token through version information can be referred to the description in the foregoing embodiments, and will not be repeated here to avoid redundancy.

[0105] As can be seen, updating the middle field as described above increases the complexity of the update process, thus preventing attackers from cracking the update rules.

[0106] After the token is updated in the above manner, the client, upon receiving the business response message, compares the tail field of the sub-token in the request header of the business response message with the tail field of its own stored token. If they do not match, the client replaces its own stored token with the sub-token.

[0107] Optionally, when a token identical to the token to be authenticated is stored locally, the authentication method provided in this application embodiment may further include: the authentication server determining whether a parent token corresponding to the token to be authenticated is stored locally; wherein the token to be authenticated is generated based on the parent token; if it exists, the validity period of the parent token is reduced; when the usage period of the parent token reaches the reduced validity period, the parent token stored locally is deleted.

[0108] In other words, when the authentication server determines that a token to be authenticated is already in use, it can check whether the parent token of that token is stored locally. Since the token to be authenticated is essentially an updated token, the validity period of the parent token can be shortened to make it expire as quickly as possible. This method allows the old token to be deleted promptly when a new token appears during the authentication process, further improving the security of the authentication process and reducing the threat to the authentication server if the parent token is intercepted.

[0109] In the above process, the validity period of the parent token can be reduced to a specific duration, such as 5 seconds or 10 seconds. Alternatively, the validity period of the parent token can be reduced by a specific duration; for example, if the original validity period of the parent token was 1 minute, it can be reduced by 20 seconds, resulting in a validity period of 40 seconds.

[0110] Optionally, when the token to be authenticated is not being used for the first time, the method further includes: the authentication server determining whether a sub-token corresponding to the token to be authenticated is stored locally; if it does not exist, generating a sub-token based on the token to be authenticated; and sending the sub-token to the client so that the client can replace the stored token to be authenticated based on the sub-token; if it exists, sending the sub-token to the client so that the client can replace the stored token to be authenticated based on the sub-token.

[0111] It should be noted that when the token to be authenticated is not being used for the first time, the authentication server will first check whether a sub-token corresponding to the token to be authenticated has already been generated locally. If it does not exist, the sub-token will be generated first and then sent to the client. If it exists, the sub-token will be returned directly to the client. Through this process, accurate updates to the token to be authenticated are achieved.

[0112] In addition, when the authentication server determines that a child token corresponding to the token to be authenticated has already been generated locally, the token to be authenticated can be used as the parent token, which can reduce the validity period of the parent token so that it expires as soon as possible.

[0113] It should be noted that the pre-stored authentication information may also include at least one or more of the following: lifecycle, number of uses, and permission information; this application does not impose any limitations on this.

[0114] Among them, the lifecycle is mainly used to determine whether the token has expired, and the permission information is mainly used to manage the user's access permission scope.

[0115] When the pre-stored authentication information includes permission information, the method includes: the authentication server changing the permission scope of the permission information of the user information corresponding to the authentication token.

[0116] It should be noted that the authentication server can be used to receive modification instructions issued by users, and then change the permission scope of the user information corresponding to the authentication token. As a result, when the user's permission information changes, the user's business functions will be restricted. In other words, by storing permission information locally on the authentication server, it is more convenient to manage the user's business functions.

[0117] Furthermore, this application embodiment also provides a deregistration mechanism. The client can initiate a token deregistration request. Upon receiving the request, the authentication server retrieves the token from the request header, extracts the user information from the token header, identifies the user, and then clears the entire token chain (including the corresponding parent and child tokens) stored locally. The client then also clears its locally stored tokens. Subsequently, the client needs to log in again to obtain the initial token before it can initiate business requests.

[0118] Please see Figure 4 The authentication method provided in this application embodiment will now be described from the authentication process of the authentication server.

[0119] First, the authentication server obtains the token to be authenticated. Then, it checks if a token identical to the token to be authenticated is stored locally. If no token identical to the token to be authenticated is stored locally, authentication fails. If a token identical to the token to be authenticated is stored locally, the server retrieves the number of times the token to be authenticated has been used.

[0120] Then, it is determined whether the number of times the token to be authenticated has been used is less than the preset number. If the number of times it has been used is not less than the preset number, authentication fails, and the parent token of the token to be authenticated is deleted (if it exists). If the number of times it has been used is less than the preset number, the validity period of the token to be authenticated is set based on the number of times it has been used.

[0121] Then, determine whether a parent token corresponding to the token to be authenticated is stored locally; if it exists, reduce the validity period of the parent token.

[0122] Then, it is determined whether a sub-token corresponding to the token to be authenticated is stored locally; if it does not exist, a sub-token is generated based on the token to be authenticated; and the sub-token is sent to the client so that the client can replace the stored token to be authenticated based on the sub-token; if it exists, the sub-token is sent to the client so that the client can replace the stored token to be authenticated based on the sub-token.

[0123] Please see Figure 5 Based on the same inventive concept, this application also provides an authentication method, which is applied alone in an authentication server. The method includes: steps S301-S302.

[0124] Step S301: Obtain the authentication token; wherein, the authentication token is carried in the business request message sent by the client.

[0125] Step S301: When a token identical to the token to be authenticated is stored locally, authenticate the token to be authenticated based on the authentication information pre-stored locally.

[0126] Since the specific processes of steps S301-S302 have been described in the foregoing embodiments, the same parts can be referred to each other, and will not be repeated here.

[0127] Based on the same inventive concept, embodiments of this application also provide an authentication method, which is applied independently to a client. The method includes: sending a service request message to enable an authentication server to obtain the authentication token carried in the service request message; and, when the authentication server locally stores a token identical to the authentication token, authenticating the authentication token based on locally stored authentication information.

[0128] Optionally, after sending the service request message, the method further includes: receiving a service response message; wherein the service response message carries a sub-token; wherein the sub-token is generated by the authentication server based on the token to be authenticated; and replacing the token to be authenticated stored in its own memory with the sub-token.

[0129] Since the specific process of the above steps has been described in the foregoing embodiments, the same parts can be referred to each other, and will not be repeated here.

[0130] Based on the same inventive concept, this application also provides an authentication device, which is applied to the authentication server in the above embodiments. The device includes: an acquisition module and an authentication module.

[0131] The acquisition module is used to acquire the authentication token to be authenticated; wherein the authentication token to be authenticated is carried in the business request message sent by the client.

[0132] The authentication module is used to authenticate the token to be authenticated based on the authentication information pre-stored locally when a token identical to the token to be authenticated is stored locally.

[0133] Optionally, the authentication information includes the number of times the token to be authenticated has been used. The authentication module is specifically used to authenticate the token to be authenticated based on the number of times it has been used; wherein, if the number of times the token to be authenticated has been used is not less than a preset number, it indicates that authentication has failed.

[0134] Optionally, the device further includes a processing module. The processing module is configured to, when the number of times the token to be authenticated is used is less than the preset number, set the validity period of the token to be authenticated based on the number of times it is used; wherein the validity period of the token to be authenticated decreases as the number of times it is used increases; and after the validity period of the token to be authenticated is reached, delete locally stored tokens identical to the token to be authenticated.

[0135] Optionally, the device further includes a dynamic update module. The dynamic update module is used to generate a sub-token based on the unauthenticated token after successful authentication and when the unauthenticated token is being used for the first time; and to send the sub-token to the client, so that the client replaces the stored unauthenticated token based on the sub-token.

[0136] Optionally, the dynamic update module is further specifically used to obtain the version information of the token to be authenticated; and to construct the sub-token, wherein the version information of the sub-token is obtained by calculating the version information of the token to be authenticated.

[0137] Optionally, the token to be authenticated includes a header field, a middle field, and a tail field. The header field includes the user information, the middle field includes preset characters, and the tail field includes version information. The dynamic update module is further specifically used to obtain the user information, preset characters, and version information from the token to be authenticated; and to construct the sub-token, wherein the header field of the sub-token includes the user information, the information in the middle field of the sub-token is obtained by calculating the preset characters and version information of the token to be authenticated using a preset algorithm, and the information in the tail field of the sub-token is obtained by calculating the version information of the token to be authenticated.

[0138] Optionally, the processing module is further configured to determine whether a parent token corresponding to the token to be authenticated is stored locally; wherein the token to be authenticated is generated based on the parent token; if it exists, the validity period of the parent token is reduced; when the validity period of the parent token reaches the reduced validity period, the parent token stored locally is deleted.

[0139] Optionally, the dynamic update module is further configured to determine whether a sub-token corresponding to the token to be authenticated is stored locally; if it does not exist, the sub-token is generated based on the token to be authenticated; and the sub-token is sent to the client so that the client can replace the stored token to be authenticated based on the sub-token; if it exists, the sub-token is sent to the client so that the client can replace the stored token to be authenticated based on the sub-token.

[0140] Optionally, the device further includes a token generation module. The token generation module is used to receive a login request message sent by the client before obtaining the authentication token; wherein the login request message carries user information; generate an initial token based on the user information, and send the initial token to the client; wherein the initial token is used by the client to include in a service request message to be sent, so that the authentication server authenticates the initial token.

[0141] The token generation module is used to generate dynamic characters based on the user information; generate an unencrypted initial token based on the user information; encrypt the unencrypted initial token based on a key composed of the dynamic characters and fixed characters to generate the initial token; wherein, the fixed characters are predetermined by the authentication server and the client.

[0142] Optionally, the authentication information includes permission information, and the processing module is further specifically used to change the permission scope of the permission information of the user information corresponding to the authentication token.

[0143] Please see Figure 6 This application provides a communication system 10, including an authentication server 100 and a client 200.

[0144] Communication connection between authentication server 100 and client 200.

[0145] The authentication server 100 is mainly used to handle the login permission control business of the client 200. In this embodiment of the application, the authentication server 100 is specifically used to obtain the token to be authenticated; wherein, the token to be authenticated is carried in the business request message sent by the client 200; and when it has a token identical to the token to be authenticated stored, it authenticates the token to be authenticated based on the pre-stored authentication information.

[0146] It should be noted that, in this embodiment, the authentication server 100 stores its own authentication information. For example, the authentication information may include at least one of lifecycle, usage count, and permission information. Since the authentication process is entirely handled by the authentication information pre-stored by the authentication server 100, the authentication token in the business request message sent by the client may not carry the aforementioned authentication information. This ensures that even if the authentication token is intercepted by an attacker, the authentication information will not be leaked, and the attacker will not be able to tamper with or use the authentication information.

[0147] Please see Figure 7 , Figure 7 This is a schematic diagram of the structure of the authentication server 100 provided in an embodiment of this application. Structurally, the authentication server 100 may include a processor 110 and a memory 120.

[0148] The processor 110 is electrically connected directly or indirectly to the memory 120 to enable data transmission or interaction. For example, these components can be electrically connected to each other via one or more communication buses or signal lines. The authentication device includes at least one software module that can be stored in the memory 120 or embedded in the operating system (OS) of the authentication server 100 in the form of software or firmware. The processor 110 is used to execute executable modules stored in the memory 120, such as software function modules and computer programs included in the authentication device, to implement the authentication method. The processor 110 can execute the computer program after receiving an execution instruction.

[0149] The processor 110 can be an integrated circuit chip with signal processing capabilities. The processor 110 can also be a general-purpose processor, such as a Central Processing Unit (CPU), a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a discrete gate or transistor logic device, or a discrete hardware component, capable of implementing or executing the methods, steps, and logic block diagrams disclosed in the embodiments of this application. Furthermore, the general-purpose processor can be a microprocessor or any conventional processor.

[0150] The memory 120 may be, but is not limited to, random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), and electrically erasable programmable read-only memory (EEPROM). The memory 120 is used to store programs, which the processor 110 executes upon receiving an execution instruction.

[0151] It should be noted that, Figure 7 The structure shown is for illustrative purposes only. The authentication server 100 provided in this embodiment may also have more advanced features. Figure 7 Fewer or more components, or having the same Figure 7 The different configurations shown. Furthermore... Figure 7 The components shown can be implemented through software, hardware, or a combination thereof.

[0152] The client 200 is mainly used to send login requests to the authentication server 100 and business requests to the business server. When the client 200 sends a business request to the business server, the business request message carries a token so that the authentication server 100 can perform authentication.

[0153] The client 200 may specifically include a personal computer, tablet computer, mobile phone, etc. Structurally, the client 200 may also include a processor and memory. The specific structure of the client can be referred to the description of the authentication server 100 above, and will not be repeated in this application.

[0154] Please see Figure 8 Optionally, the communication system 10 also includes a gateway 300 and a service server 400.

[0155] Gateway 300 is connected to authentication server 100, client 200, and business server 400. That is, authentication server 100 and client 200 communicate through gateway 300, and client 200 and business server 400 also communicate through gateway 300.

[0156] Among them, the business server 400 is mainly used to respond to the business requests of the client 200 and send the requested business data to the client 200.

[0157] Gateway 300 is mainly used for forwarding messages, and when it receives a service request message from a client, it extracts the authentication token carried in the service request message and sends the authentication token to authentication server 100 for authentication.

[0158] It should be noted that, as those skilled in the art will clearly understand, for the sake of convenience and brevity, the specific working processes of the systems, devices and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0159] Based on the same inventive concept, this application also provides a computer program product, including computer program instructions, which are read and executed by a processor to perform the method provided in the above embodiments.

[0160] Based on the same inventive concept, embodiments of this application also provide a computer-readable storage medium storing a computer program thereon, which executes the methods provided in the above embodiments when the computer program is run.

[0161] The storage medium can be any available medium that a computer can access, or a data storage device such as a server or data center that integrates one or more available media. The available medium can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state drives (SSDs)).

[0162] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some communication interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0163] Furthermore, the units described as separate components may or may not be physically separate. 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 the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0164] Furthermore, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0165] In this document, relational terms such as first and second are used only to distinguish one entity or operation from another entity or operation, without necessarily requiring or implying any such actual relationship or order between these entities or operations.

[0166] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. An authentication method characterized by, The method is applied to an authentication server, and comprises the following steps: acquiring a token to be authenticated; wherein the token to be authenticated is carried by a service request message sent by a client; when a token identical to the token to be authenticated is stored locally, authenticating the token to be authenticated based on authentication information pre-stored locally; after the token to be authenticated is authenticated successfully and the token to be authenticated is used for the first time, generating a sub-token based on the token to be authenticated; and sending the sub-token to the client, so that the client replaces the stored token to be authenticated based on the sub-token; the sub-token carries information of the token to be authenticated; when the token to be authenticated is not used for the first time, judging whether a sub-token corresponding to the token to be authenticated is stored locally; if not, generating the sub-token based on the token to be authenticated; and sending the sub-token to the client, so that the client replaces the stored token to be authenticated based on the sub-token; if yes, sending the sub-token to the client, so that the client replaces the stored token to be authenticated based on the sub-token; judging whether a parent token corresponding to the token to be authenticated is stored locally; wherein the token to be authenticated is generated based on the parent token; if yes, reducing an effective time length of the parent token; and when a use time length of the parent token reaches the reduced effective time length, deleting the parent token stored locally.

2. The method of claim 1, wherein, the authentication information comprises a use frequency of the token to be authenticated, and the authenticating the token to be authenticated based on the authentication information pre-stored locally comprises: authenticating the token to be authenticated based on the use frequency of the token to be authenticated; wherein when the use frequency of the token to be authenticated is not less than a preset frequency, it is represented that the authentication fails.

3. The method of claim 2, wherein, when the use frequency of the token to be authenticated is less than the preset frequency, the method further comprises: setting an effective time length of the token to be authenticated based on the use frequency of the token to be authenticated; wherein the effective time length of the token to be authenticated decreases with the increase of the use frequency of the token to be authenticated; after the use time length of the token to be authenticated reaches the effective time length, deleting a token identical to the token to be authenticated stored locally.

4. The method of claim 1, wherein, the token to be authenticated comprises version information, and the generating a sub-token based on the token to be authenticated comprises: acquiring the version information of the token to be authenticated; constructing the sub-token, wherein the version information of the sub-token is obtained by calculating the version information of the token to be authenticated.

5. The method of claim 1, wherein, the token to be authenticated comprises a head field, a middle field and a tail field; the head field comprises user information; the middle field comprises preset characters; and the tail field comprises version information; and the generating a sub-token based on the token to be authenticated comprises: acquiring the user information, the preset characters and the version information in the token to be authenticated; constructing the sub-token, wherein a head field of the sub-token includes the user information, information of a middle field of the sub-token is obtained by performing a preset algorithm on preset characters and version information of the to-be-authenticated token, and information of a tail field of the sub-token is obtained by performing calculation on version information of the to-be-authenticated token.

6. The method of claim 1, wherein, Before the obtaining of the to-be-authenticated token, the method further includes: receiving a login request message sent by the client; wherein the login request message carries user information; generating an initial token based on the user information, and sending the initial token to the client; wherein the initial token is used to be carried by the client to a to-be-sent service request message, so that the authentication server authenticates the initial token.

7. The method of claim 6, wherein, The generating of the initial token based on the user information includes: generating a dynamic character based on the user information; generating an unencrypted initial token based on the user information; encrypting the unencrypted initial token based on a secret key composed of the dynamic character and a fixed character to generate the initial token; wherein the fixed character is determined in advance by the authentication server and the client.

8. The method according to any one of claims 1-7, characterized in that, The authentication information includes permission information, and the method further includes: changing a permission range of the permission information of the user information corresponding to the to-be-authenticated token.

9. An authentication method characterized by, Applied to a client, the method includes: sending a service request message, so that an authentication server obtains a to-be-authenticated token carried by the service request message, and authenticates the to-be-authenticated token based on locally stored authentication information when the authentication server locally stores a token identical to the to-be-authenticated token; after the sending of the service request message, receiving a service response message; wherein the service response message carries a sub-token; wherein the sub-token is generated by the authentication server based on the to-be-authenticated token; replacing the to-be-authenticated token stored by the client with the sub-token; the sub-token carries information of the to-be-authenticated token. The authentication server is configured to: when the to-be-authenticated token is not used for the first time, judging whether a sub-token corresponding to the to-be-authenticated token is locally stored; if not, generating the sub-token based on the to-be-authenticated token; and sending the sub-token to the client, so that the client replaces the stored to-be-authenticated token based on the sub-token; if yes, sending the sub-token to the client, so that the client replaces the stored to-be-authenticated token based on the sub-token; judging whether a parent token corresponding to the to-be-authenticated token is locally stored; wherein the to-be-authenticated token is generated based on the parent token; if yes, reducing an effective time length of the parent token; when a use time length of the parent token reaches the reduced effective time length, deleting the parent token stored locally.

10. An authentication server, characterized by including: a processor and a memory, the processor and the memory being connected; the memory is configured to store a program; the processor is configured to run the program stored in the memory to execute the method in any one of claims 1-8.

11. A client, characterized in that, including: a processor and a memory, which are connected; the memory is configured to store a program; the processor is configured to execute the program stored in the memory to perform the method of claim 9.

12. A computer-readable storage medium, characterized in that, a computer program which, when executed by a computer, performs the method of any one of claims 1-8, or the computer program which, when executed by a computer, performs the method of claim 9.

13. A computer program product comprising computer programs / instructions, characterized in that, the computer program / instructions, when executed by a processor, perform the method of any one of claims 1-8, or the computer program / instructions, when executed by a processor, perform the method of claim 9.

Images