CN111030812A - Token verification method, device, storage medium and server - Google Patents
Token verification method, device, storage medium and serverDownload PDFInfo
- Publication number
- CN111030812A CN111030812ACN201911290205.7ACN201911290205ACN111030812ACN 111030812 ACN111030812 ACN 111030812ACN 201911290205 ACN201911290205 ACN 201911290205ACN 111030812 ACN111030812 ACN 111030812A
- Authority
- CN
- China
- Prior art keywords
- token
- client
- request
- database
- timestamp
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/088—Usage controlling of secret information, e.g. techniques for restricting cryptographic keys to pre-authorized uses, different access levels, validity of crypto-period, different key- or password length, or different strong and weak cryptographic algorithms
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
- H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3297—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving time stamps, e.g. generation of time stamps
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Computer And Data Communications (AREA)
Abstract
Translated fromChinese
Description
Technical Field
The present application relates to the field of computer technologies, and in particular, to a token verification method, an apparatus, a storage medium, and a server.
Background
In some scenarios, before the client calls the service of the server, the client needs to provide the ID and Secret allocated to the client by the server for authentication, after the server successfully authenticates, a token is returned to the client, the client subsequently calls the server of the server to take the token, and the server receives the call request of the client after confirming that the token is legal.
When judging whether a token is legal, firstly, the server judges whether the token is distributed by the server by inquiring the database, and then judges whether the token is overdue. In the process, the server needs to query the database for verification once every time the client initiates a request. When a client maliciously initiates a large number of service requests, it may cause the server to deny service.
Disclosure of Invention
The embodiment of the application provides a token verification method, a token verification device, a storage medium and a server, which can reduce the frequency of legally verifying a token by inquiring a database and reduce the risk of service denial of the server. The technical scheme is as follows:
in a first aspect, an embodiment of the present application provides a token verification method, where the method includes:
receiving a service calling request sent by a client, and acquiring a token carried by the service calling request;
reading a token generation timestamp in the token, and acquiring a current timestamp;
when the time difference between the token generation timestamp and the current timestamp is less than or equal to the valid duration, searching whether the token exists in a database;
and if the token exists in the database, executing the service calling request and feeding back a request result to the client.
In a second aspect, an embodiment of the present application provides a token verification apparatus, including:
the token acquisition module is used for receiving a service calling request sent by a client and acquiring a token carried by the service calling request;
the time stamp obtaining module is used for reading a token in the token to generate a time stamp and obtaining a current time stamp;
a token searching module, configured to search, when a time difference between the token generation timestamp and the current timestamp is less than or equal to a valid duration, whether the token exists in a database;
and the request execution module is used for executing the service calling request and feeding back a request result to the client if the token exists in the database.
In a third aspect, embodiments of the present application provide a computer storage medium storing a plurality of instructions adapted to be loaded by a processor and to perform the above-mentioned method steps.
In a fourth aspect, an embodiment of the present application provides a server, which may include: a processor and a memory; wherein the memory stores a computer program adapted to be loaded by the processor and to perform the above-mentioned method steps.
The beneficial effects brought by the technical scheme provided by some embodiments of the application at least comprise:
in the embodiment of the application, a server receives a service calling request sent by a client, acquires a token carried by the service calling request, generates a timestamp by reading the token in the token, acquires a current timestamp, and executes the service calling request and feeds back a request result to the client when a time difference between the token generation timestamp and the current timestamp is less than or equal to an effective time and the token exists in a database. That is to say, whether the token is expired can be confirmed by generating the timestamp by the token carried by the token, and the validity of the token in the database can be inquired only when the token is not expired, so that even if a client maliciously initiates a large number of service requests, the database is inquired by the client without the need of the client for requesting the server once, the frequency of the inquiry database for legally verifying the token is reduced, and the risk of the server rejecting service is reduced.
Drawings
In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments of the present application, and for those skilled in the art, other drawings can be obtained according to the drawings without creative efforts.
Fig. 1 is a schematic flowchart of a token verification method provided in an embodiment of the present application;
fig. 2 is a schematic flowchart of a token verification method according to an embodiment of the present application;
fig. 3 is a schematic structural diagram of a token authentication apparatus according to an embodiment of the present application;
fig. 4 is a schematic structural diagram of a token authentication apparatus according to an embodiment of the present application;
fig. 5 is a schematic structural diagram of a server according to an embodiment of the present application.
Detailed Description
In order to make the objects, technical solutions and advantages of the present application more clear, embodiments of the present application will be described in further detail below with reference to the accompanying drawings.
When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the application, as detailed in the appended claims.
In the description of the present application, it is to be understood that the terms "first," "second," and the like are used for descriptive purposes only and are not to be construed as indicating or implying relative importance. The specific meaning of the above terms in the present application can be understood in a specific case by those of ordinary skill in the art. Further, in the description of the present application, "a plurality" means two or more unless otherwise specified. "and/or" describes the association relationship of the associated objects, meaning that there may be three relationships, e.g., a and/or B, which may mean: a exists alone, A and B exist simultaneously, and B exists alone. The character "/" generally indicates that the former and latter associated objects are in an "or" relationship.
The token verification method provided by the embodiment of the present application will be described in detail below with reference to fig. 1 to fig. 2. The method may be implemented in dependence on a computer program operable on a token verification device based on the von neumann architecture. The computer program may be integrated into the application or may run as a separate tool-like application. The token verification apparatus in the embodiment of the present application may be a server having a token verification function.
Fig. 1 is a schematic flowchart of a token verification method according to an embodiment of the present disclosure. As shown in fig. 1, the method of the embodiment of the present application may include the steps of:
s101, receiving a service calling request sent by a client, and acquiring a token carried by the service calling request;
the client initiates the service call request in the following three ways:
1. by means of hyperlinks
This request belongs to a get request, and the write parameters can pass parameters to the client in a key-value pair manner with a post-query number, such as < a href? Add > submit request.
2. By means of form
This request may be a post request or a get request.
If the post request can be followed by an action, a request parameter can be added, such as < form action? A "move" method ">, if the get request cannot be followed by the action to join the request parameter (if the join parameter server cannot receive the parameter), e.g., < form action"/Optimize _ progress/Servlet 01? If the method is equal to remove, "get", the server does not receive this actual parameter.
3. By means of ajax
Such as $. post (URL, data, callback, dataType), where the URL parameter specifies the URL that is desired to be requested, the data parameter specifies the data that is sent along with the request, the callback parameter is the name of the function that is executed after the request is successful, and the dataType specifies the data type of the expected server response, such as xml, json, script, or html.
When receiving a service invocation request sent by a client in any of the above manners, the server reads relevant information carried in the request, such as a token, an invoked service, invocation time, and the like.
The Token is Token, and is generated at the server. Before calling the service, the client also needs to use the user name/password to request authentication from the server, and if the authentication of the server is successful, the server generates token and returns the token to the client. The client can take Token to prove the legal status of the client at the time of each request. Accordingly, the Token is persisted (e.g., stored in a database) at the server, which is a permanent identity Token.
Token has the following advantages: the system is completely managed by application, and homologous strategies can be avoided; CSRF attacks can be avoided; may be stateless and may be shared among multiple services.
S102, reading a token generation timestamp in the token, and acquiring a current timestamp;
a time stamp is a complete, verifiable piece of data, usually a sequence of characters, that represents a piece of data that existed before a particular time, uniquely identifying the time of the moment.
The token generation timestamp is a timestamp in a token sent by the client to the server, but the token generation timestamp is not necessarily a token generation timestamp of a token generated before the service invocation request, because in the transmission process of the server generating the token and sending the token to the client, the token may be stolen or the client may be stolen after the token arrives at the client, and the token generation timestamp is replaced or changed.
The current timestamp is the timestamp indicated by the time the server received the service invocation request. Specifically, the current timestamp may be read when the service invocation request is received.
S103, when the time difference between the token generation time stamp and the current time stamp is less than or equal to the effective time length, searching whether the token exists in a database;
to prevent the token from being stolen by other users, an expiration time is typically set for the token. The validity duration of all tokens is a fixed value, such as 5 minutes. And the Token state is stored at the server side, and the expiration time of the Token can be automatically refreshed by the user every time of operation.
When the time difference between the token generation timestamp and the current timestamp is less than or equal to the valid duration, it indicates that the token is still within the valid duration and is not expired, and it is further necessary to determine whether the token is a valid token. I.e. to look up in the database whether the token is present.
It should be noted that, when the server authenticates the account id and the account password sent by the client, if the authentication is passed, a token is generated and stored in the database.
And S104, if the token exists in the database, executing the service calling request and feeding back a request result to the client.
If the token exists in the database, the token is a legal token, the service calling request of the client can be accepted, the service calling request is executed, and the request result is fed back to the client, so that one-time service calling is completed.
In the embodiment of the application, a server receives a service calling request sent by a client, acquires a token carried by the service calling request, generates a timestamp by reading the token in the token, acquires a current timestamp, and executes the service calling request and feeds back a request result to the client when a time difference between the token generation timestamp and the current timestamp is less than or equal to an effective time and the token exists in a database. That is to say, whether the token is expired can be confirmed by generating the timestamp by the token carried by the token, and the validity of the token in the database can be inquired only when the token is not expired, so that even if a client maliciously initiates a large number of service requests, the database is inquired by the client without the need of the client for requesting the server once, the frequency of the inquiry database for legally verifying the token is reduced, and the risk of the server rejecting service is reduced.
Please refer to fig. 2, which is a flowchart illustrating a token verification method according to an embodiment of the present disclosure. The embodiment shown in fig. 2 differs from the embodiment shown in fig. 1 in that emphasizing the authentication process, the token expiration or the token illegal process before the service invocation, the token verification method may comprise the following steps:
s201, receiving an authentication request sent by a client, and acquiring an account identifier and an account password carried by the authentication request;
it can be understood that the client initiates a registration request to the server in advance, and after the registration is completed, the server allocates an account identifier (user name) and an account password to the client. Correspondingly, the server stores the allocated account identification and account password in a database. For example, as shown in table 1, a mapping relationship table of account id and account password assigned to each client is stored in the server, and the mapping relationship table is stored in the database.
TABLE 1
| Account identification | Account password |
| User name 1 | 111111 |
| User name 2 | 222222 |
| …… | …… |
| User name x | xxxxxx |
The authentication request is a verification request of the account identification and the account password. Namely, a user logs in an account through a client, so that an authentication request carrying an account identifier and an account password input during login is generated and sent to a server.
S202, when the account identification exists in the database and is matched with the account password, a token is generated;
as shown in table 1, first, whether the account id exists is searched in an account id column, if so, it is further determined whether the account password matches the account id, and if so, it is determined that the account id is allocated by the server, and if the authentication passes, a token is generated. At the same time, the server saves the token to the database. As shown in table 2, a plurality of tokens generated when the client passes authentication are included in the database, and it is understood that each token corresponds to an account id.
TABLE 2
| Token | Account identification |
| Token 1 | User name 1 |
| Token 2 | User name 2 |
| …… | …… |
| Token x | User name x |
The Token is Token, and is generated at the server. Before calling the service, the client also needs to use the user name/password to request authentication from the server, and if the authentication of the server is successful, the Token is generated at the server and returned to the client. The client can take Token to prove the legal status of the client at the time of each request. Accordingly, the Token is persisted (e.g., stored in a database) at the server, which is a permanent identity Token.
Token has the following advantages: the system is completely managed by application, and homologous strategies can be avoided; cross-site request forgery (CSRF) attacks can be avoided; may be stateless and may be shared among multiple services.
S203, encrypting the token and sending the encrypted token to the client;
generally, to prevent the token generation timestamp from being cracked, the token may be encrypted, and the client may decrypt using a corresponding algorithm after receiving the token.
Alternatively, if all the state information is attached to Token, the server may not store it. But the server still needs to authenticate the validity of Token. However, as long as the server can confirm that the Token is issued by itself and the information of the Token is not changed, the Token can be considered to be valid. In general, since signatures are issued by one party and verified by the other party, an asymmetric encryption algorithm is used. However, here, issuance and verification are the same party, so a symmetric encryption algorithm can meet the requirements, which is much faster than an asymmetric algorithm
S204, receiving a service calling request sent by the client when the token is received, and acquiring the token carried by the service calling request;
the client-initiated service invocation request may be in the form of a hyperlink or in the form of ajax. When receiving a service invocation request sent by a client in any of the above manners, the server reads relevant information carried in the request, such as a token, an invoked service, invocation time, and the like.
S205, reading a token generation timestamp in the token, and acquiring a current timestamp;
a time stamp is a complete, verifiable piece of data, usually a sequence of characters, that represents a piece of data that existed before a particular time, uniquely identifying the time of the moment.
The token generation timestamp is a timestamp in a token sent by the client to the server, but the token generation timestamp is not necessarily a token generation timestamp of a token generated before the service invocation request, because in the transmission process of the server generating the token and sending the token to the client, the token may be stolen or the client may be stolen after the token arrives at the client, and the token generation timestamp is replaced or changed.
The current timestamp is the timestamp indicated by the time the server received the service invocation request. Specifically, the current timestamp may be read when the service invocation request is received.
S206, when the time difference between the token generation timestamp and the current timestamp is larger than the effective duration, feeding back prompt information of token expiration to the client;
the validity duration (expiration duration) is a fixed value, such as 5 minutes, for all tokens.
The server analyzes a timestamp from the token, makes a difference between the timestamp and the current time of the system, if the difference exceeds the expiration time, the token is considered to be expired, and feeds back prompt information of token expiration to the client so as to inform a user that the token is expired in the service calling process, the current service calling fails, and the token needs to be applied again.
S207, when the time difference between the token generation time stamp and the current time stamp is less than or equal to the effective time length, searching whether the token exists in a database;
when the time difference between the token generation timestamp and the current timestamp is less than or equal to the valid duration, it indicates that the token is still within the valid duration and is not expired, and it is further necessary to determine whether the token is a valid token. I.e. to look up in the database whether the token is present.
S208, if the token exists in the database, executing the service calling request and feeding back a request result to the client;
if the token exists in the database, the token is a legal token, the service calling request of the client can be accepted, the service calling request is executed, and the request result is fed back to the client, so that one-time service calling is completed.
And S209, if the token does not exist in the database, feeding back prompt information that the token is illegal to the client.
When the token is not found in the table 2, it is indicated that the token is not generated by the server, the token is confirmed to be illegal, and prompt information that the token is illegal is fed back to the client, so that the user is informed that the token is tampered in the service calling process, and the current service calling fails.
In the embodiment of the application, a server receives a service calling request sent by a client, acquires a token carried by the service calling request, generates a timestamp by reading the token in the token, acquires a current timestamp, and executes the service calling request and feeds back a request result to the client when a time difference between the token generation timestamp and the current timestamp is less than or equal to an effective time and the token exists in a database. That is to say, whether the token is expired can be confirmed by generating the timestamp by the token carried by the token, and the validity of the token in the database can be inquired only when the token is not expired, so that even if a client maliciously initiates a large number of service requests, the database is inquired by the client without the need of the client for requesting the server once, the frequency of the inquiry database for legally verifying the token is reduced, and the risk of the server rejecting service is reduced.
The following are embodiments of the apparatus of the present application that may be used to perform embodiments of the method of the present application. For details which are not disclosed in the embodiments of the apparatus of the present application, reference is made to the embodiments of the method of the present application.
Referring to fig. 3, a schematic structural diagram of a token verification apparatus according to an exemplary embodiment of the present application is shown. The token validation mechanism may be implemented as all or part of the server in software, hardware, or a combination of both. The apparatus 1 includes a token obtainingmodule 10, atimestamp obtaining module 20, atoken lookup module 30, and arequest execution module 40.
The token obtainingmodule 10 is configured to receive a service invocation request sent by a client, and obtain a token carried by the service invocation request;
atimestamp obtaining module 20, configured to read a token in the token to generate a timestamp, and obtain a current timestamp;
atoken searching module 30, configured to search, when a time difference between the token generation timestamp and the current timestamp is less than or equal to a valid duration, whether the token exists in a database;
and therequest execution module 40 is configured to execute the service invocation request and feed back a request result to the client if the token exists in the database.
Optionally, as shown in fig. 4, the apparatus further includes:
and an expirationinformation sending module 50, configured to feed back, to the client, prompt information that the token is expired when a time difference between the token generation timestamp and the current timestamp is greater than the valid duration.
Optionally, as shown in fig. 4, the apparatus further includes:
and an illegalinformation sending module 60, configured to feed back, to the client, prompt information that the token is illegal if the token does not exist in the database.
Optionally, as shown in fig. 4, the apparatus further includes:
an accountinformation obtaining module 70, configured to receive an authentication request sent by a client, and obtain an account token and an account password carried in the authentication request;
and atoken sending module 80, configured to generate a token and send the token to the client when the account token exists in the database and the account token matches the account password.
The token obtainingmodule 10 is specifically configured to:
and receiving a service calling request sent by the client when the token is received, and acquiring the token carried by the service calling request.
Optionally, the token obtainingmodule 10 is specifically configured to:
and encrypting the token and sending the encrypted token to the client.
It should be noted that, when the token verification apparatus provided in the foregoing embodiment executes the token verification method, only the division of the functional modules is illustrated, and in practical applications, the functions may be distributed and completed by different functional modules according to needs, that is, the internal structure of the device may be divided into different functional modules, so as to complete all or part of the functions described above. In addition, the token verification apparatus and the token verification processing method provided in the above embodiments belong to the same concept, and details of implementation processes thereof are referred to in the method embodiments and are not described herein again.
The above-mentioned serial numbers of the embodiments of the present application are merely for description and do not represent the merits of the embodiments.
In the embodiment of the application, a server receives a service calling request sent by a client, acquires a token carried by the service calling request, generates a timestamp by reading the token in the token, acquires a current timestamp, and executes the service calling request and feeds back a request result to the client when a time difference between the token generation timestamp and the current timestamp is less than or equal to an effective time and the token exists in a database. That is to say, whether the token is expired can be confirmed by generating the timestamp by the token carried by the token, and the validity of the token in the database can be inquired only when the token is not expired, so that even if a client maliciously initiates a large number of service requests, the database is inquired by the client without the need of the client for requesting the server once, the frequency of the inquiry database for legally verifying the token is reduced, and the risk of the server rejecting service is reduced.
An embodiment of the present application further provides a computer storage medium, where the computer storage medium may store a plurality of instructions, where the instructions are suitable for being loaded by a processor and executing the method steps in the embodiments shown in fig. 1 to fig. 2, and a specific execution process may refer to specific descriptions of the embodiments shown in fig. 1 to fig. 2, which are not described herein again.
Please refer to fig. 5, which provides a schematic structural diagram of a server according to an embodiment of the present application. As shown in fig. 5, theserver 1000 may include: at least oneprocessor 1001, at least onenetwork interface 1004, auser interface 1003,memory 1005, at least onecommunication bus 1002.
Wherein acommunication bus 1002 is used to enable connective communication between these components.
Theuser interface 1003 may include a Display screen (Display) and a Camera (Camera), and theoptional user interface 1003 may also include a standard wired interface and a wireless interface.
Thenetwork interface 1004 may optionally include a standard wired interface, a wireless interface (e.g., WI-FI interface), among others.
TheMemory 1005 may include a Random Access Memory (RAM) or a Read-Only Memory (Read-Only Memory). Optionally, thememory 1005 includes a non-transitory computer-readable medium. Thememory 1005 may be used to store an instruction, a program, code, a set of codes, or a set of instructions. Thememory 1005 may include a stored program area and a stored data area, wherein the stored program area may store instructions for implementing an operating system, instructions for at least one function (such as a touch function, a sound playing function, an image playing function, etc.), instructions for implementing the various method embodiments described above, and the like; the storage data area may store data and the like referred to in the above respective method embodiments. Thememory 1005 may optionally be at least one memory device located remotely from theprocessor 1001. As shown in fig. 5, amemory 1005, which is one type of computer storage medium, may include an operating system, a network communication module, a user interface module, and a token validation application.
In theserver 1000 shown in fig. 5, theuser interface 1003 is mainly used as an interface for providing input for a user, and acquiring data input by the user; and theprocessor 1001 may be configured to invoke a token validation application stored in thememory 1005 and specifically perform the following operations:
receiving a service calling request sent by a client, and acquiring a token carried by the service calling request;
reading a token generation timestamp in the token, and acquiring a current timestamp;
when the time difference between the token generation timestamp and the current timestamp is less than or equal to the valid duration, searching whether the token exists in a database;
and if the token exists in the database, executing the service calling request and feeding back a request result to the client.
In one embodiment, theprocessor 1001 further performs the following operations:
and when the time difference between the token generation timestamp and the current timestamp is greater than the effective duration, feeding back prompt information of the expired token to the client.
In one embodiment, theprocessor 1001 further performs the following operations:
and if the token does not exist in the database, feeding back prompt information that the token is illegal to the client.
In an embodiment, before executing receiving a service invocation request sent by a client and acquiring a token carried by the service invocation request, theprocessor 1001 further executes the following operations:
receiving an authentication request sent by a client, and acquiring an account identifier and an account password carried by the authentication request;
when the account identification exists in the database and is matched with the account password, generating a token and sending the token to the client;
when executing a service invocation request sent by a receiving client and acquiring a token carried by the service invocation request, theprocessor 1001 specifically executes the following operations:
and receiving a service calling request sent by the client when the token is received, and acquiring the token carried by the service calling request.
In one embodiment, when theprocessor 1001 sends the token to the client, the following operations are specifically performed:
and encrypting the token and sending the encrypted token to the client.
In the embodiment of the application, a server receives a service calling request sent by a client, acquires a token carried by the service calling request, generates a timestamp by reading the token in the token, acquires a current timestamp, and executes the service calling request and feeds back a request result to the client when a time difference between the token generation timestamp and the current timestamp is less than or equal to an effective time and the token exists in a database. That is to say, whether the token is expired can be confirmed by generating the timestamp by the token carried by the token, and the validity of the token in the database can be inquired only when the token is not expired, so that even if a client maliciously initiates a large number of service requests, the database is inquired by the client without the need of the client for requesting the server once, the frequency of the inquiry database for legally verifying the token is reduced, and the risk of the server rejecting service is reduced.
It will be understood by those skilled in the art that all or part of the processes of the methods of the embodiments described above can be implemented by a computer program, which can be stored in a computer-readable storage medium, and when executed, can include the processes of the embodiments of the methods described above. The storage medium may be a magnetic disk, an optical disk, a read-only memory or a random access memory.
The above disclosure is only for the purpose of illustrating the preferred embodiments of the present application and is not to be construed as limiting the scope of the present application, so that the present application is not limited thereto, and all equivalent variations and modifications can be made to the present application.
Claims (10)
1. A method of token validation, the method comprising:
receiving a service calling request sent by a client, and acquiring a token carried by the service calling request;
reading a token generation timestamp in the token, and acquiring a current timestamp;
when the time difference between the token generation timestamp and the current timestamp is less than or equal to the valid duration, searching whether the token exists in a database;
and if the token exists in the database, executing the service calling request and feeding back a request result to the client.
2. The method of claim 1, further comprising:
and when the time difference between the token generation timestamp and the current timestamp is greater than the effective duration, feeding back prompt information of the expired token to the client.
3. The method of claim 1, further comprising:
and if the token does not exist in the database, feeding back prompt information that the token is illegal to the client.
4. The method according to claim 1, wherein before the receiving the service invocation request sent by the client and obtaining the token carried by the service invocation request, the method further comprises:
receiving an authentication request sent by a client, and acquiring an account identifier and an account password carried by the authentication request;
when the account identification exists in the database and is matched with the account password, generating a token and sending the token to the client;
the receiving a service invocation request sent by a client and acquiring a token carried by the service invocation request comprises the following steps:
and receiving a service calling request sent by the client when the token is received, and acquiring the token carried by the service calling request.
5. The method of claim 4, wherein sending the token to the client comprises:
and encrypting the token and sending the encrypted token to the client.
6. A token validation apparatus, the apparatus comprising:
the token acquisition module is used for receiving a service calling request sent by a client and acquiring a token carried by the service calling request;
the time stamp obtaining module is used for reading a token in the token to generate a time stamp and obtaining a current time stamp;
a token searching module, configured to search, when a time difference between the token generation timestamp and the current timestamp is less than or equal to a valid duration, whether the token exists in a database;
and the request execution module is used for executing the service calling request and feeding back a request result to the client if the token exists in the database.
7. The apparatus of claim 6, further comprising:
and the expiration information sending module is used for feeding back prompt information of token expiration to the client when the time difference between the token generation timestamp and the current timestamp is greater than the effective time length.
8. The apparatus of claim 6, further comprising:
and the illegal information sending module is used for feeding back prompt information that the token is illegal to the client if the token does not exist in the database.
9. A computer storage medium, characterized in that it stores a plurality of instructions adapted to be loaded by a processor and to perform the method steps according to any of claims 1 to 5.
10. A server, comprising: a processor and a memory; wherein the memory stores a computer program adapted to be loaded by the processor and to perform the method steps of any of claims 1 to 5.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201911290205.7ACN111030812A (en) | 2019-12-16 | 2019-12-16 | Token verification method, device, storage medium and server |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201911290205.7ACN111030812A (en) | 2019-12-16 | 2019-12-16 | Token verification method, device, storage medium and server |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN111030812Atrue CN111030812A (en) | 2020-04-17 |
Family
ID=70209104
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201911290205.7APendingCN111030812A (en) | 2019-12-16 | 2019-12-16 | Token verification method, device, storage medium and server |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111030812A (en) |
Cited By (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111431726A (en)* | 2020-06-11 | 2020-07-17 | 深圳市友杰智新科技有限公司 | Algorithm authorization method, device, computer equipment and storage medium |
| CN112235277A (en)* | 2020-10-09 | 2021-01-15 | 北京达佳互联信息技术有限公司 | Resource request method, resource response method and related equipment |
| CN112261008A (en)* | 2020-09-27 | 2021-01-22 | 苏州浪潮智能科技有限公司 | A temporary token-based authentication method, client, and server |
| CN112416964A (en)* | 2020-11-17 | 2021-02-26 | 深圳依时货拉拉科技有限公司 | Data processing method, device and system, computer equipment and computer readable storage medium |
| CN112437071A (en)* | 2020-11-17 | 2021-03-02 | 珠海格力电器股份有限公司 | Method, system, device and storage medium for device control |
| CN112437046A (en)* | 2020-11-05 | 2021-03-02 | 中国人寿保险股份有限公司 | Communication method, system, electronic device and storage medium for preventing replay attack |
| CN112491996A (en)* | 2020-11-18 | 2021-03-12 | 深圳前海微众银行股份有限公司 | Method and device for generating service request |
| CN113765819A (en)* | 2020-09-01 | 2021-12-07 | 北京沃东天骏信息技术有限公司 | Resource access method, device, electronic equipment and storage medium |
| CN113872974A (en)* | 2021-09-29 | 2021-12-31 | 深圳市微购科技有限公司 | Method, server and computer-readable storage medium for network session encryption |
| CN113946811A (en)* | 2021-10-20 | 2022-01-18 | 工银科技有限公司 | Authentication method and device |
| CN114064735A (en)* | 2021-11-30 | 2022-02-18 | 深圳市优必选科技股份有限公司 | Request processing method and device, computer equipment and computer readable storage medium |
| CN114143027A (en)* | 2021-10-27 | 2022-03-04 | 北京达佳互联信息技术有限公司 | Verification method and device for verification code token, electronic equipment and storage medium |
| CN114938352A (en)* | 2022-05-19 | 2022-08-23 | 中国银行股份有限公司 | Picture uploading method, server, client and system |
| CN118540169A (en)* | 2024-07-26 | 2024-08-23 | 成都云祺科技有限公司 | API safety realizing method, system, medium and API framework realizing method |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP2512091A1 (en)* | 2011-04-11 | 2012-10-17 | Research In Motion Limited | Mitigation of application-level distributed denial-of-service attacks |
| CN104821937A (en)* | 2015-03-26 | 2015-08-05 | 腾讯科技（北京）有限公司 | Token acquisition method, device and system |
| CN106302346A (en)* | 2015-05-27 | 2017-01-04 | 阿里巴巴集团控股有限公司 | The safety certifying method of API Calls, device, system |
| CN108183907A (en)* | 2017-12-29 | 2018-06-19 | 浪潮通用软件有限公司 | A kind of authentication method, server and Verification System |
| CN109309683A (en)* | 2018-10-30 | 2019-02-05 | 泰华智慧产业集团股份有限公司 | The method and system of client identity verifying based on token |
| CN109639730A (en)* | 2019-01-21 | 2019-04-16 | 北京工业大学 | Information system data interface authentication method under HTTP stateless protocol based on token |
- 2019
- 2019-12-16CNCN201911290205.7Apatent/CN111030812A/enactivePending
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP2512091A1 (en)* | 2011-04-11 | 2012-10-17 | Research In Motion Limited | Mitigation of application-level distributed denial-of-service attacks |
| CN104821937A (en)* | 2015-03-26 | 2015-08-05 | 腾讯科技（北京）有限公司 | Token acquisition method, device and system |
| CN106302346A (en)* | 2015-05-27 | 2017-01-04 | 阿里巴巴集团控股有限公司 | The safety certifying method of API Calls, device, system |
| CN108183907A (en)* | 2017-12-29 | 2018-06-19 | 浪潮通用软件有限公司 | A kind of authentication method, server and Verification System |
| CN109309683A (en)* | 2018-10-30 | 2019-02-05 | 泰华智慧产业集团股份有限公司 | The method and system of client identity verifying based on token |
| CN109639730A (en)* | 2019-01-21 | 2019-04-16 | 北京工业大学 | Information system data interface authentication method under HTTP stateless protocol based on token |
Cited By (19)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111431726B (en)* | 2020-06-11 | 2020-09-18 | 深圳市友杰智新科技有限公司 | Algorithm authorization method, device, computer equipment and storage medium |
| CN111431726A (en)* | 2020-06-11 | 2020-07-17 | 深圳市友杰智新科技有限公司 | Algorithm authorization method, device, computer equipment and storage medium |
| CN113765819A (en)* | 2020-09-01 | 2021-12-07 | 北京沃东天骏信息技术有限公司 | Resource access method, device, electronic equipment and storage medium |
| CN113765819B (en)* | 2020-09-01 | 2024-12-10 | 北京沃东天骏信息技术有限公司 | Resource access method, device, electronic device and storage medium |
| CN112261008A (en)* | 2020-09-27 | 2021-01-22 | 苏州浪潮智能科技有限公司 | A temporary token-based authentication method, client, and server |
| CN112235277A (en)* | 2020-10-09 | 2021-01-15 | 北京达佳互联信息技术有限公司 | Resource request method, resource response method and related equipment |
| CN112437046A (en)* | 2020-11-05 | 2021-03-02 | 中国人寿保险股份有限公司 | Communication method, system, electronic device and storage medium for preventing replay attack |
| CN112437046B (en)* | 2020-11-05 | 2023-04-28 | 中国人寿保险股份有限公司 | Communication method, system, electronic device and storage medium for preventing replay attack |
| CN112416964A (en)* | 2020-11-17 | 2021-02-26 | 深圳依时货拉拉科技有限公司 | Data processing method, device and system, computer equipment and computer readable storage medium |
| CN112437071B (en)* | 2020-11-17 | 2023-05-16 | 珠海格力电器股份有限公司 | Method, system, device and storage medium for controlling device |
| CN112437071A (en)* | 2020-11-17 | 2021-03-02 | 珠海格力电器股份有限公司 | Method, system, device and storage medium for device control |
| CN112491996B (en)* | 2020-11-18 | 2022-08-12 | 深圳前海微众银行股份有限公司 | A method and apparatus for generating a service request |
| CN112491996A (en)* | 2020-11-18 | 2021-03-12 | 深圳前海微众银行股份有限公司 | Method and device for generating service request |
| CN113872974A (en)* | 2021-09-29 | 2021-12-31 | 深圳市微购科技有限公司 | Method, server and computer-readable storage medium for network session encryption |
| CN113946811A (en)* | 2021-10-20 | 2022-01-18 | 工银科技有限公司 | Authentication method and device |
| CN114143027A (en)* | 2021-10-27 | 2022-03-04 | 北京达佳互联信息技术有限公司 | Verification method and device for verification code token, electronic equipment and storage medium |
| CN114064735A (en)* | 2021-11-30 | 2022-02-18 | 深圳市优必选科技股份有限公司 | Request processing method and device, computer equipment and computer readable storage medium |
| CN114938352A (en)* | 2022-05-19 | 2022-08-23 | 中国银行股份有限公司 | Picture uploading method, server, client and system |
| CN118540169A (en)* | 2024-07-26 | 2024-08-23 | 成都云祺科技有限公司 | API safety realizing method, system, medium and API framework realizing method |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111030812A (en) | Token verification method, device, storage medium and server | |
| US11610019B2 (en) | Information management method, apparatus, and information management system | |
| CN111556006B (en) | Third-party application system login method, device, terminal and SSO service platform | |
| US12250209B2 (en) | Network identity protection method and device, and electronic equipment and storage medium | |
| JP6574168B2 (en) | Terminal identification method, and method, system, and apparatus for registering machine identification code | |
| CN103618717B (en) | The dynamic confirming method of more account client informations, device and system | |
| CN105991614B (en) | It is a kind of it is open authorization, resource access method and device, server | |
| US9009793B2 (en) | Dynamic pin dual factor authentication using mobile device | |
| US10630574B2 (en) | Link processing method, apparatus, and system | |
| CN102217280B (en) | User service authentication method, system and server | |
| CN110417730B (en) | Unified access method of multiple application programs and related equipment | |
| US20140053251A1 (en) | User account recovery | |
| CN111444551B (en) | Account registration and login method and device, electronic equipment and readable storage medium | |
| CN112688773A (en) | Token generation and verification method and device | |
| CN111431920A (en) | Security control method and system based on dynamic token | |
| CN104954330A (en) | Method of accessing data resources, device and system | |
| TW202312054A (en) | Card binding method, user terminal, server, card binding system and storage medium | |
| CN106254319B (en) | Light application login control method and device | |
| CN109936579A (en) | Single sign-on method, device, equipment and computer readable storage medium | |
| CN105701423A (en) | Data storage method and device applied to cloud payment transactions | |
| CN106331003A (en) | A method and device for accessing an application portal system on a cloud desktop | |
| CN118214586A (en) | Identity authentication method, system, equipment and storage medium | |
| CN112231674A (en) | A kind of URL address jump verification method, system and electronic device | |
| CN109829321B (en) | Method, device, equipment and storage medium for authenticating identity | |
| CN104917755B (en) | A kind of login method based on mobile communication terminal and short message |
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 | ||
| RJ01 | Rejection of invention patent application after publication | ||
| RJ01 | Rejection of invention patent application after publication | Application publication date:20200417 |