CN114338212A - Identity authentication token management method and device, electronic equipment and readable storage medium - Google Patents
Identity authentication token management method and device, electronic equipment and readable storage medium Download PDFInfo
- Publication number
- CN114338212A CN114338212A CN202111677137.7A CN202111677137A CN114338212A CN 114338212 A CN114338212 A CN 114338212A CN 202111677137 A CN202111677137 A CN 202111677137A CN 114338212 A CN114338212 A CN 114338212A
- Authority
- CN
- China
- Prior art keywords
- client
- token
- timestamp
- identity
- login account
- 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
- 238000007726 management method Methods 0.000 title claims abstract description 39
- 238000000034 method Methods 0.000 claims abstract description 50
- 238000012795 verification Methods 0.000 claims description 14
- 230000006870 function Effects 0.000 description 8
- 238000010586 diagram Methods 0.000 description 5
- 238000004891 communication Methods 0.000 description 3
- 238000001514 detection method Methods 0.000 description 3
- 238000011161 development Methods 0.000 description 3
- 230000000694 effects Effects 0.000 description 3
- 230000003993 interaction Effects 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 238000012545 processing Methods 0.000 description 2
- 238000010200 validation analysis Methods 0.000 description 2
- 238000007599 discharging Methods 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 239000004973 liquid crystal related substance Substances 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 238000000926 separation method Methods 0.000 description 1
Images
Landscapes
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
The application discloses an identity authentication token management method, an identity authentication token management device, electronic equipment and a readable storage medium, and belongs to the technical field of identity authentication, wherein the method comprises the following steps: the identity authentication token management method is applied to a server and comprises the following steps: receiving a login request sent by a client; acquiring a first timestamp of a system; generating a token according to the login account, the unique identity of the client and the first timestamp; the token is returned to the client. By the identity authentication method, token of the storage resource storage client of the server does not need to be occupied, and storage pressure of the server can be reduced.
Description
Technical Field
The embodiment of the invention relates to the technical field of self-service equipment, in particular to an equipment detection method and device, electronic equipment and a readable storage medium.
Background
At present, the authentication token can be called token to be widely applied in application systems. Whether based on the interface development of the separation of the front end and the back end of the B/S framework, namely the browser and server framework modes, or the mobile application development or the applet development, the client identity authentication is required. The token is used when the client identity is authenticated, and the specific use mode is as follows: the server generates a token for the client, then issues the token to the client, and simultaneously stores the token in the server; after receiving the request of the client, analyzing the token from the request and comparing the token with the token stored in the server, if the token is the same as the token, the authentication is passed, otherwise, the authentication is not passed.
In the existing manner of storing the token at the Server side after the Server generates the token, a cache database such as a Remote Dictionary Server (redis) needs to be installed in the Server to store the token, and the storage pressure of the Server is large.
Disclosure of Invention
The embodiment of the application aims to provide an identity authentication token management method, an identity authentication token management device, an electronic device and a readable storage medium, and can solve the problems that in the prior art, a token needs to be stored on a server side, and the storage pressure is high.
In order to solve the technical problem, the present application is implemented as follows:
in a first aspect, an embodiment of the present application provides an identity authentication token management method, which is applied to a server, where the method includes: receiving a login request sent by a client, wherein the login request carries a login account and a unique client identity; acquiring a first timestamp of a system; generating a token according to the login account, the unique client identity and the first timestamp, wherein the token is used for performing identity authentication on the client; returning the token to the client.
Optionally, the generating a token according to the login account, the unique client identity, and the first timestamp includes: and symmetrically encrypting the login account and the first timestamp by taking the unique identity of the client as a secret key to generate a token.
Optionally, after the returning the token to the client, the method further comprises: receiving a call request sent by the client, wherein the call request carries a token, a request parameter and a unique identity of the client; analyzing the call request to obtain a token, request parameters and a unique identity of the client; decrypting the token by using the unique identity of the client to obtain a first timestamp and a first login account; and performing identity verification on the client based on the first timestamp, the first login account and the request parameter.
Optionally, performing identity verification on the client based on the first timestamp, the first login account and the request parameter includes: comparing whether the first login account is matched with the login account carried in the request parameter; if so, judging the timeliness of the token according to the first timestamp; and determining that the client identity authentication is passed under the condition that the timeliness of the token is effective.
Optionally, the determining the timeliness of the token according to the first timestamp includes: acquiring a second timestamp corresponding to the current time of the system; calculating a time interval between the second timestamp and the first timestamp; determining that the timeliness of the token is effective when the time interval is greater than a preset threshold; determining that the timeliness of the token is invalid if the time interval is less than or equal to the preset threshold.
Optionally, the symmetric encryption is performed on the login account and the first timestamp by using the unique client identity as a key to generate a token, including: splicing the login account and the first timestamp according to a preset rule to obtain an object to be encrypted; and symmetrically encrypting the spliced objects to be encrypted by adopting the unique identity of the client to generate a token.
Optionally, the client unique identity includes at least one of: a browser fingerprint, a unique identification of the client device.
In a second aspect, an embodiment of the present application provides an authentication token management apparatus, which is applied to a server, where the apparatus includes: the system comprises a first receiving module, a second receiving module and a third receiving module, wherein the first receiving module is used for receiving a login request sent by a client, and the login request carries a login account and a unique client identity; the first acquisition module is used for acquiring a first timestamp of the system; the encryption module is used for generating a token according to the login account, the unique client identity and the first timestamp, wherein the token is used for carrying out identity verification on the client; and the sending module is used for returning the token to the client.
Optionally, the encryption module is specifically configured to: and symmetrically encrypting the login account and the first timestamp by taking the unique identity of the client as a secret key to generate a token.
Optionally, the apparatus further comprises: the second receiving module is configured to receive a call request sent by the client after the token is returned to the client by the sending module, where the call request carries the token, a request parameter, and a unique identity of the client; the analysis module is used for analyzing the calling request to obtain a token, request parameters and a unique identity of the client; the decryption module is used for decrypting the token by adopting the unique identity of the client to obtain a first timestamp and a first login account; and the verification module is used for verifying the identity of the client based on the first timestamp, the first login account and the request parameters.
Optionally, the verification module comprises: the comparison submodule is used for comparing whether the first login account is matched with the login account carried in the request parameter or not; the timeliness judging submodule is used for judging the timeliness of the token according to the first timestamp if the matching is carried out; and the result determining submodule is used for determining that the client identity is verified under the condition that the timeliness of the token is effective.
Optionally, the timeliness determination sub-module is specifically configured to: acquiring a second timestamp corresponding to the current time of the system; calculating a time interval between the second timestamp and the first timestamp; determining that the timeliness of the token is effective when the time interval is greater than a preset threshold; determining that the timeliness of the token is invalid if the time interval is less than or equal to the preset threshold.
Optionally, the encryption module includes: the splicing submodule is used for splicing the login account and the first timestamp according to a preset rule to obtain an object to be encrypted; and the symmetric encryption submodule is used for symmetrically encrypting the spliced objects to be encrypted by adopting the unique identity of the client to generate a token.
Optionally, the client unique identity includes at least one of: a browser fingerprint, a unique identification of the client device.
In a third aspect, an embodiment of the present application provides an electronic device, which includes a processor, a memory, and a program or instructions stored on the memory and executable on the processor, and when executed by the processor, the program or instructions implement the steps of the method according to the first aspect.
In a fourth aspect, embodiments of the present application provide a readable storage medium, on which a program or instructions are stored, which when executed by a processor implement the steps of the method according to the first aspect.
According to the identity authentication token management method provided by the embodiment of the application, a login request sent by a client is received, a first time stamp of a system is obtained, a token is generated according to the login account number, the unique identity of the client and the first time stamp, and the generated token is returned to the client so that the client can perform identity authentication on the client according to the token carried in a call request when the client sends the call request. According to the token management scheme, the server does not need to cache any token data, a cache database such as Redis can be prevented from being installed for caching the token data, the storage pressure of the server can be reduced, and the server is light.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings needed to be used in the description of the embodiments of the present invention will be briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and it is obvious for those skilled in the art that other drawings can be obtained according to these drawings without inventive labor.
FIG. 1 is a flow chart illustrating the steps of a method for authentication token management according to an embodiment of the present application;
FIG. 2 is a flow chart showing the steps of an authentication token generation process of an embodiment of the present application;
FIG. 3 is a flow chart illustrating the steps of an authentication token validation process in an embodiment of the present application;
fig. 4 is a block diagram showing a configuration of an authentication token management apparatus according to an embodiment of the present application;
fig. 5 is a block diagram showing a configuration of an electronic device according to an embodiment of the present application;
fig. 6 is a schematic diagram showing a hardware configuration of an electronic device according to an embodiment of the present application.
Detailed Description
The technical solutions in the embodiments of the present application will be described clearly 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 that can be derived by one of ordinary skill in the art from the embodiments given herein are intended to be within the scope of the present disclosure.
The terms first, second and the like in the description and in the claims of the present application are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It will be appreciated that the data so used may be interchanged under appropriate circumstances such that embodiments of the application may be practiced in sequences other than those illustrated or described herein, and that the terms "first," "second," and the like are generally used herein in a generic sense and do not limit the number of terms, e.g., the first term can be one or more than one. In addition, "and/or" in the specification and claims means at least one of connected objects, a character "/" generally means that a preceding and succeeding related objects are in an "or" relationship.
The device detection method provided by the embodiment of the present application is described in detail below with reference to the accompanying drawings through specific embodiments and application scenarios thereof.
Referring to fig. 1, a flowchart illustrating steps of a method for managing an authentication token according to an embodiment of the present application is shown.
The identity authentication token management method of the embodiment of the application comprises the following steps:
step 101: and receiving a login request sent by a client.
The token management method, namely the identity authentication token, can be applied to a server, a token management program is arranged in the server, and the token for authenticating the identity of the client can be managed by operating the token management program. The whole token management can be divided into two parts, wherein the first part is a process of generating the token for the client after the client successfully logs in after a login request sent by the client; and the second part is the process of carrying out identity verification on the client based on the token reported by the client when the client carries out a subsequent service request.
The login request carries a login account and a unique client identity. The client unique identity comprises at least one of the following: browser fingerprint, unique identification of client device.
Step 102: a system first timestamp is obtained.
And after the server verifies the login account in the login request sent by the client, the client successfully logs in. The server generates a corresponding token for the client according to the information carried in the login request and the current first timestamp of the system, and the specific manner of generating the token refers to the relevant description in step 103.
Step 103: and generating a token according to the login account, the unique identity of the client and the first timestamp.
The token generated by the server is used for performing identity authentication on the client, when a subsequent client sends a service request to the server, the token is carried in the service request, and the server determines the identity of the client based on the token.
One feasible way to generate tokens is: and symmetrically encrypting the login account and the first timestamp by taking the unique identity of the client as a secret key to generate a token.
Specifically, when a token is generated by symmetrically encrypting a login account and a first time stamp by taking a unique identity of a client as a secret key, the login account and the first time stamp can be spliced according to a preset rule to obtain an object to be encrypted; and symmetrically encrypting the spliced objects to be encrypted by adopting the unique identity of the client to generate the token.
In the actual implementation process, the preset rule may be set by a person skilled in the art according to actual requirements, and this is not specifically limited in the embodiment of the present application. For example: the preset rule may be set to splice the login account before the first timestamp, or splice the login account after the first timestamp, and the like.
The encryption may employ an encryption algorithm for this, such as: AES, DES, 3 DES.
Another feasible way to generate tokens is: and symmetrically encrypting the login account, the first timestamp and the unique client identity by taking the unique client identity as a secret key to generate the token.
The splicing rule of the login account, the first timestamp and the unique client identity can be flexibly set by a person skilled in the art, and the splicing rule is not specifically limited in the embodiment of the application.
Step 104: the token is returned to the client.
After the server generates the token for the client, the token is directly returned to the client, and all interface requests sent to the server by subsequent clients need to carry the token and the unique identity of the client except for basic request parameters, so that the server can carry out identity authentication on the client according to the token carried in the interface requests.
According to the identity authentication token management method provided by the embodiment of the application, a login request sent by a client is received, a first time stamp of a system is obtained, a token is generated according to the login account number, the unique identity of the client and the first time stamp, and the generated token is returned to the client so that the client can perform identity authentication on the client according to the token carried in a call request when the client sends the call request. According to the token management scheme, the server does not need to cache any token data, a cache database such as Redis can be prevented from being installed for caching the token data, the storage pressure of the server can be reduced, and the server is light.
In an optional embodiment, after returning the token to the client, the method further comprises: the server receives a calling request sent by a client; analyzing the calling request to obtain a token, a request parameter and a unique identity of the client; decrypting the token by using the unique identity of the client to obtain a first timestamp and a first login account; and performing identity authentication on the client based on the first timestamp, the first login account and the request parameter.
The call request carries the token, the request parameter and the unique identity of the client.
It should be noted that, the above description is only given by taking an example of encrypting the timestamp and the login account by the unique identity of the client to generate the token. If the token is generated by encrypting the timestamp, the login account and the unique identity of the client by the unique identity of the client, the first timestamp and the first login account can be obtained after the token is decrypted based on the unique identity of the client.
The token carried in the call request sent by the client is decrypted, and the identity of the client is verified based on the login account and the timestamp obtained by decryption, so that the token does not need to be stored on the server side, and the aim of verifying the identity of the client can be fulfilled.
In an optional embodiment, based on the first timestamp, the first login account number, and the request parameter, the manner of authenticating the client may be as follows:
firstly, comparing whether a first login account is matched with a login account carried in request parameters;
if the time validity of the token is judged according to the first time stamp in the matching execution; and if not, determining that the client authentication is not passed. A hint that the token is invalid may be returned to the client.
Secondly, judging the timeliness of the token according to the first timestamp if the token is matched with the first timestamp;
and finally, determining that the client identity authentication is passed under the condition that the timeliness of the token is effective.
And under the condition that the timeliness of the token is invalid, determining that the authentication of the client fails, and returning a prompt message of overtime of the token to the client.
According to the method for verifying the identity of the client based on the login account and the timestamp, the verification result is more accurate and reliable.
In an alternative embodiment, the manner of determining the timeliness of the token according to the first timestamp may be as follows:
acquiring a second timestamp corresponding to the current time of the system; calculating a time interval between the second time stamp and the first time stamp; determining that the timeliness of the token is effective under the condition that the time interval is greater than a preset threshold value; and determining the timeliness of the token to be invalid when the time interval is less than or equal to a preset threshold value.
The preset threshold may be flexibly set by a person skilled in the art, and is not particularly limited in the embodiment of the present application.
This method of determining timeliness of the token based on the time interval between the two timestamps reduces the amount of computation, and can reduce the computation load on the server.
Referring to fig. 2, a flowchart illustrating steps of an authentication token generation process according to an embodiment of the present application is shown.
The identity authentication token generation process of the embodiment of the application comprises the following steps:
step 201: the client acquires the unique identifier.
The identity authentication token generation process in the embodiment of the present application is explained from the interaction perspective of the client and the server.
Step 202: the client sends a login request to the server.
The login request carries the acquired unique ID, namely the unique identity of the client. The client acquires the unique identifier, which may include but is not limited to a browser fingerprint, a mobile terminal unique ID, and the like, and then carries the unique identifier together with the login information and submits the unique identifier to the server for login.
Step 203: the server parses the unique ID and login account number from the login request.
And after receiving the login request, the server normally logs in and returns the login failure. And if the login is successful, executing a token generation related process, specifically including the steps 204 to 205, acquiring a server timestamp by the server, then splicing and encrypting the server timestamp, the unique ID and the login account.
Step 204: the server obtains the current timestamp.
Wherein the current timestamp is the first timestamp.
The introduction of the time stamp can effectively verify the token issuing and timeliness.
Step 205: and the server encrypts the first timestamp, the login account and the unique ID by using the unique ID as a secret key to generate a ticket.
Symmetric encryption algorithms can be adopted for encryption, such as AES, DES, 3DES and the like, and the security of the ticket can be improved.
It should be noted that the server may also encrypt the first timestamp and generate a ticket by using the unique ID as a key.
Step 206: the server returns a token to the client.
And the token is generated and then sent to a login client, the client finishes login operation at the moment, and the client records the token. All interface requests sent by subsequent clients to the server need to be carried with the token and the unique ID of the client except for basic request parameters, so that the server can perform identity authentication on the client based on the token. The token validation process is explained below with reference to fig. 3. Referring to fig. 3, a flowchart illustrating steps of an authentication token verification process according to an embodiment of the present application is shown.
The authentication process of the authentication token in the embodiment of the application is explained from the interaction angle between the client and the server.
The authentication process of the authentication token of the embodiment of the application comprises the following steps:
step 301: the client invokes the interface.
Step 302: the client sends a call request to the server.
The call request carries a ticket, a service parameter, i.e., a request parameter, and a unique ID.
Step 303: the server obtains a ticket, a service parameter and a unique ID.
After the server side takes the token, authentication is started: and symmetrically decrypting the unique ID of the client to obtain the login account, the unique ID and the first timestamp.
Step 304: and the server decrypts the ticket by adopting the unique ID to obtain the generation time and the account number during generation.
The time, namely the first time stamp, is generated, and the account, namely the login account, is generated.
Step 305: comparing the login accounts and determining whether the ticket is valid; if yes, go to step 306; if not, go to step 307.
The login account can be compared with the login accounts in the parameters, and the token is prevented from being falsely used by other login accounts. And outputting the prompt information that the token is invalid when the comparison fails.
Step 306: comparing the timestamps to determine whether the ticket is valid; if yes, go to step 308; if not, step 309 is performed.
And after the first time stamp is taken, the first time stamp is the issuing time of the token, the first time stamp is compared with the current time of the server, if the first time stamp is larger than the preset value delta, the token overtime can be returned, the verification fails, the overtime prompt information of the token can be given, and the client can conveniently quit and log in again.
Step 307: and the server returns a ticket invalid prompt message to the client.
Step 308: the server completes the authentication of the client, executes other service functions, and returns an acquired interface return value to the client.
Step 309: and the server returns a ticket overtime prompt message to the client.
In the above way, the whole process realizes all functions of the token, but the server does not cache any token data, so that the installation of cache databases such as Redis is avoided, and the server can be lightened.
Steps 301 to 309 are procedures for verifying the identity of the client by the server in response to the interface call request of the client once. In the actual implementation process, each calling request which needs to be authenticated and is sent to the server by the client triggers the server to execute the ticket authentication process.
According to the identity authentication token management method provided by the embodiment of the application, on one hand, the server does not need to cache any token data, a cache database such as Redis can be prevented from being installed for caching token data, the storage pressure of the server can be reduced, and the server is light. In the second aspect, the server symmetrically encrypts the token, so that the security of the token can be improved. In a third aspect, a token timeout exit or other security function may be provided.
It should be noted that, in the authentication token management method provided in the embodiment of the present application, the execution subject may be an authentication token management apparatus, or a control module in the authentication token management apparatus for executing the method for managing the authentication token. In the embodiment of the present application, an authentication token management apparatus executes an authentication token management method as an example, and the authentication token management apparatus provided in the embodiment of the present application is described.
Fig. 4 is a block diagram of an authentication token management apparatus for implementing an embodiment of the present application.
The identity authentication token management device of the embodiment of the application is applied to a server, and comprises the following functional modules: a first receiving module 401, configured to receive a login request sent by a client, where the login request carries a login account and a unique client identity; a first obtaining module 402, configured to obtain a system first timestamp; the encryption module 403 is configured to generate a token according to the login account, the unique client identity, and the first timestamp, where the token is used to perform identity authentication on the client; a sending module 404, configured to return the token to the client.
Optionally, the encryption module is specifically configured to: and symmetrically encrypting the login account and the first timestamp by taking the unique identity of the client as a secret key to generate a token.
Optionally, the apparatus further comprises: the second receiving module is configured to receive a call request sent by the client after the token is returned to the client by the sending module, where the call request carries the token, a request parameter, and a unique identity of the client; the analysis module is used for analyzing the calling request to obtain a token, request parameters and a unique identity of the client; the decryption module is used for decrypting the token by adopting the unique identity of the client to obtain a first timestamp and a first login account; and the verification module is used for verifying the identity of the client based on the first timestamp, the first login account and the request parameters.
Optionally, the verification module comprises: the comparison submodule is used for comparing whether the first login account is matched with the login account carried in the request parameter or not; the timeliness judging submodule is used for judging the timeliness of the token according to the first timestamp if the matching is carried out; and the result determining submodule is used for determining that the client identity is verified under the condition that the timeliness of the token is effective.
Optionally, the timeliness determination sub-module is specifically configured to: acquiring a second timestamp corresponding to the current time of the system; calculating a time interval between the second timestamp and the first timestamp; determining that the timeliness of the token is effective when the time interval is greater than a preset threshold; determining that the timeliness of the token is invalid if the time interval is less than or equal to the preset threshold.
Optionally, the encryption module includes: the splicing submodule is used for splicing the login account and the first timestamp according to a preset rule to obtain an object to be encrypted; and the symmetric encryption submodule is used for symmetrically encrypting the spliced objects to be encrypted by adopting the unique identity of the client to generate a token.
Optionally, the client unique identity includes at least one of: a browser fingerprint, a unique identification of the client device.
The identity authentication token management device provided by the embodiment of the application receives a login request sent by a client, acquires a first time stamp of a system, generates a token according to the login account number, the unique identity of the client and the first time stamp, and returns the generated token to the client so as to authenticate the identity of the client according to the token carried in a call request when the client sends the call request. When the token management device is applied to the server, the server does not need to cache any token data, a cache database such as Redis can be prevented from being installed for caching the token data, the storage pressure of the server can be reduced, and the server is light.
The authentication token management apparatus shown in fig. 4 in this embodiment may be an apparatus, or may be a component, an integrated circuit, or a chip in a server. The authentication token management apparatus shown in fig. 4 in the embodiment of the present application may be an apparatus having an operating system. The operating system may be an Android operating system (Android), an iOS operating system, or other possible operating systems, which is not specifically limited in the embodiments of the present application.
The authentication token management apparatus shown in fig. 4 provided in the embodiment of the present application can implement each process implemented by the method embodiments of fig. 1 to fig. 3, and is not described here again to avoid repetition.
Optionally, as shown in fig. 5, an electronic device 500 is further provided in this embodiment of the present application, and includes a processor 501, a memory 502, and a program or an instruction stored in the memory 502 and executable on the processor 501, where the program or the instruction is executed by the processor 501 to implement each process of the authentication token management method in the embodiment, and can achieve the same technical effect, and in order to avoid repetition, details are not repeated here.
It should be noted that the electronic device in the embodiment of the present application includes the server described above.
Fig. 6 is a schematic diagram of a hardware structure of an electronic device implementing an embodiment of the present application.
The electronic device 600 includes, but is not limited to: a radio frequency unit 601, a network module 602, an audio output unit 603, an input unit 604, a sensor 605, a display unit 606, a user input unit 607, an interface unit 608, a memory 609, a processor 610, and the like. Those skilled in the art will appreciate that the electronic device 600 may further comprise a power source (e.g., a battery) for supplying power to the various components, and the power source may be logically connected to the processor 610 through a power management system, so as to implement functions of managing charging, discharging, and power consumption through the power management system. The electronic device structure shown in fig. 6 does not constitute a limitation of the electronic device, and the electronic device may include more or less components than those shown, or combine some components, or arrange different components, and thus, the description is omitted here.
The processor 610 is configured to receive a login request sent by a client, where the login request carries a login account and a unique client identity; acquiring a first timestamp of a system; generating a token according to the login account, the unique client identity and the first timestamp, wherein the token is used for performing identity authentication on the client; returning the token to the client.
It is to be understood that, in the embodiment of the present application, the input Unit 604 may include a Graphics Processing Unit (GPU) 6041 and a microphone 6042, and the Graphics Processing Unit 6041 processes image data of a still picture or a video obtained by an image capturing apparatus (such as a camera) in a video capturing mode or an image capturing mode. The display unit 606 may include a display panel 6061, and the display panel 6061 may be configured in the form of a liquid crystal display, an organic light emitting diode, or the like. The user input unit 607 includes a touch panel 6071 and other input devices 6072. A touch panel 6071, also referred to as a touch screen. The touch panel 6071 may include two parts of a touch detection device and a touch controller. Other input devices 6072 may include, but are not limited to, a physical keyboard, function keys (e.g., volume control keys, switch keys, etc.), a trackball, a mouse, and a joystick, which are not described in detail herein. The memory 609 may be used to store software programs as well as various data including, but not limited to, application programs and an operating system. The processor 610 may integrate an application processor, which primarily handles operating systems, user interfaces, applications, etc., and a modem processor, which primarily handles wireless communications. It will be appreciated that the modem processor described above may not be integrated into the processor 610.
The embodiment of the present application further provides a readable storage medium, where a program or an instruction is stored on the readable storage medium, and when the program or the instruction is executed by a processor, the process of the embodiment of the authentication token management method is implemented, and the same technical effect can be achieved, and in order to avoid repetition, details are not repeated here.
The processor is the processor in the electronic device described in the above embodiment. The readable storage medium includes a computer readable storage medium, such as a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk, and so on.
The embodiment of the present application further provides a chip, where the chip includes a processor and a communication interface, the communication interface is coupled to the processor, and the processor is configured to execute a program or an instruction to implement each process of the embodiment of the authentication token management method, and can achieve the same technical effect, and in order to avoid repetition, the description is omitted here.
It should be understood that the chips mentioned in the embodiments of the present application may also be referred to as system-on-chip, system-on-chip or system-on-chip, etc.
It should be noted that, in this document, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element. Further, it should be noted that the scope of the methods and apparatus of the embodiments of the present application is not limited to performing the functions in the order illustrated or discussed, but may include performing the functions in a substantially simultaneous manner or in a reverse order based on the functions involved, e.g., the methods described may be performed in an order different than that described, and various steps may be added, omitted, or combined. In addition, features described with reference to certain examples may be combined in other examples.
Through the above description of the embodiments, those skilled in the art will clearly understand that the method of the above embodiments can be implemented by software plus a necessary general hardware platform, and certainly can also be implemented by hardware, but in many cases, the former is a better implementation manner. Based on such understanding, the technical solutions of the present application may be embodied in the form of a computer software product, which is stored in a storage medium (such as ROM/RAM, magnetic disk, optical disk) and includes instructions for enabling a terminal (such as a mobile phone, a computer, a server, or a network device) to execute the method according to the embodiments of the present application.
While the present embodiments have been described with reference to the accompanying drawings, it is to be understood that the invention is not limited to the precise embodiments described above, which are meant to be illustrative and not restrictive, and that various changes may be made therein by those skilled in the art without departing from the spirit and scope of the invention as defined by the appended claims.
Claims (10)
1. An authentication token management method applied to a server is characterized by comprising the following steps:
receiving a login request sent by a client, wherein the login request carries a login account and a unique client identity;
acquiring a first timestamp of a system;
generating a token according to the login account, the unique client identity and the first timestamp, wherein the token is used for performing identity authentication on the client;
returning the token to the client.
2. The method of claim 1, wherein generating a token in accordance with the login account number, the client unique id, and the first timestamp comprises:
and symmetrically encrypting the login account and the first timestamp by taking the unique identity of the client as a secret key to generate a token.
3. The method of claim 1, wherein after the returning the token to the client, the method further comprises:
receiving a call request sent by the client, wherein the call request carries a token, a request parameter and a unique identity of the client;
analyzing the call request to obtain a token, request parameters and a unique identity of the client;
decrypting the token by using the unique identity of the client to obtain a first timestamp and a first login account;
and performing identity verification on the client based on the first timestamp, the first login account and the request parameter.
4. The method of claim 3, wherein authenticating the client based on the first timestamp, the first login account number, and the request parameters comprises:
comparing whether the first login account is matched with the login account carried in the request parameter;
if so, judging the timeliness of the token according to the first timestamp;
and determining that the client identity authentication is passed under the condition that the timeliness of the token is effective.
5. The method of claim 4, wherein said determining the timeliness of the token in accordance with the first timestamp comprises:
acquiring a second timestamp corresponding to the current time of the system;
calculating a time interval between the second timestamp and the first timestamp;
determining that the timeliness of the token is effective when the time interval is greater than a preset threshold;
determining that the timeliness of the token is invalid if the time interval is less than or equal to the preset threshold.
6. The method according to claim 2, wherein symmetrically encrypting the login account and the first timestamp with the client unique identity as a key to generate a token comprises:
splicing the login account and the first timestamp according to a preset rule to obtain an object to be encrypted;
and symmetrically encrypting the spliced objects to be encrypted by adopting the unique identity of the client to generate a token.
7. The method of claim 1, wherein the client unique identity comprises at least one of: a browser fingerprint, a unique identification of the client device.
8. An authentication token management apparatus applied to a server, the apparatus comprising:
the system comprises a first receiving module, a second receiving module and a third receiving module, wherein the first receiving module is used for receiving a login request sent by a client, and the login request carries a login account and a unique client identity;
the first acquisition module is used for acquiring a first timestamp of the system;
the encryption module is used for generating a token according to the login account, the unique client identity and the first timestamp, wherein the token is used for carrying out identity verification on the client;
and the sending module is used for returning the token to the client.
9. The apparatus of claim 8, wherein the encryption module is specifically configured to:
and symmetrically encrypting the login account and the first timestamp by taking the unique identity of the client as a secret key to generate a token.
10. The apparatus of claim 8, further comprising:
the second receiving module is configured to receive a call request sent by the client after the token is returned to the client by the sending module, where the call request carries the token, a request parameter, and a unique identity of the client;
the analysis module is used for analyzing the calling request to obtain a token, request parameters and a unique identity of the client;
the decryption module is used for decrypting the token by adopting the unique identity of the client to obtain a first timestamp and a first login account;
and the verification module is used for verifying the identity of the client based on the first timestamp, the first login account and the request parameters.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111677137.7A CN114338212A (en) | 2021-12-31 | 2021-12-31 | Identity authentication token management method and device, electronic equipment and readable storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111677137.7A CN114338212A (en) | 2021-12-31 | 2021-12-31 | Identity authentication token management method and device, electronic equipment and readable storage medium |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN114338212A true CN114338212A (en) | 2022-04-12 |
Family
ID=81023580
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202111677137.7A Pending CN114338212A (en) | 2021-12-31 | 2021-12-31 | Identity authentication token management method and device, electronic equipment and readable storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114338212A (en) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115865379A (en) * | 2023-02-27 | 2023-03-28 | 广东省信息工程有限公司 | Stateless distributed authentication method, client, authentication server and medium |
| CN116567052A (en) * | 2023-07-11 | 2023-08-08 | 腾讯科技（深圳）有限公司 | Network connection method, device, computer equipment and storage medium |
| WO2024092565A1 (en) * | 2022-11-02 | 2024-05-10 | 京东方科技集团股份有限公司 | Identifier acquisition method, apparatus, device and medium |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104821937A (en) * | 2015-03-26 | 2015-08-05 | 腾讯科技（北京）有限公司 | Token acquisition method, device and system |
| US20150310194A1 (en) * | 2014-04-29 | 2015-10-29 | Bank Of America Corporation | Authentication Using Device ID |
| CN107809317A (en) * | 2017-11-09 | 2018-03-16 | 郑州云海信息技术有限公司 | A kind of identity identifying method and system based on token digital signature |
| CN109327477A (en) * | 2018-12-06 | 2019-02-12 | 泰康保险集团股份有限公司 | Authentication method, device and storage medium |
| CN111371805A (en) * | 2020-03-17 | 2020-07-03 | 北京工业大学 | Token-based unified identity authentication interface and method |
-
2021
- 2021-12-31 CN CN202111677137.7A patent/CN114338212A/en active Pending
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20150310194A1 (en) * | 2014-04-29 | 2015-10-29 | Bank Of America Corporation | Authentication Using Device ID |
| CN104821937A (en) * | 2015-03-26 | 2015-08-05 | 腾讯科技（北京）有限公司 | Token acquisition method, device and system |
| CN107809317A (en) * | 2017-11-09 | 2018-03-16 | 郑州云海信息技术有限公司 | A kind of identity identifying method and system based on token digital signature |
| CN109327477A (en) * | 2018-12-06 | 2019-02-12 | 泰康保险集团股份有限公司 | Authentication method, device and storage medium |
| CN111371805A (en) * | 2020-03-17 | 2020-07-03 | 北京工业大学 | Token-based unified identity authentication interface and method |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2024092565A1 (en) * | 2022-11-02 | 2024-05-10 | 京东方科技集团股份有限公司 | Identifier acquisition method, apparatus, device and medium |
| CN115865379A (en) * | 2023-02-27 | 2023-03-28 | 广东省信息工程有限公司 | Stateless distributed authentication method, client, authentication server and medium |
| CN116567052A (en) * | 2023-07-11 | 2023-08-08 | 腾讯科技（深圳）有限公司 | Network connection method, device, computer equipment and storage medium |
| CN116567052B (en) * | 2023-07-11 | 2023-09-15 | 腾讯科技（深圳）有限公司 | Network connection method, device, computer equipment and storage medium |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN106850699B (en) | A kind of mobile terminal login authentication method and system | |
| CN106330850B (en) | Security verification method based on biological characteristics, client and server | |
| CN114338212A (en) | Identity authentication token management method and device, electronic equipment and readable storage medium | |
| JP2018532301A (en) | User authentication method and apparatus | |
| CN108616360B (en) | User identity verification and registration method and device | |
| CN111431719A (en) | Mobile terminal password protection module, mobile terminal and password protection method | |
| CN111556006A (en) | Third-party application system login method, device, terminal and SSO service platform | |
| CN111708991A (en) | Service authorization method, service authorization device, computer equipment and storage medium | |
| CN105516104A (en) | Identity verification method and system of dynamic password based on TEE (Trusted execution environment) | |
| CN108322416B (en) | Security authentication implementation method, device and system | |
| CN109145628B (en) | Data acquisition method and system based on trusted execution environment | |
| EP2251810A1 (en) | Authentication information generation system, authentication information generation method, and authentication information generation program utilizing a client device and said method | |
| CN114900338A (en) | Encryption and decryption method, device, equipment and medium | |
| US20180357638A1 (en) | Identity information authentication method, user terminal, service terminal, authentication server, and service system | |
| CN110830471B (en) | OTP (one time password) verification method, server, client and computer-readable storage medium | |
| CN102098162A (en) | Method for performing safety management of operation and maintenance based on security token | |
| CN112232814A (en) | Encryption and decryption method of payment key, payment authentication method and terminal equipment | |
| CN104426659A (en) | Dynamic password generating method, authentication method, authentication system and corresponding equipment | |
| CN111460410A (en) | Server login method, device and system and computer readable storage medium | |
| CN113055182B (en) | Authentication method and system, terminal, server, computer system, and medium | |
| CN112380501B (en) | Equipment operation method, device, equipment and storage medium | |
| CN113205342A (en) | User identity authentication method and device based on multi-terminal payment | |
| CN112351043A (en) | Vehicle navigation factory setting password management method and system | |
| CN114584324B (en) | Identity authorization method and system based on block chain | |
| CN115550002B (en) | TEE-based intelligent home remote control method and related device |
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 |