CN111294337A - Token-based authentication method and device - Google Patents
Token-based authentication method and device Download PDFInfo
- Publication number
- CN111294337A CN111294337A CN202010044548.1A CN202010044548A CN111294337A CN 111294337 A CN111294337 A CN 111294337A CN 202010044548 A CN202010044548 A CN 202010044548A CN 111294337 A CN111294337 A CN 111294337A
- Authority
- CN
- China
- Prior art keywords
- token
- identifier
- client
- server
- version data
- 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.)
- Pending
Links
Images
Classifications
-
- 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 Hardware Design (AREA)
- Computer Security & Cryptography (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Information Transfer Between Computers (AREA)
Abstract
The embodiment of the application discloses an authentication method and device based on a token, wherein the method comprises the following steps: the method comprises the steps that a server receives a service request sent by a first client, the service request comprises a first identifier and a first token of the first client, the first token comprises a first token identifier and first version data, when a second token identifier which is the same as the first token identifier is detected to exist in a token storage space, second version data included in a second token identified by the second token identifier and a second identifier of a second client are obtained, the token storage space is used for storing a token authorized to be used by the server, and when the first version data is the same as the second version data and the first identifier is the same as the second identifier, the service data requested by the service request is returned to the first client. By adopting the embodiment of the application, the security of the token (such as JWT) authentication can be ensured.
Description
Technical Field
The present application relates to the field of computer technologies, and in particular, to an authentication method and apparatus based on a token.
Background
With the development of computer technology, token-based authentication is increasing in world wide web (web) applications. JSON Web Token (JWT for short) is the most common cross-domain authentication solution at present. Cross-domain means that any one of a protocol, a domain name, and a port of a Uniform Resource Locator (URL) request is different from the URL of a current page, that is, JWT supports authentication of a web application written in hypertext Markup Language (HTML) and native Language at the same time. JWT is an open standard (RFC 7519) that can securely transfer messages between a server and a client since the information of the JWT is digitally signed.
However, after the JWT issues on the server side, the JWT will always be active for the lifetime of the JWT. And once the JWT on the client is stolen by a lawbreaker, the lawbreaker can easily acquire the information or property of the user, which causes a serious security problem.
Disclosure of Invention
The embodiment of the application provides an authentication method and device based on a token, which can improve the security of token (such as JWT) authentication.
In a first aspect, an embodiment of the present application provides a token-based authentication method, where the method includes:
the method comprises the steps that a server receives a service request sent by a first client, wherein the service request comprises a first identifier and a first token of the first client, and the first token comprises a first token identifier and first version data; if the fact that a second token identifier which is the same as the first token identifier exists in a token storage space is detected, the server obtains second version data included in a second token identified by the second token identifier and a second identifier of a second client, and the token storage space is used for storing tokens authorized to be used by the server; and if the first version data is the same as the second version data and the first identifier is the same as the second identifier, the server returns the service data requested by the service request to the first client.
With reference to the first aspect, in a possible implementation manner, before the server receives the service request sent by the first client, the method further includes:
the server generates a second token according to a login request sent by a second client, and stores the second token in a token storage space, wherein the second token comprises a second token identifier, a second identifier of the second client and second version data; the server issues the second token to the second client, so that the second client performs authentication on the server based on the second token.
With reference to the first aspect, in a possible implementation manner, the second token further includes a token validity period. After the server issues the second token to the second client, the method further includes: if the second token is detected to be invalid based on the token validity period, the server deletes the second token from the token storage space; after the server returns the service data requested by the service request to the first client, the method further includes: the server extends the token validity period included in the second token.
With reference to the first aspect, in one possible implementation, the method further includes: the server respectively calculates the hash value of the first version data and the hash value of the second version data, and compares whether the hash value of the first version data is equal to the hash value of the second version data; when the hash value of the first version data is equal to the hash value of the second version data, the server determines that the first version data is the same as the second version data; and when the hash value of the first version data is not equal to the hash value of the second version data, the server determines that the first version data is not the same as the second version data.
With reference to the first aspect, in one possible implementation, the method further includes: and if the fact that a second token identifier which is the same as the first token identifier does not exist in the token storage space is detected, the server returns a request failure response aiming at the service request, and the request failure response is used for rejecting the service request.
With reference to the first aspect, in one possible implementation, the method further includes: if the first version data is different from the second version data, the server returns a request failure response aiming at the service request, and the request failure response is used for rejecting the service request; if the first identifier is different from the second identifier, the server performs data desensitization processing on the service data requested by the service request to obtain target service data, and returns the target service data to the first client.
With reference to the first aspect, in one possible implementation, the method further includes: and when receiving the log-out request sent by the first client, the server deletes the second token identified by the second token identification which is the same as the first token identification from the token storage space.
In a second aspect, an embodiment of the present application provides a token-based authentication apparatus, including:
the system comprises a receiving module, a sending module and a receiving module, wherein the receiving module is used for receiving a service request sent by a first client, the service request comprises a first identifier and a first token of the first client, and the first token comprises a first token identifier and first version data;
the obtaining module is used for obtaining second version data included in a second token identified by a second token identifier and a second identifier of a second client when the fact that the second token identifier which is the same as the first token identifier exists in a token storage space is detected, wherein the token storage space is used for storing tokens authorized to be used by a server;
and the sending module is used for returning the service data requested by the service request to the first client when the first version data is the same as the second version data and the first identifier is the same as the second identifier.
With reference to the second aspect, in one possible implementation manner, the apparatus further includes a generation module and a storage module. The generating module is used for generating a second token according to a login request sent by a second client; the storage module is configured to store the second token in a token storage space, where the second token includes a second token identifier, a second identifier of the second client, and second version data; the sending module is further configured to issue the second token to the second client, so that the second client performs authentication based on the second token.
With reference to the second aspect, in a possible implementation manner, the second token further includes a token validity period. The device also comprises a deleting module and an effective period prolonging module. The deleting module is used for deleting the second token from the token storage space when the second token is detected to be invalid based on the token validity period; the validity period extending module is used for extending the validity period of the token included in the second token.
With reference to the second aspect, in one possible implementation, the apparatus further includes a calculation module, a comparison module, and a determination module. The calculation module is used for calculating the hash value of the first version data and the hash value of the second version data respectively; the comparison module is used for comparing whether the hash value of the first version data is equal to the hash value of the second version data; the determining module is configured to determine that the first version data is the same as the second version data when the hash value of the first version data is equal to the hash value of the second version data; the determining module is further configured to determine that the first version data is different from the second version data when the hash value of the first version data is not equal to the hash value of the second version data.
With reference to the second aspect, in a possible implementation manner, the sending module is further configured to, when it is detected that a second token identifier that is the same as the first token identifier does not exist in the token storage space, return a request failure response to the service request, where the request failure response is used to reject the service request.
With reference to the second aspect, in one possible implementation, the apparatus further includes a data desensitization module. The sending module is further configured to return a request failure response to the service request when the first version data is different from the second version data or the first identifier is different from the second identifier, where the request failure response is used to reject the service request; the data desensitization module is used for performing data desensitization processing on the service data requested by the service request to obtain target service data when the first identifier is different from the second identifier; the sending module is further configured to return the target service data to the first client.
With reference to the second aspect, in a possible implementation manner, the deleting module is further configured to delete, from the token storage space, a second token identified by the second token identifier that is the same as the first token identifier when receiving a login logout request sent by the first client.
In a third aspect, an embodiment of the present application provides a server, including a processor, an input device, an output device, and a memory, where the processor, the input device, the output device, and the memory are connected to each other, where the memory is used to store a computer program that supports the server to execute the method described above, and the computer program includes program instructions, and the processor is configured to call the program instructions to execute the token-based authentication method described above in the first aspect.
In a fourth aspect, embodiments of the present application provide a computer-readable storage medium storing a computer program comprising program instructions that, when executed by a processor, cause the processor to perform the token-based authentication method of the first aspect.
According to the embodiment of the application, a service request sent by a first client is received, the service request comprises a first identifier and a first token of the first client, the first token comprises a first token identifier and first version data, when a second token identifier which is the same as the first token identifier is detected to exist in a token storage space, second version data included in a second token identified by the second token identifier and a second identifier of a second client are obtained, and when the first version data is the same as the second version data and the first identifier is the same as the second identifier, the service data requested by the service request is returned to the first client. According to the embodiment of the application, through multiple tests (whether a first token is legal (namely whether a second token identifier which is the same as the first token identifier exists in a token storage space), whether the first token is invalid (namely whether first version data and second version data are the same) and whether a first client is a legal client (namely whether the first identifier and the second identifier are the same)), only when the multiple tests are passed, service data are returned to the first client, each token can be ensured to be used on generated token equipment, the use of the token across the equipment is avoided, and therefore the authentication security of the token (such as JWT) can be improved.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings needed to be used in the description of the embodiments are briefly introduced below, and it is obvious that the drawings in the following description are some embodiments of the present application, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without creative efforts.
FIG. 1 is a schematic flow chart diagram of a token-based authentication method provided by an embodiment of the present application;
FIG. 2 is another schematic flow chart diagram of a method for providing token-based authentication according to an embodiment of the present application;
fig. 3 is a schematic structural diagram of a token-based authentication apparatus according to an embodiment of the present application;
fig. 4 is a schematic structural diagram of a server according to an embodiment of the present application.
Detailed Description
The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are some, but not all, embodiments of the present application. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.
It should be understood that the terms "first," "second," and the like in the description and claims of this application and in the drawings are used for distinguishing between different objects and not necessarily for describing a particular order. Furthermore, the terms "include" and "have," as well as any variations thereof, are intended to cover non-exclusive inclusions. For example, a process, method, system, article, or apparatus that comprises a list of steps or elements is not limited to only those steps or elements listed, but may alternatively include other steps or elements not listed, or inherent to such process, method, article, or apparatus.
It should also be appreciated that reference herein 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 present application. 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 explicitly and implicitly understood by one skilled in the art that the embodiments described herein can be combined with other embodiments.
It should be further understood that the term "and/or" as used in this specification and the appended claims refers to and includes any and all possible combinations of one or more of the associated listed items.
The token-based authentication method provided by the embodiment of the present application will be described with reference to fig. 1 to fig. 2.
Referring to fig. 1, a schematic flow chart of a method for providing token-based authentication according to an embodiment of the present application is shown. As shown in fig. 1, the token-based authentication method may include the steps of:
s101, the first client sends a service request to a server. Accordingly, the server receives the service request.
In some possible embodiments, the first client may generate the service request according to an operation of the user. The first client may send the service request to the server, and accordingly, the server receives the service request. The service request may be for requesting service data. It can be understood that the server may allocate a token to each client, and when the client requests service data from the server, the token may carry the token allocated to the client by the server, and the token may be used for authentication, that is, to identify whether the client is a legitimate client authorized by the server. The service request may include a first identification of the first client and a first token, and the first token may include a first token identification and first version data. The first identifier may be used to uniquely identify the first client, and the first version data may be a version number of the first token. Version numbers typically consist of 2 to 4 parts: major version number, minor version number, internal version number, and revision number. The major version number and the minor version number are optional; the internal version number and the revision number are optional, but if a revision number section is defined, the internal version number is mandatory. All defined parts must be integers greater than or equal to 0. For example, the first version data is a version number: 1.1.0.
the token referred to in the embodiments of the present application may be JWT. The first client may be a terminal such as a mobile phone, a portable computer, a desktop computer, or a browser, an application program, etc. on the terminal. The first identifier may be a client identifier of the first client, such as an Internet Protocol (IP) Address or a physical Address (MAC Address) of the client, a browser identifier, and the like.
S102, when it is detected that a second token identifier identical to the first token identifier exists in the token storage space, the server obtains second version data included in a second token identified by the second token identifier and a second identifier of a second client.
In some possible embodiments, after receiving the service request, the server may extract a first token carried in the service request, and may extract a first token identifier from the first token. The server may detect whether a second token identification identical to the first token identification exists in the token storage space. If the server detects a second token identifier that is the same as the first token identifier in the token storage space, which indicates that the first token is a legitimate token authorized by the server and also indicates that the first token is authentic, the server may extract, from the token storage space, a second token identified by the second token identifier, and may obtain second version data included in the second token and a second identifier of a second client. The second identifier may be used to uniquely identify the second client, and the second identifier and the first identifier may be the same type of identifier. For example, the first identifier and the second identifier are both IP addresses. The second version data may be a version number of the second token. For example, the second version data is a version number: 1.1.1. the first token identifier may be used to uniquely identify the first token, for example, the first token identifier may be a Hash value obtained by performing a Hash (Hash) operation on data/information in the first token by the server. Optionally, the first token identifies signature data generated by encrypting data/information in the first token by using an HS256 algorithm for the server. The second token identifier may be used to uniquely identify the second token, and the second token identifier may belong to the same class of identifiers as the first token identifier, for example, the first token identifier is a hash value, and the second token identifier is also a hash value; the first token identification is signature data and the second token identification is also signature data. The token storage space may be a Redis cache or a particular one of cache spaces or a relational database. According to the embodiment of the application, whether the first token carried in the service request sent by the first client exists in the server or not is detected, so that whether the first client steals the tokens of other clients to acquire service data or not is judged, data leakage caused by the fact that different clients use one token is prevented, and data safety is improved.
Optionally, if the server does not detect a second token identifier that is the same as the first token identifier in the token storage space, which indicates that the first token is not a legitimate token authorized by the server and also indicates that the first token is forged, the server may return a request failure response to the service request. The request failure response may be used to reject the service request.
S103, when the first version data is the same as the second version data and the first identifier is the same as the second identifier, the server returns the service data requested by the service request to the first client. Accordingly, the first client receives service data requested by the service request.
In some possible embodiments, after obtaining the second version data and the second identifier, the server may detect whether the first version data is the same as the second version data. If it is detected that the first version data and the second version data are the same, which indicates that the first token is the latest version of the token, or indicates that the first token is not invalid, the server may detect whether the first identifier and the second identifier are the same. If it is detected that the first identifier is the same as the second identifier, it indicates that the first client and the second client are the same client, and also indicates that the first client sending the service request is a legal client authorized by the server, and also indicates that the first token is not stolen by the first client, the server may return the service data requested by the service request to the first client. Accordingly, the first client may receive the service data requested by the service request and display the service data. According to the method and the device for verifying the token authentication, after the first token is determined to be a legal token (namely, a second token identifier which is the same as the first token identifier exists in the token storage space), whether the first token is invalid (whether the first version data and the second version data are the same) and whether the first client is a legal client (whether the first identifier and the second identifier are the same) are judged, and when the first token is not invalid (namely, the first version data and the second version data are the same) and the first client is a legal client (namely, the first identifier and the second identifier are the same), the server returns the service data requested by the service request to the first client.
Optionally, if it is detected that the first version data is different from the second version data, which indicates that the first token is not the latest version of the token, or that the first token has failed, the server may return a request failure response to the service request. The request failure response may be used to reject the service request. Further optionally, if it is detected that the first identifier is different from the second identifier, it indicates that the first client and the second client are not the same client, it also indicates that the first client sending the service request is not a legal client authorized by the server, and it also indicates that the first token may be stolen by the first client, so that the first client cannot access data in the server, and the server may return a request failure response to the service request.
Further optionally, if it is detected that the first identifier is different from the second identifier, the server may perform data desensitization processing on the service data requested by the service request to obtain target service data, and may return the target service data to the first client. Meanwhile, the server may send authentication prompt information to the first client, where the authentication prompt information is used to prompt the user to perform authentication. After the user receives the target service data and the authentication prompt message through the first client, the user can perform authentication on the first client. The first client sends the authentication information (account password, fingerprint, iris or gesture and the like) input by the user to the server, and the server receives the authentication information sent by the first client and then authenticates the authentication information. If the identity authentication is passed, the server may send the service data requested by the service request to the first client. And if the identity authentication is not passed, the server does not process the identity authentication.
In some possible embodiments, the server, upon detecting whether the first version data is the same as the second version data, may calculate a hash value of the first version data, may calculate a hash value of the second version data, and compare whether the hash value of the first version data is the same as the hash value of the second version data. The server may determine that the first version data is identical to the second version data if the hash value of the first version data is identical to the hash value of the second version data. If the hash value of the first version data is not the same as the hash value of the second version data, the server may determine that the first version data is not the same as the second version data. Since the hash operation is to convert an input with an arbitrary length (also called a pre-mapped pre-image) into an output with a fixed length through a hash algorithm, and simply compress a message with an arbitrary length into a message with a certain fixed length, the embodiment of the present application maps data with a large data size into data with a small data size through the hash operation, that is, compares hash values of data with different versions, so as to improve the detection efficiency. Similarly, the server may compare whether the hash value of the first identifier is the same as the hash value of the second identifier when detecting whether the first identifier is the same as the second identifier. The server may determine that the first identifier is identical to the second identifier if the hash value of the first identifier is identical to the hash value of the second identifier. If the hash value of the first identifier is not the same as the hash value of the second identifier, the server may determine that the first identifier is not the same as the second identifier.
In some possible embodiments, after returning the service data requested by the service request to the first client, the server may extend the token validity period included in the second token in the token storage space. Alternatively, the server may increase the request time (the time when the service request is sent) by a fixed time length to obtain the validity period of the second token, and extend the validity period of the token included in the second token to the validity period of the second token. For example, the request time is 2019.7.8, the second token includes a token validity period of 2019.7.10, and the fixed duration is 15 days, then the request time 2019.7.8 increases the fixed duration by 15 days to obtain a second token validity period 2019.7.23, and the server may extend the token validity period included in the second token to a second token validity period 2019.7.23. Optionally, the server may also increase the request time by a random time length to obtain a second token validity period, and extend the token validity period included in the second token to the second token validity period. By prolonging the token validity period of the second token, the embodiment of the application can avoid that the user is forced to be offline when sending the service request at the critical time of the token validity period.
In the embodiment of the application, a server receives a service request sent by a first client, where the service request includes a first identifier and a first token of the first client, the first token includes a first token identifier and first version data, when it is detected that a second token identifier identical to the first token identifier exists in a token storage space, second version data included in the second token identified by the second token identifier and a second identifier of the second client are obtained, the token storage space is used for storing a token authorized to be used by the server, and when the first version data is identical to the second version data and the first identifier is identical to the second identifier, service data requested by the service request is returned to the first client. The security of token (e.g. JWT) authentication can be improved.
Referring to fig. 2, another schematic flow chart of the method for providing token-based authentication according to the embodiment of the present application is shown. As shown in fig. 2, the token-based authentication method may include the steps of:
s201, the second client sends a login request to the server. Accordingly, the server receives a login request.
In some possible implementations, the user may enter login information on the second client, which may include a user identification (i.e., a user account) and a password. The second client may send a login request to the server, which in turn, the server receives. The login request may include one or more of user identification, session identification, user sensitive information, client identification, browser identification, login state timestamp, and the like.
S202, the server generates a second token according to the login request and stores the second token in the token storage space.
In some possible embodiments, after receiving the login request, the server may store various information carried in the login request in a token storage space (e.g., a key value storage system Redis). The server may generate a second version of data, which may be a token version number, and may determine a token validity period, which may include a token expiration time. The server may encrypt the various information carried in the login request, the second version data, and the token validity period using a JWT signature algorithm (e.g., HS256 or RS256) to generate signature data (e.g., a segment identifier), and may identify the signature data as a second token. The server may encapsulate the signature data (second token identification), the second version data, the token validity period, and various information carried in the login request into a second token (JWT), and may store the second token in a token storage space. Optionally, after the server generates the signature data, the server may further determine the second token identifier according to a preset rule. The server may encapsulate the signature data, the second token identification, the second version data, the token validity period, and various information carried in the login request into a second token (JWT), and may store the second token in a token storage space.
In some possible embodiments, the server may detect whether the second token is invalid based on the token validity period of the second token, that is, whether the current time reaches the token expiration time. When the token validity period of the second token arrives, the server may delete the second token from the token storage space. Alternatively, the server may detect on a regular basis, such as a 00:00 daily basis, whether each token stored in the token storage space is invalid. According to the embodiment of the application, whether each token stored in the token storage space is invalid or not is detected regularly, the invalid token can be cleaned in time, and the data leakage of a user caused by the fact that lawless persons use the invalid token for authentication and authentication is successful is avoided.
In some possible embodiments, the server may update the signature data in the token periodically, i.e., the server re-encrypts the various information carried in the login request, the second version data and the token validity period at intervals using the JWT signature algorithm to generate new signature data, and may generate a new token.
S203, the server issues a second token to the second client. Accordingly, the second client receives the second token.
In some possible embodiments, the server may send the second token to the second client after generating the second token, and accordingly, the second client may receive the second token. The second client, after receiving the second token, may authenticate on the server based on the second token.
S204, the first client sends a service request to the server. Accordingly, the server receives the service request.
S205, when it is detected that a second token identifier identical to the first token identifier exists in the token storage space, the server obtains second version data included in the second token identified by the second token identifier and a second identifier of the second client.
And S206, when the first version data is the same as the second version data and the first identifier is the same as the second identifier, the server returns the service data requested by the service request to the first client. Accordingly, the first client receives service data requested by the service request.
In some possible implementations, the implementation manners of step S204 to step S206 in the embodiments of the present application may refer to the implementation manners of step S101 to step S103 in the embodiment shown in fig. 1, and are not described herein again.
S207, the first client sends a log-out request to the server. Accordingly, the server receives an logout request.
S208, the server deletes the second token identified by the second token identification which is the same as the first token identification from the token storage space.
In some possible embodiments, after the server returns the service data requested by the service request to the first client, when the user clicks the log-out control on the first client, the first client may generate a log-out request, where the log-out request may carry the first token. The first client may send the logout request to the server, and accordingly, the server receives the logout request. After receiving the log-out request, the server may delete the second token identified by the second token identifier identical to the first token identifier from the token storage space (e.g., Redis), so as to invalidate the first token, thereby improving security. The validity of the token in the embodiment of the application is controlled by the server, and the server can independently disable one token.
In other possible embodiments, after the server returns the service data requested by the service request to the first client, the user may click a change password control, forget a password control, or cancel an account control on the first client. The first client side can generate different requests according to different controls clicked by a user, and can send the generated different requests to the server, wherein the password changing control corresponds to the password changing request, the forgotten password control corresponds to the password forgetting request, and the account logout control corresponds to the account logout request. When the server receives any one of a request for changing a password, a request for forgetting a password and a request for logging off an account, the server may change the second version data in the token storage space (e.g., Redis) to generate new version data. The server may re-encrypt the new version data, the token valid value, and various information carried in the aforementioned login request using the JWT signature algorithm to generate new signature data, and may determine a new token valid period. The server may encapsulate the new signature data, the new version data, the new token validity period, and various information carried in the login request into a new token, and store the new token in the token storage space. Optionally, after the server stores the new token in the token storage space, the second token in the token storage space may be deleted, so as to invalidate the first token. The server may issue a new token to the first client.
In the embodiment of the application, the server generates a second token according to the login request and issues the second token to the second client, when the first client sends a service request to the server, the server receives the service request sent by the first client, the service request comprises a first identification of the first client and a first token, the first token comprises a first token identification and first version data, when detecting the presence of a second token identification in the token storage space that is identical to the first token identification, obtaining a second token identification identifying second version data included in the identified second token and a second identification of the second client, the token storage space is used for storing tokens authorized to be used by the server, and when the first version data is the same as the second version data and the first identifier is the same as the second identifier, the token storage space returns the service data requested by the service request to the first client. The security of token (e.g. JWT) authentication can be improved.
The token-based authentication method in the embodiment of the present application is described in detail above, and in order to better implement the above scheme in the embodiment of the present application, the embodiment of the present application further provides a corresponding apparatus and server.
Referring to fig. 3, a schematic structural diagram of an authentication apparatus based on a token according to an embodiment of the present application is shown. As shown in fig. 3, the token-based authentication apparatus 100 may include:
a receiving module 101, configured to receive a service request sent by a first client, where the service request includes a first identifier and a first token of the first client, and the first token includes a first token identifier and first version data;
an obtaining module 102, configured to, when it is detected that a second token identifier that is the same as the first token identifier exists in a token storage space, obtain second version data included in a second token identified by the second token identifier and a second identifier of a second client, where the token storage space is used to store tokens that a server authorizes to use;
a sending module 103, configured to return the service data requested by the service request to the first client when the first version data is the same as the second version data and the first identifier is the same as the second identifier.
In some possible embodiments, the token-based authentication apparatus 100 further includes a generation module 104 and a storage module 105. The generating module 104 is configured to generate a second token according to a login request sent by a second client; the storage module 105 is configured to store the second token in a token storage space, where the second token includes a second token identifier, a second identifier of the second client, and second version data; the sending module 103 is further configured to issue the second token to the second client, so that the second client performs authentication based on the second token.
In some possible embodiments, the second token further includes a token validity period. The token-based authentication device further comprises a deletion module 106 and a validity period extension module 107. The deleting module 106, configured to delete the second token from the token storage space when the second token is detected to be invalid based on the token validity period; the validity period extending module 107 is configured to extend the validity period of the token included in the second token.
In some possible embodiments, the token-based authentication apparatus 100 further comprises a calculation module 108, a comparison module 109, and a determination module 110. The calculating module 108, configured to calculate a hash value of the first version data and a hash value of the second version data respectively; the comparing module 109 is configured to compare whether the hash value of the first version data is equal to the hash value of the second version data; the determining module 110 is configured to determine that the first version data is the same as the second version data when the hash value of the first version data is equal to the hash value of the second version data; the determining module 110 is further configured to determine that the first version data is different from the second version data when the hash value of the first version data is not equal to the hash value of the second version data.
In some possible embodiments, the sending module 103 is further configured to, when detecting that a second token identifier identical to the first token identifier does not exist in the token storage space, return a request failure response to the service request, where the request failure response is used to reject the service request.
In some possible embodiments, the token-based authentication apparatus 100 further comprises a data desensitization module 111. The sending module 103 is further configured to, when the first version data is different from the second version data or the first identifier is different from the second identifier, return a request failure response to the service request, where the request failure response is used to reject the service request; the data desensitization module 111 is configured to perform data desensitization processing on the service data requested by the service request to obtain target service data when the first identifier is different from the second identifier; the sending module 103 is further configured to return the target service data to the first client.
In some possible embodiments, the deleting module 106 is further configured to delete, when receiving a login logout request sent by the first client, a second token identified by the second token identifier that is the same as the first token identifier from the token storage space.
The acquiring module 102, the generating module 104, the storing module 105, the deleting module 106, the validity period extending module 107, the calculating module 108, the comparing module 109, the determining module 110, and the data desensitizing module 111 may be a module, such as a processing module.
In a specific implementation, the implementation of each module and/or unit may also correspond to the corresponding description of the server in the method embodiment shown in fig. 1 or fig. 2, and perform the method and the function performed by the server in the foregoing embodiment.
In this embodiment of the present application, a token-based authentication device receives a service request sent by a first client, where the service request includes a first identifier and a first token of the first client, the first token includes a first token identifier and first version data, when it is detected that a second token identifier identical to the first token identifier exists in a token storage space, a second version data included in a second token identified by the second token identifier and a second identifier of a second client are obtained, the token storage space is used for storing a token authorized to be used by a server, and when the first version data is identical to the second version data and the first identifier is identical to the second identifier, service data requested by the service request is returned to the first client. The security of token (e.g. JWT) authentication can be improved.
Fig. 4 is a schematic structural diagram of a server according to an embodiment of the present application. As shown in fig. 4, the server in the embodiment of the present application may include: one or more processors 401; one or more input devices 402, one or more output devices 403, and memory 404. The processor 401, the input device 402, the output device 403, and the memory 404 are connected by a bus 405. The memory 404 is used to store computer programs comprising program instructions and the processor 401 is used to execute the program instructions stored by the memory 402.
The input device 402 is configured to receive a service request sent by a first client, where the service request includes a first identifier and a first token of the first client, and the first token includes a first token identifier and first version data. The processor 401 is configured to call the program instructions to perform: when detecting that a second token identifier identical to the first token identifier exists in the token storage space, obtaining second version data included in the second token identified by the second token identifier and a second identifier of a second client, wherein the token storage space is used for storing tokens authorized to be used by the server. The output device 403 is configured to return the service data requested by the service request to the first client when the first version data is the same as the second version data and the first identifier is the same as the second identifier.
It should be understood that, in the embodiment of the present Application, the Processor 401 may be a Central Processing Unit (CPU), and the Processor may also be other general processors, Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) or other Programmable logic devices, discrete Gate or transistor logic devices, discrete hardware components, and the like. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.
The input device 402 may include an input interface and the output device 403 may include an output interface.
The memory 404 may include a read-only memory and a random access memory, and provides instructions and data to the processor 401. A portion of the memory 404 may also include non-volatile random access memory. For example, the memory 404 may also store device type information.
In a specific implementation, the processor 401, the input device 402, and the output device 403 described in this embodiment of the present application may execute the implementation described in the token-based authentication method provided in this embodiment of the present application, and may also execute the implementation of the token-based authentication apparatus described in this embodiment of the present application, which is not described herein again.
An embodiment of the present application further provides a computer-readable storage medium, where a computer program is stored in the computer-readable storage medium, where the computer program includes program instructions, and when the program instructions are executed by a processor, the token-based authentication method shown in fig. 1 or fig. 2 is implemented, for details, please refer to the description of the embodiment shown in fig. 1 or fig. 2, which is not described herein again.
The computer readable storage medium may be the token-based authentication apparatus according to any of the foregoing embodiments or an internal storage unit of an electronic device, such as a hard disk or a memory of the electronic device. The computer readable storage medium may also be an external storage device of the electronic device, such as a plug-in hard disk, a smart card (SMC), a Secure Digital (SD) card, a flash card (flash card), and the like, which are provided on the electronic device. Further, the computer readable storage medium may also include both an internal storage unit and an external storage device of the electronic device. The computer-readable storage medium is used for storing the computer program and other programs and data required by the electronic device. The computer readable storage medium may also be used to temporarily store data that has been output or is to be output.
Those of ordinary skill in the art will appreciate that the elements and algorithm steps of the examples described in connection with the embodiments disclosed herein may be embodied in electronic hardware, computer software, or combinations of both, and that the components and steps of the examples have been described in a functional general in the foregoing description for the purpose of illustrating clearly the interchangeability of hardware and software. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.
The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus and computer program products according to embodiments of the application. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable medical data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable medical data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable medical data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be loaded onto a computer or other programmable medical data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
Although the present application has been described in conjunction with specific features and embodiments thereof, it will be evident that various modifications and combinations can be made thereto without departing from the spirit and scope of the application. Accordingly, the specification and figures are merely exemplary of the present application as defined in the appended claims and are intended to cover any and all modifications, variations, combinations, or equivalents within the scope of the present application. It will be apparent to those skilled in the art that various changes and modifications may be made in the present application without departing from the spirit and scope of the application. Thus, if such modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is intended to include such modifications and variations as well.
Claims (10)
1. A token-based authentication method, comprising:
a server receives a service request sent by a first client, wherein the service request comprises a first identifier and a first token of the first client, and the first token comprises a first token identifier and first version data;
if it is detected that a second token identifier identical to the first token identifier exists in a token storage space, the server obtains second version data included in a second token identified by the second token identifier and a second identifier of a second client, and the token storage space is used for storing tokens authorized to be used by the server;
and if the first version data is the same as the second version data and the first identifier is the same as the second identifier, the server returns the service data requested by the service request to the first client.
2. The method of claim 1, wherein before the server receives the service request sent by the first client, the method further comprises:
the server generates a second token according to a login request sent by a second client, and stores the second token in a token storage space, wherein the second token comprises a second token identification, a second identification of the second client and second version data;
and the server issues the second token to the second client so that the second client performs authentication on the server based on the second token.
3. The method of claim 2, wherein the second token further comprises a token validity period;
after the server issues the second token to the second client, the method further includes:
if the second token is detected to be invalid based on the token validity period, the server deletes the second token from the token storage space;
after the server returns the service data requested by the service request to the first client, the method further includes:
the server extends a token validity period included in the second token.
4. The method of claim 1, further comprising:
the server respectively calculates the hash value of the first version data and the hash value of the second version data, and compares whether the hash value of the first version data is equal to the hash value of the second version data;
when the hash value of the first version data is equal to the hash value of the second version data, the server determines that the first version data is the same as the second version data;
when the hash value of the first version data is not equal to the hash value of the second version data, the server determines that the first version data is different from the second version data.
5. The method according to any one of claims 1-4, further comprising:
and if detecting that a second token identifier which is the same as the first token identifier does not exist in the token storage space, returning a request failure response to the service request by the server, wherein the request failure response is used for rejecting the service request.
6. The method according to any one of claims 1-4, further comprising:
if the first version data is different from the second version data, the server returns a request failure response aiming at the service request, wherein the request failure response is used for rejecting the service request;
and if the first identifier is different from the second identifier, the server performs data desensitization processing on the service data requested by the service request to obtain target service data, and returns the target service data to the first client.
7. The method of claim 1, further comprising:
and when receiving a log-out request sent by the first client, the server deletes a second token identified by the second token identifier which is the same as the first token identifier from the token storage space.
8. A token-based authentication apparatus, comprising:
the system comprises a receiving module, a sending module and a receiving module, wherein the receiving module is used for receiving a service request sent by a first client, the service request comprises a first identifier and a first token of the first client, and the first token comprises a first token identifier and first version data;
the obtaining module is configured to, when it is detected that a second token identifier that is the same as the first token identifier exists in a token storage space, obtain second version data included in a second token identified by the second token identifier and a second identifier of a second client, where the token storage space is used to store tokens authorized to be used by the server;
and the sending module is used for returning the service data requested by the service request to the first client when the first version data is the same as the second version data and the first identifier is the same as the second identifier.
9. A server comprising a processor, an input device, an output device, and a memory, the processor, the input device, the output device, and the memory being interconnected, wherein the memory is configured to store a computer program comprising program instructions, the processor being configured to invoke the program instructions to perform the method of any of claims 1-7.
10. A computer-readable storage medium, characterized in that the computer-readable storage medium stores a computer program comprising program instructions that, when executed by a processor, cause the processor to carry out the method according to any one of claims 1-7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010044548.1A CN111294337A (en) | 2020-01-15 | 2020-01-15 | Token-based authentication method and device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010044548.1A CN111294337A (en) | 2020-01-15 | 2020-01-15 | Token-based authentication method and device |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN111294337A true CN111294337A (en) | 2020-06-16 |
Family
ID=71024260
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010044548.1A Pending CN111294337A (en) | 2020-01-15 | 2020-01-15 | Token-based authentication method and device |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111294337A (en) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114610740A (en) * | 2022-05-12 | 2022-06-10 | 上海柯林布瑞信息技术有限公司 | Data version management method and device for medical data platform |
| CN115766213A (en) * | 2022-11-15 | 2023-03-07 | 四川启睿克科技有限公司 | jwt failure management method |
| WO2023093500A1 (en) * | 2021-11-26 | 2023-06-01 | 深圳前海微众银行股份有限公司 | Access verification method and apparatus |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107689870A (en) * | 2017-08-29 | 2018-02-13 | 杭州绿湾网络科技有限公司 | Client method for authenticating and system |
| US20180332016A1 (en) * | 2017-05-10 | 2018-11-15 | Verizon Patent And Licensing Inc. | Token and device location-based automatic client device authentication |
| CN109660343A (en) * | 2019-01-17 | 2019-04-19 | 平安科技（深圳）有限公司 | Token updating method, device, computer equipment and storage medium |
| US20190349194A1 (en) * | 2018-05-10 | 2019-11-14 | Oracle International Corporation | Secure credential generation and validation |
-
2020
- 2020-01-15 CN CN202010044548.1A patent/CN111294337A/en active Pending
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20180332016A1 (en) * | 2017-05-10 | 2018-11-15 | Verizon Patent And Licensing Inc. | Token and device location-based automatic client device authentication |
| CN107689870A (en) * | 2017-08-29 | 2018-02-13 | 杭州绿湾网络科技有限公司 | Client method for authenticating and system |
| US20190349194A1 (en) * | 2018-05-10 | 2019-11-14 | Oracle International Corporation | Secure credential generation and validation |
| CN109660343A (en) * | 2019-01-17 | 2019-04-19 | 平安科技（深圳）有限公司 | Token updating method, device, computer equipment and storage medium |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2023093500A1 (en) * | 2021-11-26 | 2023-06-01 | 深圳前海微众银行股份有限公司 | Access verification method and apparatus |
| CN114610740A (en) * | 2022-05-12 | 2022-06-10 | 上海柯林布瑞信息技术有限公司 | Data version management method and device for medical data platform |
| CN115766213A (en) * | 2022-11-15 | 2023-03-07 | 四川启睿克科技有限公司 | jwt failure management method |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN107135073B (en) | Interface calling method and device | |
| US9398050B2 (en) | Dynamically configured connection to a trust broker | |
| US10630676B2 (en) | Protecting against malicious discovery of account existence | |
| US11336632B2 (en) | Composite user identities in distributed computing systems | |
| US9154482B2 (en) | Secure access credential updating | |
| JP6574168B2 (en) | Terminal identification method, and method, system, and apparatus for registering machine identification code | |
| CN109005142B (en) | Website security detection method, device, system, computer equipment and storage medium | |
| WO2019095856A1 (en) | Network identity authentication method and system, and user agent device used thereby | |
| WO2020000749A1 (en) | Method and apparatus for detecting unauthorized vulnerabilities | |
| CN111294337A (en) | Token-based authentication method and device | |
| CN112738100B (en) | Authentication method, device, authentication equipment and authentication system for data access | |
| CN112836202A (en) | Information processing method and device and server | |
| CN110704820A (en) | Login processing method and device, electronic equipment and computer readable storage medium | |
| CN111371889B (en) | Message processing method and device, internet of things system and storage medium | |
| CN109842616B (en) | Account binding method and device and server | |
| CN113259429B (en) | Session maintenance management and control method, device, computer equipment and medium | |
| US11075922B2 (en) | Decentralized method of tracking user login status | |
| CN114422139A (en) | API gateway request security verification method and device, electronic equipment and computer readable medium | |
| CN108965335B (en) | Method for preventing malicious access to login interface, electronic device and computer medium | |
| CN111935122B (en) | Data security processing method and device | |
| US10313349B2 (en) | Service request modification | |
| CN113225348A (en) | Request anti-replay verification method and device | |
| CN111917787A (en) | Request detection method and device, electronic equipment and computer-readable storage medium | |
| CN113452803A (en) | Verification method, verification device, server and storage medium | |
| KR20140023085A (en) | A method for user authentication, a authentication server and a user authentication system |
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 |