CN111294337B - Authentication method and device based on token - Google Patents

Authentication method and device based on token Download PDF

Info

Publication number
CN111294337B
CN111294337B CN202010044548.1A CN202010044548A CN111294337B CN 111294337 B CN111294337 B CN 111294337B CN 202010044548 A CN202010044548 A CN 202010044548A CN 111294337 B CN111294337 B CN 111294337B
Authority
CN
China
Prior art keywords
token
identifier
version data
client
hash value
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
Application number
CN202010044548.1A
Other languages
Chinese (zh)
Other versions
CN111294337A (en
Inventor
吴振全
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Ping An Technology Shenzhen Co Ltd
Original Assignee
Ping An Technology Shenzhen Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Ping An Technology Shenzhen Co Ltd filed Critical Ping An Technology Shenzhen Co Ltd
Priority to CN202010044548.1A priority Critical patent/CN111294337B/en
Publication of CN111294337A publication Critical patent/CN111294337A/en
Application granted granted Critical
Publication of CN111294337B publication Critical patent/CN111294337B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0807Network 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 a token-based authentication method and device, wherein the method comprises the following steps: the 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, the first token comprises a first token identifier and first version data, when a second token identifier which is identical to the first token identifier exists in a token storage space, the second version data and the second identifier of the second client which are included in the second token identified by the second token identifier are acquired, the token storage space is used for storing the 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, 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 authentication of the token (such as JWT) can be realized.

Description

Authentication method and device based on token
Technical Field
The present application relates to the field of computer technologies, and in particular, to a token-based authentication method and apparatus.
Background
With the development of computer technology, token-based authentication in world wide web (web) applications is increasing. JSON Web Token (JWT for short) is currently the most commonly used cross-domain authentication solution. Cross-domain refers to any one of a protocol, domain name and port requested by a uniform resource locator (Uniform Resource Locator, URL) which is different from the URL of the current page, namely the JWT supports the authentication of web application written by hypertext markup language (Hyper Text Markup Language, HTML) and native language at the same time. JWTs are an open standard (RFC 7519) that can securely transfer messages between servers and clients because JWTs' information is digitally signed.
However, at the server side, after JWTs issue, JWTs will remain active for the validity period of JWTs. Because the JWT is stored on the client, once the JWT on the client is stolen by an lawbreaker, the lawbreaker can easily acquire information or property of the user, and serious security problems are caused.
Disclosure of Invention
The embodiment of the application provides a token-based authentication method and device, 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, including:
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 of the first client and a first token, and the first token comprises a first token identifier and first version data; if the fact that the second token identification which is the same as the first token identification exists in the token storage space is detected, the server acquires second version data and second identification of a second client side, wherein the second version data and the second identification of the second client side are contained in the second token identified by the second token identification, and the token storage space is used for storing tokens authorized to be used by the server; 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 one 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 the login request sent by the second client, and stores the second token in the 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 to cause the second client to authenticate 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 comprises: 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 validity period of the token included in the second token.
With reference to the first aspect, in a possible implementation manner, the method further includes: the server calculates the hash value of the first version data and the hash value of the second version data respectively, 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 not equal to the second version data.
With reference to the first aspect, in a possible implementation manner, the method further includes: if the fact that the second token identification which is identical to the first token identification does not exist in the token storage space is detected, the server returns a request failure response to the service request, and the request failure response is used for rejecting the service request.
With reference to the first aspect, in a possible implementation manner, the method further includes: if the first version data is different from the second version data, the server returns a request failure response to the service request, wherein 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 a possible implementation manner, the method further includes: when receiving the logout request sent by the first client, the server deletes the second token identified by the second token identification identical to 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 receiving module is used for receiving a service request sent by a first client, wherein the service request comprises a first identifier of the first client and a first token, and the first token comprises a first token identifier and first version data;
The acquisition module is used for acquiring second version data and second identifications of second clients, which are included in second tokens identified by the second token identifications, when the second token identifications which are identical to the first token identifications exist in the token storage space, wherein the token storage space is used for storing 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.
With reference to the second aspect, in a possible implementation manner, the apparatus further includes a generating module and a storage module. The generation module is used for generating a second token according to the login request sent by the second client; the storage module is used for storing 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 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 a validity period extending 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 configured to extend a validity period of a token included in the second token.
With reference to the second aspect, in a possible implementation manner, the apparatus further includes a calculating module, a comparing module, and a determining module. The computing module is used for respectively computing the hash value of the first version data and the hash value of the second version data; 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 used for determining that the first version data is identical to the second version data when the hash value of the first version data is identical 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 detecting 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 a possible implementation manner, the apparatus further includes a data desensitizing module. The sending module 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 is used for carrying out data desensitization processing on the service data requested by the service request when the first identifier is different from the second identifier to obtain target service data; 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, when receiving an 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.
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, and where the memory is configured to store a computer program supporting the server to perform the method, where the computer program includes program instructions, and where the processor is configured to invoke the program instructions to perform the token-based authentication method of 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 which, when executed by a processor, cause the processor to perform the token-based authentication method of the first aspect described above.
The embodiment of the application 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, 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 exists in a token storage space, the second version data and the second identifier of the second client which are included in the second token identified by the second token identifier are acquired, 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. The embodiment of the application returns the service data to the first client only when the multiple tests are passed through (whether the first token is legal (namely whether the second token identification which is the same as the first token identification exists in the token storage space) or not), whether the first token is invalid (namely whether the first version data is the same as the second version data or not) and whether the first client is a legal client (namely whether the first identification is the same as the second identification or not) so as to ensure that each token must be used on the generated token equipment and prevent the use of the token across equipment, thereby improving the security of authentication of the token (such as JWT).
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for the description of the embodiments will be briefly described below, and it is obvious that the drawings in the following description are some embodiments of the present application, and other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.
FIG. 1 is a schematic flow chart 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 of providing token-based authentication in accordance with an embodiment of the present application;
fig. 3 is a schematic structural diagram of a token-based authentication device 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 following description of the embodiments of the present application will be made clearly and fully with reference to the accompanying drawings, in which it is evident that the embodiments described are some, but not all embodiments of the application. All other embodiments, which can be made by those skilled in the art based on the embodiments of the application without making any inventive effort, are intended to be within the scope of the application.
It should be understood that the terms first, second, and the like in the description and the claims of the present application and in the accompanying drawings are used for distinguishing between different objects and not necessarily for describing a particular sequential or chronological order. Furthermore, the terms "comprise" and "have," as well as any variations thereof, are intended to cover a non-exclusive inclusion. For example, a process, method, system, article, or apparatus that comprises a list of steps or elements is not limited to only those listed steps or elements but may include other steps or elements not listed or inherent to such process, method, article, or apparatus.
It should be further appreciated that reference herein to "an embodiment" means that a particular feature, structure or characteristic described in connection with the embodiment may be included in at least one embodiment of the 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. Those of skill in the art will explicitly and implicitly appreciate that the embodiments described herein may be combined with other embodiments.
It should be further understood that the term "and/or" as used in the present specification and the appended claims refers to any and all possible combinations of one or more of the associated listed items, and includes such combinations.
The token-based authentication method provided by the embodiment of the application will be described with reference to fig. 1-2.
Referring to fig. 1, a schematic flow chart of a token-based authentication method is provided according to an embodiment of the present application. As shown in fig. 1, the token-based authentication method may include the steps of:
s101, a first client sends a service request to a server. Accordingly, the server receives the service request.
In some possible implementations, the first client may generate the service request according to a user operation. The first client may send the service request to the server, which in turn receives the service request. The service request may be used to request service data. It will be appreciated that the server may assign a token to each client, and that a client may carry the token assigned to that client by the server when requesting traffic data from the server, which token may be used for authentication, i.e. to identify whether that client is a legitimate client for which the server is authorised. The service request may include a first identifier of the first client and a first token, where the first token may include a first token identifier and first version data. The first identification may be used to uniquely identify the first client, and the first version data may be a version number of the first token. The version number is typically composed of 2 to 4 parts: a major version number, a minor version number, an internal version number, and a revision number. The major version number and minor version number are mandatory; the internal version number and 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 version number: 1.1.0.
The token involved in the embodiment 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 (Internet Protocol, IP) Address or a physical Address (MEDIA ACCESS Control Address, MAC Address), a browser identifier, etc. of the client.
S102, when detecting that a second token identifier identical to the first token identifier exists in the token storage space, the server acquires second version data and second identifiers of the second clients, wherein the second version data and the second identifiers of the second clients are included in the second tokens identified by the second token identifier.
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 in the token storage space whether there is a second token identification that is the same as the first token identification. If the server detects a second token identifier identical to the first token identifier in the token storage space, which indicates that the first token is a legal token authorized by the server and also indicates that the first token is real, the server may extract the second token identified by the second token identifier from the token storage space, and may acquire 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, where the second identifier may be the same type of identifier as the first 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 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 identifier may also be 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 identifier 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 is identified as signature data and the second token is also identified as signature data. The token storage space may be a Redis cache or a particular one of the cache spaces or relational databases. The embodiment of the application judges whether the first client steals the tokens of other clients to acquire the service data by detecting whether the first token carried in the service request sent by the first client exists in the server, thereby preventing data leakage caused by using one token by different clients and improving the security of the data.
Optionally, if the server does not detect the second token identifier identical to the first token identifier in the token storage space, which indicates that the first token is not a legal token authorized by the server, and also indicates that the first token is counterfeit, 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 identification is the same as the second identification, 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 the server acquires the second version data and the second identifier, the server may detect whether the first version data is identical to the second version data. If the first version data and the second version data are detected to be the same, the first token is the latest version token, or the first token is not invalid, the server can detect whether the first identifier and the second identifier are the same. If the first identifier is detected to be the same as the second identifier, the first client and the second client are the same client, the first client sending the service request is a legal client authorized by the server, and the first token is not stolen by the first client can be indicated, and the server can 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. After determining that the first token is a legal token (namely, a second token identifier which is the same as the first token identifier exists in a token storage space), the embodiment of the application judges whether the first token is invalid (whether the first version data is the same as the second version data) and whether the first client is a legal client (whether the first identifier is the same as the second identifier), and when the first token is not invalid (namely, the first version data is the same as the second version data) and the first client is the legal client (namely, 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, and through multiple tests, each token can be ensured to be used on the generated token equipment, so that the use of the token across equipment is stopped, and the security of the token authentication is improved.
Optionally, if the first version data and the second version data are detected to be different, which indicates that the first token is not the latest version 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 the first identifier is detected to be different from the second identifier, which indicates that the first client and the second client are not the same client, which also indicates that the first client sending the service request is not a legal client authorized by the server, and which indicates that the first token may be stolen by the first client, so that the first client cannot access the data in the server, the server may return a request failure response to the service request.
Still further optionally, if the first identifier is detected to be 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 can send authentication prompt information to the first client, wherein the authentication prompt information is used for prompting a user to perform authentication. After receiving the target service data and the authentication prompt information 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, etc.) input by the user to the server, and the server performs authentication after receiving the authentication information sent by the first client. If the authentication is passed, the server may send the service data requested by the service request to the first client. If the authentication is not passed, the server does not process.
In some possible embodiments, the server may calculate the hash value of the first version data and may calculate the hash value of the second version data when detecting whether the first version data is identical to the second version data, and compare whether the hash value of the first version data is identical to 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 any length (also called pre-mapping pre-image) into an output with a fixed length through a hash algorithm, simply, compress a message with any length into a message with a certain fixed length, the embodiment of the application maps data with large data size into data with small data size through the hash operation, namely, compares hash values of different versions of data, thereby improving the detection efficiency. Similarly, when detecting whether the first identifier is identical to the second identifier, the server may also compare whether 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 the same as the hash value of the second identifier, the server may determine that the first identifier is the same as 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, the server may extend the validity period of the token included in the second token in the token storage space after returning the service data requested by the service request to the first client. Alternatively, the server may increase the request time (the time when the service request is sent) by a fixed period of time to obtain the second token validity period, and extend the token validity period included in the second token to the second token validity period. For example, if the request time is 2019.7.8, the token validity period included in the second token is 2019.7.10, and the fixed duration is 15 days, and the request time 2019.7.8 is increased by 15 days to obtain the second token validity period 2019.7.23, and the server may extend the token validity period included in the second token to the second token validity period 2019.7.23. Optionally, the server may also increase the request time by a random duration to obtain a second token validity period, and extend the token validity period included in the second token to the second token validity period. The embodiment of the application can avoid the forced offline of the user when the user sends the service request in the critical time of the token validity period by prolonging the token validity period of the second token.
In the embodiment of the application, 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, 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 exists in a token storage space, the second identifier of the second client and second version data which is included in the second token identified by the second token identifier are acquired, 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. The security of token (e.g., JWT) authentication can be improved.
Referring to fig. 2, there is another schematic flow chart diagram of a token-based authentication method provided by an embodiment of the present application. 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 the login request.
In some possible implementations, the user may enter login information on the second client, which may include a user identification (i.e., user account number) and a password. The second client may send a login request to the server, which in turn receives the login request. The login request may include one or more of user identification, session identification, user sensitive information, client identification, browser identification, login status 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 the server receives the login request, various information carried in the login request may be stored in a token storage space (such as a key value storage system dis). The server may generate second version 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 RS 256) to generate signature data (e.g., a section of identifier), and may use the signature data as a second token identifier. 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 generating 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 stale, i.e. whether the current time has reached the token expiration time, based on the token validity period of the second token. When the token validity period of the second token arrives, then the server may delete the second token from the token storage space. Alternatively, the server may detect periodically, such as 00:00 a day, whether each token stored in the token storage space is stale. According to the embodiment of the application, whether each token stored in the token storage space is invalid or not is detected periodically, so that the invalid token can be cleaned timely, and the situation that an illegal molecule uses the invalid token for authentication and authentication is successful to cause data leakage of a user is avoided.
In some possible embodiments, the server may update the signature data in the token periodically, i.e., the server encrypts the various information carried in the login request, the second version data, and the token validity period again 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, after generating the second token, the server may send the second token to the second client, 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 detecting that the second token identifier identical to the first token identifier exists in the token storage space, the server acquires the second version data included in the second token identified by the second token identifier and the second identifier of the second client.
S206, when the first version data is the same as the second version data and the first identification is the same as the second identification, 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 embodiment of the present application may refer to the implementation manners of step S101 to step S103 in the embodiment shown in fig. 1, which are not described herein.
S207, the first client sends a log-out request to the server. Accordingly, the server receives the logout request.
S208, the server deletes the second token identified by the second token identification identical to 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 logout control on the first client, the first client may generate a logout request, where the logout request may carry the first token. The first client may send the logout request to the server, which in turn receives the logout request. After receiving the logout request, the server may delete the second token identified by the second token identification identical to the first token identification from the token storage space (e.g., redis), so as to invalidate the first token, thereby improving security. The token validity of 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 on a change password control, forget password control, or logoff account control on the first client. The first client can generate different requests according to clicking different controls 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 password forgetting control corresponds to the password forgetting request, and the account cancellation control corresponds to the account cancellation request. When the server receives any one of the request to change the password, the request to forget the password and the request to cancel the account, the server can change the second version data in the token storage space (such as Redis) to generate new version data. The server may encrypt the new version data, the token valid value, and various information carried in the login request again using the JWT signature algorithm to generate new signature data, and may determine a new token valid period. The server may package 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 to invalidate the first token. The server may issue a new token to the first client.
In the embodiment of the application, a server generates a second token according to a login request and issues the second token to a second client, when a 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 identifier of the first client and a first token, 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 exists in a token storage space, the second version data and the second identifier of the second client which are included in the second token identifier 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. The security of token (e.g., JWT) authentication can be improved.
The token-based authentication method of the embodiment of the present application is described in detail above, and in order to facilitate better implementation of the above solution of the embodiment of the present application, the embodiment of the present application further provides a corresponding device and a server.
Referring to fig. 3, a schematic structural diagram of a token-based authentication device according to an embodiment of the present application is provided. 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 of the first client and a first token, and the first token includes a first token identifier and first version data;
An obtaining module 102, configured to obtain, when it is detected that a second token identifier that is the same as the first token identifier exists 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, where the token storage space is used for storing a token authorized for use by a server;
and a sending module 103, configured to return, to the first client, service data requested by the service request 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 device 100 further comprises 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 the 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 is 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 extension 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 device 100 further comprises a calculation module 108, a comparison module 109, and a determination module 110. The calculating module 108 is 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 identical to the second version data when the hash value of the first version data is identical 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 the 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.
In some possible embodiments, the token-based authentication device 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 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 the logout request sent by the first client, the second token identified by the second token identification that is the same as the first token identification from the token storage space.
The obtaining 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 one 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, where the methods and functions performed by the server in the foregoing embodiments are performed.
In the embodiment of the application, the token-based authentication device receives a service request sent by a first client, wherein the service request comprises a first identifier of the first client and a first token, 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 exists in a token storage space, the second identifier of the second client and the second version data which is included in the second token and is identified by the second token identifier are acquired, the token storage space is used for storing a token authorized to be used by a 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. The security of token (e.g., JWT) authentication can be improved.
Referring to fig. 4, a schematic structural diagram of a server according to an embodiment of the present application is shown. 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 a 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 for storing a computer program comprising program instructions, and the processor 401 is used for executing 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 of the first client and a first token, and the first token includes a first token identifier and first version data. The above processor 401 is configured to invoke the program instruction execution: and when the second token identification which is the same as the first token identification exists in the token storage space, acquiring second version data and second identifications of the second clients, which are included in the second token identified by the second token identification, 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, to the first client, service data requested by the service request 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 appreciated that in embodiments of the present application, the Processor 401 may be a central processing unit (Central Processing Unit, CPU), which may also be other general purpose Processor, digital signal Processor (DIGITAL SIGNAL Processor, DSP), application SPECIFIC INTEGRATED Circuit (ASIC), off-the-shelf Programmable gate array (Field-Programmable GATE ARRAY, FPGA) or other Programmable logic device, discrete gate or transistor logic device, discrete hardware components, or the like. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.
Input device 402 may include an input interface and output device 403 may include an output interface.
The memory 404 may include read only memory and random access memory and provide instructions and data to the processor 401. A portion of memory 404 may also include non-volatile random access memory. For example, memory 404 may also store information of device type.
In a specific implementation, the processor 401, the input device 402, and the output device 403 described in the embodiments of the present application may execute the implementation described in the token-based authentication method provided in the embodiments of the present application, and may also execute the implementation of the token-based authentication apparatus described in the embodiments of the present application, which is not described herein.
The embodiment of the present application further provides a computer readable storage medium, where a computer program is stored, where the computer program includes program instructions, which when executed by a processor, implement the token-based authentication method shown in fig. 1 or fig. 2, and the specific details are described with reference to the embodiment shown in fig. 1 or fig. 2 and are not repeated herein.
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 memory card (SMART MEDIA CARD, SMC), a Secure Digital (SD) card, a flash memory card (FLASH CARD), or 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 to store 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 described in connection with the embodiments disclosed herein may be embodied in electronic hardware, in computer software, or in a combination of the two, and that the elements and steps of the examples have been generally described in terms of function in the foregoing description to clearly illustrate 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 solution. 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 flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations 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 data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable 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 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 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 application has been described in connection with specific features and embodiments thereof, it will be apparent that various modifications and combinations can be made without departing from the spirit and scope of the application. Accordingly, the specification and drawings are merely exemplary illustrations of the present application as defined in the appended claims and are considered to cover any and all modifications, variations, combinations, or equivalents that fall within the scope of the application. It will be apparent to those skilled in the art that various modifications and variations can be made to the present application without departing from the spirit or scope of the application. Thus, it is intended that the present application also include such modifications and alterations insofar as they come within the scope of the appended claims or the equivalents thereof.

Claims (6)

1. A token-based authentication method, comprising:
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 of the first client and a first token, and the first token comprises a first token identifier and first version data;
if the fact that the second token identification which is the same as the first token identification exists in the token storage space is detected, the server acquires second version data and second identification of a second client side, wherein the second version data and the second identification of the second client side are included in a second token identified by the second token identification, and the token storage space is used for storing tokens authorized to be used by the server;
Detecting whether the first version data and the second version data are identical includes: respectively calculating the hash value of the first version data and the hash value of the second version data, comparing whether the hash value of the first version data is equal to the hash value of the second version data, determining that the first version data is identical to the second version data when the hash value of the first version data is equal to the hash value of the second version data, and determining that the first version data is not identical to 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;
Detecting whether the first and second identifications are identical comprises: comparing whether the hash value of the first identifier is identical to the hash value of the second identifier, determining that the first identifier is identical to the second identifier when the hash value of the first identifier is identical to the hash value of the second identifier, and determining that the first identifier is not identical to the second identifier when the hash value of the first identifier is not identical to the hash value of the second identifier;
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;
wherein the second token also 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, deleting the second token from the token storage space by the server;
After the server returns the service data requested by the service request to the first client, the method further includes:
The server prolongs the validity period of the token included in the second token;
The method further comprises the steps of:
if the first version data is different from the second version data, the server returns a request failure response to the service request, wherein 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;
The method further comprises the steps of:
and when receiving the login exit request sent by the first client, deleting the second token identified by the second token identification which is identical to the first token identification from the token storage space by the server.
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 identifier, a second identifier of the second client and second version data;
the server issues the second token to the second client to cause the second client to authenticate on the server based on the second token.
3. The method according to claim 2, wherein the method further comprises:
and if the fact that the second token identification which is the same as the first token identification does not exist in the token storage space is detected, the server returns a request failure response to the service request, wherein the request failure response is used for rejecting the service request.
4. A token-based authentication apparatus for performing the method of any of claims 1-3, comprising:
The system comprises a receiving module, a processing module and a processing module, wherein the receiving module is used for receiving a service request sent by a first client, the service request comprises a first identifier of the first client and a first token, and the first token comprises a first token identifier and first version data;
The acquisition module is used for acquiring second version data and second identifications of second clients, which are included in second tokens identified by the second token identifications, when the second token identifications which are identical to the first token identifications exist in a token storage space, wherein the token storage space is used for storing tokens authorized to be used by the server;
The obtaining module is further configured to detect whether the first version data and the second version data are the same, including: respectively calculating the hash value of the first version data and the hash value of the second version data, comparing whether the hash value of the first version data is equal to the hash value of the second version data, determining that the first version data is identical to the second version data when the hash value of the first version data is equal to the hash value of the second version data, and determining that the first version data is not identical to 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 obtaining module is further configured to detect whether the first identifier and the second identifier are the same, including: comparing whether the hash value of the first identifier is identical to the hash value of the second identifier, determining that the first identifier is identical to the second identifier when the hash value of the first identifier is identical to the hash value of the second identifier, and determining that the first identifier is not identical to the second identifier when the hash value of the first identifier is not identical to the hash value of the second identifier;
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.
5. 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 adapted 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-3.
6. A computer readable storage medium, characterized in that the computer readable storage medium stores a computer program comprising program instructions which, when executed by a processor, cause the processor to perform the method of any of claims 1-3.
CN202010044548.1A 2020-01-15 2020-01-15 Authentication method and device based on token Active CN111294337B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010044548.1A CN111294337B (en) 2020-01-15 2020-01-15 Authentication method and device based on token

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010044548.1A CN111294337B (en) 2020-01-15 2020-01-15 Authentication method and device based on token

Publications (2)

Publication Number Publication Date
CN111294337A CN111294337A (en) 2020-06-16
CN111294337B true CN111294337B (en) 2024-07-23

Family

ID=71024260

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010044548.1A Active CN111294337B (en) 2020-01-15 2020-01-15 Authentication method and device based on token

Country Status (1)

Country Link
CN (1) CN111294337B (en)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114117551B (en) * 2021-11-26 2022-12-27 深圳前海微众银行股份有限公司 Access verification method and device
CN114610740B (en) * 2022-05-12 2022-08-16 上海柯林布瑞信息技术有限公司 Data version management method and device of medical data platform
CN115766213A (en) * 2022-11-15 2023-03-07 四川启睿克科技有限公司 jwt failure management method

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10044701B2 (en) * 2016-05-24 2018-08-07 Vantiv, Llc Technologies for token-based authentication and authorization of distributed computing resources
US11126670B2 (en) * 2017-05-10 2021-09-21 Verizon Patent And Licensing Inc. Token and device location-based automatic client device authentication
CN107689870B (en) * 2017-08-29 2021-02-02 杭州绿湾网络科技有限公司 Client authentication method and system
US10841088B2 (en) * 2018-05-10 2020-11-17 Oracle International Corporation Secure credential generation and validation
CN109660343B (en) * 2019-01-17 2023-06-20 平安科技(深圳)有限公司 Token updating method, device, computer equipment and storage medium

Also Published As

Publication number Publication date
CN111294337A (en) 2020-06-16

Similar Documents

Publication Publication Date Title
US11329989B2 (en) Token-based access control and grouping
Alaca et al. Device fingerprinting for augmenting web authentication: classification and analysis of methods
CN112333198B (en) Secure cross-domain login method, system and server
US10715514B1 (en) Token-based credential renewal service
US9154482B2 (en) Secure access credential updating
US11336632B2 (en) Composite user identities in distributed computing systems
WO2018233536A1 (en) Authentication method, and authentication data processing method and device based on blockchain
JP6574168B2 (en) Terminal identification method, and method, system, and apparatus for registering machine identification code
US10673862B1 (en) Token-based access tracking and revocation
US10630676B2 (en) Protecting against malicious discovery of account existence
US9143496B2 (en) Device authentication using device environment information
CN111294337B (en) Authentication method and device based on token
US8549597B1 (en) Temporary virtual identities in a social networking system
CN105991614B (en) It is a kind of it is open authorization, resource access method and device, server
CN106897586B (en) Application Programming Interface (API) authority management method and device
CN109005142B (en) Website security detection method, device, system, computer equipment and storage medium
CN110378091A (en) A kind of auth method, device and equipment
US9015817B2 (en) Resilient and restorable dynamic device identification
CN109842616B (en) Account binding method and device and server
CN112738100B (en) Authentication method, device, authentication equipment and authentication system for data access
CN110958249B (en) Information processing method, information processing device, electronic equipment and storage medium
WO2020000749A1 (en) Method and apparatus for detecting unauthorized vulnerabilities
CN115022047B (en) Account login method and device based on multi-cloud gateway, computer equipment and medium
CN112836202A (en) Information processing method and device and server
CN111371889B (en) Message processing method and device, internet of things system and 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