CN111030812A

CN111030812A - Token verification method, device, storage medium and server

Info

Publication number: CN111030812A
Application number: CN201911290205.7A
Authority: CN
Inventors: 龚敏
Original assignee: Guangdong Oppo Mobile Telecommunications Corp Ltd
Current assignee: Guangdong Oppo Mobile Telecommunications Corp Ltd
Priority date: 2019-12-16
Filing date: 2019-12-16
Publication date: 2020-04-17

Abstract

The embodiment of the application discloses a token verification method, a token verification device, a storage medium and a server, wherein the method comprises the following steps: 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. Therefore, by adopting the embodiment of the application, the frequency of legally verifying the token by inquiring the database can be reduced, and the risk of service denial of the server is reduced.

Description

Token verification method, device, storage medium and server

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.

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;

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;

S208, if the token exists in the database, executing the service calling request and feeding back a request result to the client;

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.

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 obtaining module 10, a timestamp obtaining module 20, a token lookup module 30, and a request execution module 40.

The token obtaining module 10 is configured to receive a service invocation request sent by a client, and obtain a token carried by the service invocation request;

a timestamp obtaining module 20, configured to read a token in the token to generate a timestamp, and obtain a current timestamp;

a token 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 the request 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 expiration information 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 illegal information 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 account information 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 a token 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 obtaining module 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 obtaining module 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.

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, the server 1000 may include: at least one processor 1001, at least one network interface 1004, a user interface 1003, memory 1005, at least one communication bus 1002.

Wherein a communication bus 1002 is used to enable connective communication between these components.

The user interface 1003 may include a Display screen (Display) and a Camera (Camera), and the optional user interface 1003 may also include a standard wired interface and a wireless interface.

The network interface 1004 may optionally include a standard wired interface, a wireless interface (e.g., WI-FI interface), among others.

Processor 1001 may include one or more processing cores, among other things. The processor 1001 connects various parts throughout the server 1000 using various interfaces and lines, and performs various functions of the server 1000 and processes data by executing or executing instructions, programs, code sets, or instruction sets stored in the memory 1005, and calling data stored in the memory 1005. Alternatively, the processor 1001 may be implemented in at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), and Programmable Logic Array (PLA). The processor 1001 may integrate one or more of a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), a modem, and the like. Wherein, the CPU mainly processes an operating system, a user interface, an application program and the like; the GPU is used for rendering and drawing the content required to be displayed by the display screen; the modem is used to handle wireless communications. It is understood that the modem may not be integrated into the processor 1001, but may be implemented by a single chip.

The Memory 1005 may include a Random Access Memory (RAM) or a Read-Only Memory (Read-Only Memory). Optionally, the memory 1005 includes a non-transitory computer-readable medium. The memory 1005 may be used to store an instruction, a program, code, a set of codes, or a set of instructions. The memory 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. The memory 1005 may optionally be at least one memory device located remotely from the processor 1001. As shown in fig. 5, a memory 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 the server 1000 shown in fig. 5, the user interface 1003 is mainly used as an interface for providing input for a user, and acquiring data input by the user; and the processor 1001 may be configured to invoke a token validation application stored in the memory 1005 and specifically perform the following operations:

In one embodiment, the processor 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.

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, the processor 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, the processor 1001 specifically executes the following operations:

In one embodiment, when the processor 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.

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

1. A method of token validation, the method comprising:

2. The method of claim 1, further comprising:

3. The method of claim 1, further comprising:

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:

the receiving a service invocation request sent by a client and acquiring a token carried by the service invocation request comprises the following steps:

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:

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.