CN111654379B - Multi-server unified token generation method and authentication method - Google Patents
Multi-server unified token generation method and authentication method Download PDFInfo
- Publication number
- CN111654379B CN111654379B CN202010512036.3A CN202010512036A CN111654379B CN 111654379 B CN111654379 B CN 111654379B CN 202010512036 A CN202010512036 A CN 202010512036A CN 111654379 B CN111654379 B CN 111654379B
- Authority
- CN
- China
- Prior art keywords
- token
- server
- time point
- generating
- tokens
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
- H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Computer And Data Communications (AREA)
Abstract
The application relates to a multi-server unified token generation method, an authentication method, computer equipment and a storage medium. The method for generating the unified token of the multiple servers comprises the following steps: after receiving a token request message sent by a client, a first server generates a first token according to a current time point and a preset keyword, and stores the time point for generating the first token; the first server sends the first token to the client, notifies a second server associated with the first server to generate a plurality of second tokens, and stores time points for generating the plurality of second tokens, wherein the second server is used for respectively generating the plurality of second tokens according to each time point and a preset keyword in a first preset range before and after the current time point, and the time points in the first preset range before and after the current time point comprise the time points for generating the first tokens. By the method and the device, the problems that tokens of multi-server unified authentication are not unified and the consistency of the tokens is low are solved.
Description
Technical Field
The present application relates to the field of computer technologies, and in particular, to a method and an apparatus for generating a unified token for multiple servers, a method and an apparatus for authenticating the unified token, a computer device, and a computer-readable storage medium.
Background
In the field of computer technology, a token is commonly used to complete the connection between a client and a server, and the client can access services after the token passes through the token.
The deployment scene of the multi-server is more and more widely applied. In order to realize the problem of unified login of multiple servers, a method of authenticating a token, that is, performing multi-server authentication through a unified token, is proposed in the prior art to realize unified login. However, the existing unified token storage method is implemented by storing tokens in third-party devices and third-party servers, and the third-party storage method has the problems of insecurity of tokens and inconsistency of tokens of the servers.
At present, no effective solution is provided for the problems of non-uniformity of tokens and low token consistency of multi-server uniform authentication in the related technology.
Disclosure of Invention
The embodiment of the application provides a multi-server unified token generation method, a multi-server unified token authentication method, computer equipment and a computer readable storage medium, so as to at least solve the problems of non-unified token and low token consistency of multi-server unified authentication in the related art.
In a first aspect, an embodiment of the present application provides a method for generating a unified token for multiple servers, including:
after receiving a token request message sent by a client, a first server generates a first token according to a current time point and a preset keyword, and stores the time point for generating the first token;
the first server sends the first token to the client, and notifies a second server associated with the first server to generate a plurality of second tokens and stores time points for generating the plurality of second tokens, wherein the second server is configured to generate the plurality of second tokens respectively according to each time point in a first preset range before and after a current time point and the preset keyword, and the time points in the first preset range before and after the current time point include the time points for generating the first token.
In some embodiments, the method for generating a unified token for multiple servers further includes: and the first server informs a second server associated with the first server of generating a plurality of second tokens according to a server list, wherein the first server asynchronously acquires the server list after generating the first token.
In a second aspect, an embodiment of the present application provides a method for generating a unified token for multiple servers, including:
the multi-server generates a first token and a second token by using the unified token generation method of the multi-server in the first aspect; the unified token authentication method of the multiple servers comprises the following steps:
a first server receives a service request message sent by a client, wherein the service request message carries a third token of the client;
the first server matches a fourth token corresponding to the third token in the locally stored first tokens;
under the condition that the fourth token is matched, the first server judges whether the time difference between the time point of generating the fourth token and the current time point is within a preset time difference interval or not, wherein the preset time difference interval is determined according to a first preset time difference value and a second preset time difference value;
the first server allows the client to call the service requested by the service request message under the condition that the time difference between the time point of generating the fourth token and the current time point is within a preset time difference interval, and updates the current time point to the time point of generating the fourth token;
the first server notifies a second server associated with the first server of a point in time at which the second token was generated by the synchronization update.
In some embodiments, the method for unified token authentication for multiple servers further comprises: and the first server refuses the client to call the service requested by the service request message under the condition that the time difference between the time point of generating the fourth token and the current time point is larger than the first preset time difference value.
In some embodiments, the method for unified token authentication for multiple servers further comprises: and allowing the client to call the service requested by the service request message by the first server under the condition that the time difference between the time point of generating the fourth token and the current time point is smaller than the second preset time difference value.
In some embodiments, the first server matching, among the locally stored first tokens, a fourth token corresponding to the third token comprises: and the first server matches the fourth token in a token matching code, wherein the token matching code comprises a plurality of first tokens in a second preset range before and after the current time point selected from the first tokens stored locally in the first server.
In some embodiments, the method for unified token authentication of multiple servers further comprises:
after receiving a service request message sent by a client, the second server matches a fifth token corresponding to the third token in second tokens stored locally;
under the condition that the fifth token is matched, the second server judges whether the time difference between the time point of generating the fifth token and the current time point is within the preset time difference interval or not;
and the second server allows the client to call the service requested by the service request message and updates the current time point to the time point for generating the fifth token when the time difference between the time point for generating the fifth token and the current time point is judged to be within the preset time difference interval.
In some embodiments, the method for unified token authentication of multiple servers further comprises: and the second server refuses the client to call the service requested by the service request message when judging that the time difference between the time point of generating the fifth token and the current time point is greater than the first preset time difference value.
In a third aspect, embodiments of the present application provide a computer device, including a memory, a processor, and a computer program stored on the memory and executable on the processor, where the processor, when executing the computer program, implements the multi-server unified token generation method according to the first aspect, and/or the multi-server unified token authentication method according to the second aspect.
In a fourth aspect, embodiments of the present application provide a computer-readable storage medium, on which a computer program is stored, which when executed by a processor implements the multi-server unified token generation method according to the first aspect, and/or the multi-server unified token authentication method according to the second aspect.
Compared with the related art, the multi-server unified token generation method, the authentication method, the computer device and the computer readable storage medium provided by the embodiment of the application generate the first token according to the current time point and the preset keyword by the first server after receiving the token request message sent by the client, and store the time point for generating the first token; the first server sends the first token to the client, and notifies a second server associated with the first server to generate a plurality of second tokens, and stores time points for generating the plurality of second tokens, wherein the second server is used for respectively generating the plurality of second tokens according to each time point and a preset keyword in a first preset range before and after a current time point, and the time points in the first preset range before and after the current time point comprise the time points for generating the first tokens. By the method and the device, the problems of non-uniformity of tokens and low token consistency of multi-server unified authentication in the related technology are solved, and the beneficial effects of ensuring token consistency and consistency of the multi-server through a synchronous time point mechanism are achieved.
The details of one or more embodiments of the application are set forth in the accompanying drawings and the description below to provide a more concise and understandable description of the application, and features, objects, and advantages of the application.
Drawings
The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this application, illustrate embodiment(s) of the application and together with the description serve to explain the application and not to limit the application. In the drawings:
FIG. 1 is a flow chart of a multi-server unified token generation method according to an embodiment of the present application;
FIG. 2 is a flow diagram of a method for unified token authentication for multiple servers according to an embodiment of the application;
FIG. 3 is a flow diagram of unified token generation, authentication, according to a preferred embodiment of the present application;
FIG. 4 is a block diagram of a unified token generation apparatus for multiple servers according to an embodiment of the present application;
FIG. 5 is a block diagram of a unified token authentication apparatus for multiple servers according to an embodiment of the present application;
fig. 6 is a hardware configuration diagram of a computer device according to an embodiment of the present application.
Detailed Description
In order to make the objects, technical solutions and advantages of the present application more clearly understood, the present application is described and illustrated below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the present application and are not intended to limit the present application. All other embodiments obtained by a person of ordinary skill in the art based on the embodiments provided in the present application without any inventive step are within the scope of protection of the present application.
It is obvious that the drawings in the following description are only examples or embodiments of the present application, and that it is also possible for a person skilled in the art to apply the present application to other similar contexts on the basis of these drawings without inventive effort. Moreover, it should be appreciated that in the development of any such actual implementation, as in any engineering or design project, numerous implementation-specific decisions must be made to achieve the developers' specific goals, such as compliance with system-related and business-related constraints, which may vary from one implementation to another.
Reference in the specification to "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment can be included in at least one embodiment of the specification. The appearances of the phrase in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. It is to be expressly and implicitly understood by one of ordinary skill in the art that the embodiments described herein may be combined with other embodiments without conflict.
Unless defined otherwise, technical or scientific terms referred to herein shall have the ordinary meaning as understood by those of ordinary skill in the art to which this application belongs. Reference to "a," "an," "the," and similar words throughout this application are not to be construed as limiting in number, and may refer to the singular or the plural. The present application is directed to the use of the terms "including," "comprising," "having," and any variations thereof, which are intended to cover non-exclusive inclusions; for example, a process, method, system, article, or apparatus that comprises a list of steps or modules (elements) is not limited to the listed steps or elements, but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus. Reference to "connected," "coupled," and the like in this application is not intended to be limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect. The term "plurality" as referred to herein means two or more. "and/or" describes an association relationship of associated objects, meaning that three relationships may exist, for example, "A and/or B" may mean: a exists alone, A and B exist simultaneously, and B exists alone. The character "/" generally indicates that the former and latter associated objects are in an "or" relationship. Reference herein to the terms "first," "second," "third," and the like, are merely to distinguish similar objects and do not denote a particular ordering for the objects.
The embodiment provides a unified token generation method for multiple servers. Fig. 1 is a flowchart of a method for generating a unified token for multiple servers according to an embodiment of the present application, where the flowchart includes the following steps, as shown in fig. 1:
step S101, after receiving a token request message sent by a client, a first server generates a first token according to a current time point and a preset keyword, and stores the time point for generating the first token.
In this embodiment, after the first server generates the first token, the first token is stored locally in the first server, and the storage of the first token may be stored through a token list.
The time for the first server to generate the token may be short, and the current time of the first server may also be regarded as the time for generating the first token. Meanwhile, the keywords in this embodiment are keywords stored on each server when multiple servers are deployed, and the keywords stored by each server are the same. The keyword may be one or more character strings or a keyword, for example, a website or a name may be selected. The consistency and the uniformity of tokens generated by the multiple servers are ensured by setting the same keywords.
Step S102, the first server sends the first token to the client, and notifies a second server associated with the first server to generate a plurality of second tokens, and stores time points for generating the plurality of second tokens, wherein the second server is configured to generate the plurality of second tokens respectively according to each time point and a preset keyword in a first preset range before and after a current time point, and the time points in the first preset range before and after the current time point include time points for generating the first token.
In this embodiment, after receiving the notification of generating the second token, the second server obtains a plurality of time points in a first preset range before and after the current time point, and then generates the second token according to each time point and the preset keyword, where the number of the second tokens generated by the second server is multiple. The current point in time of the second server is a different point in time than the current point in time of the first server. Of course, the interval between the current time point of the second server and the current time point of the first server is not too long. In a specific application scenario, the interval between the current time point of the second server and the current time point of the first server may not exceed one second.
In some embodiments, the length of the first preset range may be determined according to the number of servers of the multi-server system, and the minimum unit of the time point may be seconds. For example, when a multi-server deployment is performed, the length of the first preset range may be set according to the time length required by the multiple servers to complete token generation, that is, it is at least ensured that the multiple servers can complete token generation within the first preset range before and after the current time point, and the time points before and after the current time point are considered for performing error correction when an error exists in the time point.
Through the steps S101 to S102, after receiving a token request message sent by a client, a first server generates a first token according to a current time point and a preset keyword, and stores a time point for generating the first token; the first server sends the first token to the client, and notifies a second server associated with the first server to generate a plurality of second tokens, and saves points in time for generating the plurality of second tokens. By synchronizing the time points, the problems that tokens of multi-server unified authentication are not unified and the consistency of the tokens is low are solved, and the beneficial effects that the tokens of the multi-server are kept consistent and the consistency of the tokens is high are achieved.
In some embodiments, the method for generating the unified token of the multi-server implements the following steps:
and the first server informs a second server associated with the first server to generate a plurality of second tokens according to the server list, wherein the first server asynchronously acquires the server list after generating the first token.
In this embodiment, the token is generated by the second server using the server list. Of course, in some embodiments, the token generated by the second server or the token stored locally may also be a token synchronized (sent) by another second server. That is, after receiving the notification from the first server, the other second servers generate a second token and send a second token to all the other second servers, and the second server, upon receiving the second token, can form a plurality of second tokens equivalent to the second server respectively generating a plurality of second tokens according to each time point and the preset keyword within the first preset range before and after the current time point.
In this embodiment, a multi-token matching mechanism is adopted, and when one first server generates a token, a plurality of second servers associated with the first server are enabled to synchronously generate corresponding tokens. The consistency and unity of the tokens of all servers in a cluster formed by a first server and a plurality of second servers is guaranteed.
The embodiment provides a unified token authentication method for multiple servers. Fig. 2 is a flowchart of a multi-server unified token authentication method according to an embodiment of the present application. As shown in fig. 2, the process includes the following steps:
step S201, the first server generates a first token according to the current time point and a preset keyword, and stores the time point for generating the first token.
Step S202, the first server sends the first token to the client, and notifies a second server associated with the first server to generate a plurality of second tokens, and saves time points for generating the plurality of second tokens.
Step S203, the first server receives a service request message sent by the client, where the service request message carries a third token of the client.
In this embodiment, the third token of the client is carried in the service request message and is the first token or the second token that is generated and issued by the first server or the second server according to the token obtaining request of the client.
In step S204, the first server matches a fourth token corresponding to the third token in the locally stored first token.
Step S205, in a case that the fourth token is matched, the first server determines whether a time difference between a time point of generating the fourth token and a current time point is within a preset time difference interval, where the preset time difference interval is determined according to the first preset time difference value and the second preset time difference value.
In this embodiment, a preset time difference interval is set, so as to determine whether the login time of the third token (the token in the client service request message) exceeds the set time, and if the login time exceeds the set time, the third token needs to be acquired again.
In step S206, the first server allows the client to invoke the service requested by the service request message and update the current time point to the time point at which the fourth token is generated, when it is determined that the time difference between the time point at which the fourth token is generated and the current time point is within the preset time difference interval.
In this embodiment, when the time difference between the time point of the fourth token and the current time point is within the preset time difference interval, it indicates that the fourth token is available, but the aging of the fourth token needs to be updated. By comparing the time points of the token, the timeliness of the token is guaranteed. In some embodiments, the preset time difference interval is often set to half an hour, and if the token does not log in for half an hour, it is necessary to request the server to generate a new token again. And for the token on the login, the consistent login is kept, and the limitation of the login time length is not preset.
In step S207, the first server notifies a second server associated with the first server of a time point at which the second token is generated by the synchronous update.
In this embodiment, the servers are enabled to synchronously update the aging of the token through a synchronous time point mechanism.
Through the steps S201 to S207, the consistency and the uniformity of the tokens of each server are ensured by adopting a synchronous time mechanism and a multi-token matching mechanism; the token is stored locally in the server, so that the problem that the token is unsafe due to the fact that the token is stored in a third party in the related technical field is solved, the token is safely stored, and meanwhile, the timeliness of the token is guaranteed through comparison of the generation time points of the token.
In some embodiments, the method for authenticating the unified token of the multi-server further implements the following steps:
and the first server refuses the client to call the service requested by the service request message under the condition that the time difference between the time point of generating the fourth token and the current time point is larger than a first preset time difference value.
It should be understood that, when the time difference between the time point of generating the fourth token and the current time point is greater than the first preset time difference value, it indicates that the token has exceeded the set time for logging in, and at this time, the client needs to request the server to generate the token again.
In some embodiments, the method for authenticating the unified token of the multi-server further implements the following steps: and the first server allows the client to call the service requested by the service request message under the condition that the time difference between the time point of generating the fourth token and the current time point is smaller than a second preset time difference value.
In this embodiment, the token is allowed to log in by determining the existence time of the fourth token, that is, the time difference between the time point of generating the fourth token and the current time point is smaller than the lower limit value of the preset time difference interval, that is, the second preset time difference value, and the aging of the token does not need to be changed.
In some embodiments, the first server matching a fourth token corresponding to the third token among the locally stored first tokens comprises: and the first server matches the fourth token in a token matching code, wherein the token matching code comprises a plurality of first tokens in a second preset range before and after the current time point selected from the first tokens stored locally in the first server.
Specifically, when a client requests to access a service, the server extracts a token from the access service request, and then obtains a first token in a set time around a current time point from a first token stored locally in the server as a fourth token matched with the token. Certainly, the set time is set according to the number of the servers, in this embodiment, 10 seconds are set before and after the current time point, and in some other application scenarios, the first token with a time interval different from the current time point interval may be set and acquired as the fourth token matched with the token carried by the client according to the requirement.
In some embodiments, the method for authenticating the unified token of the multi-server further implements the following steps:
and 11, after receiving the service request message sent by the client, the second server matches a fifth token corresponding to the third token in the locally stored second tokens. In this embodiment, the fifth token actually corresponds to one of the second tokens.
And step 22, under the condition that the fifth token is matched, the second server judges whether the time difference between the time point of generating the fifth token and the current time point is within a preset time difference interval.
And step 33, allowing the client to call the service requested by the service request message and update the current time point to the time point for generating the fifth token by the second server under the condition that the time difference between the time point for generating the fifth token and the current time point is judged to be within the preset time difference interval.
After a synchronous time mechanism is adopted, a plurality of servers generate a unified token, when a client requests to access the service of a second server, whether a third token of the client meets a required token or not is verified, then the login timeliness of a fifth token corresponding to the third token is verified through token time point comparison, and if the login timeliness of the fifth token meets the set requirement, the third token can be adopted for login. Of course, if the log-in time period is satisfied, it is necessary to verify whether or not the generation time point of the fifth token (second token) needs to be updated, and if it is verified that the update is necessary, the generation time of the fifth token is updated (the generation time point of the corresponding second token existing locally in the second server is updated).
In some embodiments, the unified token authentication method for multiple servers further implements the following steps: and the second server refuses the client to call the service requested by the service request message under the condition that the time difference between the time point of generating the fifth token and the current time point is larger than the first preset time difference value.
In this embodiment, when the second server determines that the time difference between the generation time point of the fifth token (substantially the second token) and the current time point is greater than the first preset time difference, it indicates that the third token has exceeded the set time and is not logged in, and the generation token needs to be acquired again to perform the verification and login steps.
Fig. 3 is a flowchart of unified token generation and authentication according to the preferred embodiment of the present application. As shown in fig. 3, the process includes the following steps:
in step S301, the client sends a request for obtaining a token to a first server (one of the multiple servers).
Step S302, the first server receives the request of the client, calculates the md5 value according to the current time point and the keyword stored in the first server, and generates the first token, the first server stores the first token locally and records the time point of generation of the first token, and then step S303 and step S304 are executed.
Step S303, the first token is issued to the client, and then step S307 is executed.
In step S304, the first server notifies the second server to generate the second token according to the asynchronously obtained server list, and then step S305 is performed.
Step S305, the second server determines whether the request for obtaining the token is a service IP in its service list, if yes, step S306 is executed, otherwise, the token generation process is ended.
Step S306, the second server combines 20 time points of 10 seconds before and after the current time point is obtained with the keywords stored by the second server to generate 20 md5 second tokens, and the second server stores the second tokens in the second server and records the generation time points of the second tokens.
Step S307, the client sends a service request carrying the third token to the first server.
Step S308, the first server compares the third token and determines whether the third token is in the token list locally stored in the first server. If so, step S309 is performed, otherwise, token verification is ended.
In step S309, the first server determines a generation time point of the fourth token corresponding to the third token.
And step S310, judging whether the difference value between the generation time point of the fourth token and the current time point exceeds 30min, if so, ending the token verification, otherwise, executing step S311.
Step S311, determining whether the difference between the generation time point of the fourth token and the current time point is less than 5min, if yes, executing step S312, otherwise, executing step S313.
Step S312, the client is allowed to invoke the service requested by the service request message.
Step 313, judging whether the difference value between the generation time point of the fourth token and the current time point is between 5min and 30min, if so, executing step 314, otherwise, ending the token verification.
In step S314, the generation time point of the fourth token is updated, and then step S315 is performed.
In step S315, the first server notifies the second server of synchronously updating the generation time point of the second token corresponding to the fourth token according to the server list, and then, step S316 is executed.
In step S316, the second server determines whether the request for obtaining the token is a service IP in its service list, if so, step S317 is executed, otherwise, an exception is returned.
Step S317, the second server compares the third token and determines whether the third token is in the token list locally stored in the second server. If so, step S318 is performed, otherwise, a token error is returned.
In step S318, the second server determines the generation time point of the compared fifth token corresponding to the third token, and then performs S319.
Step S319, determining whether the difference between the generation time point of the fifth token and the current time point exceeds 30min, if yes, returning to token timeout, otherwise, executing step S320.
And step S320, judging whether the difference value between the generation time point of the fifth token and the current time point is between 5min and 30min, if so, executing step S321, otherwise, returning to the token error.
Step S321, allowing the client to invoke the service requested by the service request message, and updating the generation time point of the fifth token.
The present embodiment further provides a multi-server unified token generation apparatus, which is used to implement the foregoing embodiments and preferred embodiments, and the description of the apparatus is omitted here. As used hereinafter, the terms "module," "unit," "subunit," and the like may implement a combination of software and/or hardware for a predetermined function. Although the means described in the embodiments below are preferably implemented in software, an implementation in hardware, or a combination of software and hardware is also possible and contemplated.
Fig. 4 is a block diagram of a multi-server unified token generation apparatus according to an embodiment of the present application, and as shown in fig. 4, the apparatus includes:
a first generating module 41, configured to generate, by the first server, a first token according to the current time point and a preset keyword, and store the time point for generating the first token;
the first processing module 42 is configured to send the first token to the client by the first server, notify a second server associated with the first server to generate a plurality of second tokens, and store time points for generating the plurality of second tokens, where the second server is configured to generate the plurality of second tokens respectively according to each time point and a preset keyword in a first preset range before and after a current time point, and the time points in the first preset range before and after the current time point include time points for generating the first token.
In some embodiments, the first processing module 42 is configured to notify, by the first server, a second server associated with the first server to generate a plurality of second tokens according to the server list, wherein the first server asynchronously obtains the server list after generating the first token.
The present embodiment further provides a unified token authentication apparatus with multiple servers, where the apparatus is used to implement the foregoing embodiments and preferred embodiments, and the description of the apparatus is omitted here. As used hereinafter, the terms "module," "unit," "subunit," and the like may implement a combination of software and/or hardware for a predetermined function. Although the means described in the embodiments below are preferably implemented in software, an implementation in hardware, or a combination of software and hardware is also possible and contemplated.
Fig. 5 is a block diagram of a multi-server unified token authentication apparatus according to an embodiment of the present application, and as shown in fig. 5, the apparatus includes:
the first generating module 51 is configured to generate a first token according to the current time point and a preset keyword, and store the time point for generating the first token.
A second processing module 52, configured to send the first token to the client by the first server, notify a second server associated with the first server to generate a plurality of second tokens, and store time points for generating the plurality of second tokens.
The obtaining module 53 is configured to receive, by the first server, a service request message sent by the client, where the service request message carries a third token of the client.
And a first matching module 54, configured to match, by the first server, a fourth token corresponding to the third token in the locally stored first token.
The first determining module 55 is configured to, in a case that the fourth token is matched, determine, by the first server, whether a time difference between a time point of generating the fourth token and a current time point is within a preset time difference interval, where the preset time difference interval is determined according to a first preset time difference value and a second preset time difference value.
The third processing module 56 is configured to, when determining that the time difference between the time point of generating the fourth token and the current time point is within the preset time difference interval, the first server allows the client to invoke the service requested by the service request message, and update the current time point to the time point of generating the fourth token.
A synchronization module 57 for the first server to inform a second server associated with the first server of a point in time at which the synchronization update generated the second token.
In some embodiments, the third processing module 56 is configured to, when determining that the time difference between the time point of generating the fourth token and the current time point is greater than the first preset time difference value, refuse the client to invoke the service requested by the service request message.
In some embodiments, the third processing module 56 is further configured to allow the client to invoke the service requested by the service request message, when the first server determines that the time difference between the time point of generating the fourth token and the current time point is smaller than the second preset time difference value.
In some of these embodiments, matching module 54 includes:
and the first matching unit is used for the first server to match the fourth token in the token matching code, wherein the token matching code comprises a plurality of first tokens in a second preset range before and after the current time point selected from the first tokens stored locally in the first server.
In some embodiments, the multi-server unified token authentication apparatus includes:
and the second matching module is used for matching a fifth token corresponding to the third token in the second tokens stored locally by the second server.
And the second judging module is used for judging whether the time difference between the time point for generating the fifth token and the current time point is within the preset time difference interval or not by the second server.
And the fourth processing module is used for allowing the client to call the service requested by the service request message and updating the current time point to the time point for generating the fifth token when the second server judges that the time difference between the time point for generating the fifth token and the current time point is within the preset time difference interval.
In some embodiments, the fourth processing module is configured to, when determining that the time difference between the time point at which the fifth token is generated and the current time point is greater than the first preset time difference value, refuse the client to invoke the service requested by the service request message.
The above modules may be functional modules or program modules, and may be implemented by software or hardware. For a module implemented by hardware, the modules may be located in the same processor; or the modules can be respectively positioned in different processors in any combination.
In addition, the method for generating the unified token of the multiple servers according to the embodiment of the present application described in conjunction with fig. 1 and/or the method for authenticating the unified token of the multiple servers according to the embodiment of the present application described in conjunction with fig. 2 may be implemented by a computer device. Fig. 6 is a hardware structure diagram of a computer device according to an embodiment of the present application.
The computer device may comprise a processor 61 and a memory 62 in which computer program instructions are stored.
Specifically, the processor 61 may include a Central Processing Unit (CPU), or A Specific Integrated Circuit (ASIC), or may be configured to implement one or more Integrated circuits of the embodiments of the present Application.
The memory 62 may be used to store or cache various data files that need to be processed and/or used for communication, as well as possible computer program instructions executed by the processor 61.
The processor 61 may implement any one of the multi-server unified token generation methods and/or any one of the multi-server unified token authentication methods in the above embodiments by reading and executing computer program instructions stored in the memory 62.
In some of these embodiments, the computer device may also include a communication interface 63 and a bus 60. As shown in fig. 6, the processor 61, the memory 62, and the communication interface 63 are connected via a bus 60 to complete mutual communication.
The communication interface 63 is used for implementing communication between modules, devices, units and/or apparatuses in the embodiments of the present application. The communication interface 63 may also enable communication with other components such as: the data communication is carried out among external equipment, image/data acquisition equipment, a database, external storage, an image/data processing workstation and the like.
The computer device may execute the unified token generation method for multiple servers and/or the unified token authentication method for multiple servers in this embodiment of the application based on the obtained generation token request message and the authentication token message, thereby implementing the unified token generation method for multiple servers described in connection with fig. 1 and/or the unified token authentication method for multiple servers described in connection with fig. 2.
In addition, in combination with the multi-server unified token generation method and/or the multi-server unified token authentication method in the foregoing embodiments, the embodiments of the present application may be implemented by providing a computer-readable storage medium. The computer readable storage medium having stored thereon computer program instructions; the computer program instructions, when executed by a processor, implement any one of the multi-server unified token generation methods and/or multi-server unified token authentication methods of the above embodiments.
The technical features of the embodiments described above may be arbitrarily combined, and for the sake of brevity, all possible combinations of the technical features in the embodiments described above are not described, but should be considered as being within the scope of the present specification as long as there is no contradiction between the combinations of the technical features.
The above-mentioned embodiments only express several embodiments of the present application, and the description thereof is more specific and detailed, but not construed as limiting the scope of the invention. It should be noted that, for a person skilled in the art, several variations and modifications can be made without departing from the concept of the present application, which falls within the scope of protection of the present application. Therefore, the protection scope of the present patent application shall be subject to the appended claims.
Claims (10)
1. A method for generating a unified token of multiple servers is characterized by comprising the following steps:
after receiving a token request message sent by a client, a first server generates a first token according to a current time point and a preset keyword, and stores the time point for generating the first token;
the first server sends the first token to the client, and notifies a second server associated with the first server to generate a plurality of second tokens and stores time points for generating the plurality of second tokens, wherein the second server is configured to generate the plurality of second tokens respectively according to each time point in a first preset range before and after a current time point and the preset keyword, and the time points in the first preset range before and after the current time point include the time points for generating the first token.
2. The method of claim 1, further comprising: and the first server informs a second server associated with the first server of generating a plurality of second tokens according to a server list, wherein the first server asynchronously acquires the server list after generating the first token.
3. A multi-server unified token authentication method, wherein a multi-server generates a first token and a second token using the multi-server unified token generation method of claim 1 or 2; the unified token authentication method of the multiple servers comprises the following steps:
a first server receives a service request message sent by a client, wherein the service request message carries a third token of the client;
the first server matches a fourth token corresponding to the third token in the locally stored first tokens;
under the condition that the fourth token is matched, the first server judges whether the time difference between the time point of generating the fourth token and the current time point is within a preset time difference interval or not, wherein the preset time difference interval is determined according to a first preset time difference value and a second preset time difference value;
the first server allows the client to call the service requested by the service request message and updates the current time point to the time point for generating the fourth token when judging that the time difference between the time point for generating the fourth token and the current time point is within a preset time difference interval;
the first server notifies a second server associated with the first server of a point in time at which the second token was generated by the synchronization update.
4. The method of claim 3, further comprising:
and the first server refuses the client to call the service requested by the service request message under the condition that the time difference between the time point of generating the fourth token and the current time point is larger than the first preset time difference value.
5. The method of claim 3, further comprising:
and the first server allows the client to call the service requested by the service request message under the condition that the time difference between the time point of generating the fourth token and the current time point is smaller than the second preset time difference value.
6. The method of claim 3, wherein the first server matching a fourth token corresponding to the third token among the locally stored first tokens comprises: and the first server matches the fourth token in a token matching code, wherein the token matching code comprises a plurality of first tokens in a second preset range before and after the current time point selected from the first tokens stored locally in the first server.
7. The method of claim 3, further comprising:
after receiving a service request message sent by the client, the second server matches a fifth token corresponding to the third token in second tokens stored locally;
under the condition that the fifth token is matched, the second server judges whether the time difference between the time point of generating the fifth token and the current time point is within the preset time difference interval or not;
and the second server allows the client to call the service requested by the service request message and updates the current time point to the time point for generating the fifth token under the condition that the time difference between the time point for generating the fifth token and the current time point is within the preset time difference interval.
8. The method of claim 7, further comprising:
and the second server refuses the client to call the service requested by the service request message when judging that the time difference between the time point of generating the fifth token and the current time point is greater than the first preset time difference value.
9. A computer device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, wherein the processor when executing the computer program implements a multi-server unified token generation method according to any of claims 1 to 2 and/or a multi-server unified token authentication method according to any of claims 3 to 8.
10. A computer-readable storage medium, on which a computer program is stored, which, when being executed by a processor, carries out a multi-server unified token generation method according to any one of claims 1 to 2 and/or a multi-server unified token authentication method according to any one of claims 3 to 8.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010512036.3A CN111654379B (en) | 2020-06-08 | 2020-06-08 | Multi-server unified token generation method and authentication method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010512036.3A CN111654379B (en) | 2020-06-08 | 2020-06-08 | Multi-server unified token generation method and authentication method |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN111654379A CN111654379A (en) | 2020-09-11 |
| CN111654379B true CN111654379B (en) | 2022-12-20 |
Family
ID=72349343
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010512036.3A Active CN111654379B (en) | 2020-06-08 | 2020-06-08 | Multi-server unified token generation method and authentication method |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111654379B (en) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113055371A (en) * | 2021-03-09 | 2021-06-29 | 上海明略人工智能(集团)有限公司 | Login authentication method and system for Internet of things TCP (Transmission control protocol) equipment |
| CN113489657B (en) * | 2021-06-29 | 2022-09-09 | ***股份有限公司 | Distributed flow velocity control system and operation method thereof |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107835195B (en) * | 2017-12-04 | 2021-06-15 | 灵动元点信息技术（北京）有限公司 | Distributed network application node integrated management method |
| CN111147436B (en) * | 2018-11-05 | 2022-03-11 | 华为技术有限公司 | Network slice authorization method and communication device |
| CN109660343B (en) * | 2019-01-17 | 2023-06-20 | 平安科技（深圳）有限公司 | Token updating method, device, computer equipment and storage medium |
| CN110266642A (en) * | 2019-05-15 | 2019-09-20 | 网宿科技股份有限公司 | Identity identifying method and server, electronic equipment |
-
2020
- 2020-06-08 CN CN202010512036.3A patent/CN111654379B/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| CN111654379A (en) | 2020-09-11 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US9792623B2 (en) | Advertisement processing method and apparatus | |
| WO2017198079A1 (en) | File download method and apparatus, user terminal and machine-readable storage medium | |
| CN111654379B (en) | Multi-server unified token generation method and authentication method | |
| CN110705973A (en) | Consensus method applied to miner nodes in block chain system and block chain system | |
| CN112654100B9 (en) | Information processing method and related network equipment | |
| WO2019214714A1 (en) | Method, system, node, and computer storage medium for controlling video playback | |
| CN109067746B (en) | Communication method and device between client and server | |
| US11681513B2 (en) | Controlled scope of authentication key for software update | |
| CN110601832A (en) | Data access method and device | |
| CN113888164A (en) | Block chain transaction pool implementation method and device, computer equipment and storage medium | |
| CN105592083B (en) | Method and device for terminal to access server by using token | |
| CN113709530A (en) | Resource downloading method, system, electronic equipment and storage medium | |
| CN111161072A (en) | Block chain-based random number generation method, equipment and storage medium | |
| CN111988262B (en) | Authentication method, authentication device, server and storage medium | |
| CN111565195A (en) | Challenge black hole attack defense method of distributed system and distributed system | |
| CN113852665A (en) | File uploading method and device, electronic equipment, storage medium and program product | |
| CN111147235B (en) | Object access method and device, electronic equipment and machine-readable storage medium | |
| CN115982279A (en) | Data synchronization method, device and system and computer equipment | |
| CN113225348B (en) | Request anti-replay verification method and device | |
| US11226983B2 (en) | Sub-scope synchronization | |
| CN110324373B (en) | File sharing method and device and file synchronization system | |
| CN111857764A (en) | Offline data updating method, device, equipment and storage medium | |
| CN112861188A (en) | Data aggregation system and method for multiple clusters | |
| CN111736869A (en) | Version updating method of server-side interface and calling method of server-side interface | |
| CN114401110B (en) | Request authentication method, system, computer device and readable storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |