WO2021047012A1 - 基于token令牌的身份校验方法及相关设备 - Google Patents

基于token令牌的身份校验方法及相关设备 Download PDF

Info

Publication number
WO2021047012A1
WO2021047012A1 PCT/CN2019/117322 CN2019117322W WO2021047012A1 WO 2021047012 A1 WO2021047012 A1 WO 2021047012A1 CN 2019117322 W CN2019117322 W CN 2019117322W WO 2021047012 A1 WO2021047012 A1 WO 2021047012A1
Authority
WO
WIPO (PCT)
Prior art keywords
token
task request
client
http task
user
Prior art date
Application number
PCT/CN2019/117322
Other languages
English (en)
French (fr)
Inventor
杨小彦
Original Assignee
平安普惠企业管理有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 平安普惠企业管理有限公司 filed Critical 平安普惠企业管理有限公司
Publication of WO2021047012A1 publication Critical patent/WO2021047012A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0869—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving random numbers or seeds
    • 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
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/121—Timestamp
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]

Definitions

  • This application relates to the field of information security, and in particular to an identity verification method and related equipment based on TOKEN tokens.
  • TOKEN token is used to verify the identity of the requester.
  • the TOKEN token generally specifies how long it will expire. After the expiration, the TOKEN will become invalid, but before the TOKEN becomes invalid, it is easy to be intercepted by the attacker, and then the user will be forged to request the backend, which will cause the forged request attack and lead to the potential risk of the system.
  • the purpose of this application is to address the deficiencies of the prior art, and provide a TOKEN token-based identity verification method and related equipment.
  • the TOKEN token is generated on the client and sent to the server, and the TOKEN is verified on the server. It can effectively improve the security of identity verification.
  • the technical solution of the present application provides an identity verification method and related equipment based on TOKEN tokens.
  • This application discloses an identity verification method based on TOKEN, which includes the following steps:
  • the server After receiving the HTTP task request, the server verifies the user identity corresponding to the HTTP task request, and sends feedback information to the client according to the verification result;
  • the client After the client receives the feedback information from the server, it updates the data corresponding to this HTTP task request according to the feedback information.
  • the application also discloses an identity verification device based on TOKEN, the device includes:
  • Information acquisition module set to detect the login status of the user at the client, and obtain the user's identity information when it is detected that the user successfully logs in at the client;
  • Request sending module set to generate a random number on the client when the user is about to initiate an HTTP task request, and obtain the time stamp of the client, and generate the current on the client according to the user’s identity information, random number and time stamp. And send an HTTP task request to the server according to the current TOKEN token;
  • Verification module when the server receives the HTTP task request, it verifies the user identity corresponding to the HTTP task request, and sends feedback information to the client according to the verification result;
  • Update module After the client receives the feedback information from the server, it updates the data corresponding to the HTTP task request according to the feedback information.
  • the application also discloses a computer device, the computer device includes a memory and a processor, the memory is stored with computer readable instructions, when the computer readable instructions are executed by one or more of the processors, One or more of the processors perform the following steps:
  • the server After receiving the HTTP task request, the server verifies the user identity corresponding to the HTTP task request, and sends feedback information to the client according to the verification result;
  • the client After the client receives the feedback information from the server, it updates the data corresponding to this HTTP task request according to the feedback information.
  • the application also discloses a computer-readable storage medium.
  • the storage medium may be volatile or non-volatile.
  • the storage medium can be read and written by the processor, and the storage medium stores computer instructions.
  • the computer-readable instructions are executed by one or more processors, the one or more processors execute the following steps:
  • the server After receiving the HTTP task request, the server verifies the user identity corresponding to the HTTP task request, and sends feedback information to the client according to the verification result;
  • the client After the client receives the feedback information from the server, it updates the data corresponding to this HTTP task request according to the feedback information.
  • This application generates a TOKEN token consisting of user identity information, time stamp and random number on the client side, and verifies this token on the server side, due to the random number in the token It is randomly generated and encrypted, and the random number is combined with user information and time stamp to generate a token through a hash algorithm, which ensures the security of the task request and avoids the risk of tampering caused by the distribution of TOKEN by the server.
  • FIG. 1 is a schematic flowchart of a method for identity verification based on TOKEN in the first embodiment of this application;
  • FIG. 2 is a schematic flowchart of a method for identity verification based on TOKEN tokens according to the second embodiment of the application;
  • FIG. 3 is a schematic flowchart of a method for identity verification based on TOKEN in the third embodiment of this application;
  • FIG. 4 is a schematic flowchart of a method for identity verification based on TOKEN tokens according to a fourth embodiment of this application;
  • FIG. 5 is a schematic flowchart of a TOKEN-based identity verification method according to a fifth embodiment of this application.
  • Fig. 6 is a schematic flowchart of a method for identity verification based on TOKEN according to the sixth embodiment of the application;
  • FIG. 7 is a schematic flowchart of a method for identity verification based on TOKEN tokens according to the seventh embodiment of the application.
  • Fig. 8 is a schematic structural diagram of an identity verification device based on TOKEN according to an embodiment of the application.
  • step s101 the login status of the user is detected at the client, and when it is detected that the user successfully logs in at the client, the identity information of the user is obtained;
  • the user’s information includes the user’s account name and password.
  • the client After the client passes the verification of the user’s account name and password, the user will The client can successfully log in, and the client can also obtain the identity information of the currently logged-in user, and the user's identity information is the user's account.
  • Step s102 when the user is ready to initiate an HTTP task request, a random number is generated on the client, and the time stamp of the client is obtained, and the current TOKEN command is generated on the client according to the user's identity information, the random number and the time stamp And send an HTTP task request to the server according to the current TOKEN token;
  • a corresponding HTTP task request data packet will be generated on the client.
  • the HTTP task request data packet contains the user’s identity information and task information, and then will The HTTP task request data packet is sent to the server, so that after the server receives the HTTP task request data packet, the HTTP task request data packet is parsed to obtain the user in the HTTP task request data packet.
  • the identity information and task information are verified according to the user identity information, and the corresponding task is executed according to the task information after the verification is passed.
  • a random number with a fixed number of digits or any number of digits can be generated on the client, and the current time stamp of the client can be obtained, and then based on the random number, time stamp, and The user's identity information generates a TOKEN token, and puts the TOKEN token into the HTTTP task request data packet.
  • Step s103 After receiving the HTTP task request, the server verifies the user identity corresponding to the HTTP task request, and sends feedback information to the client according to the verification result;
  • the server can parse the HTTP task request, obtain the user identity information in the HTTP task request, and verify the user identity information. If the verification is passed, the corresponding data is sent to the client according to the tasks in the HTTP task request, otherwise, a rejection request message can be sent to the client.
  • Step s104 After the client receives the feedback information from the server, it updates the data corresponding to this HTTP task request according to the feedback information.
  • the client after the client receives the feedback information from the server, it can update the client data according to the feedback information; the feedback information includes a successful feedback message and a failed feedback message. If the client receives the feedback information, Identify the rejection of the server due to timeout, the client can regenerate a TOKEN, the TOKEN contains the current time stamp, user information and random number; if the TOKEN check fails and the server rejects, the client can end this HTTP HTTP session Task request: If a success message is received, the client can end this HTTP task request, and update the client data according to the feedback data of the server.
  • a TOKEN token consisting of user identity information, time stamp and random number is generated on the client side, and the token is verified on the server side, because the random number in the token is randomly generated and After encryption, the random number, user information and time stamp are used to generate a token through the hash algorithm, which ensures the security of the task request and avoids the risk of tampering caused by the TOKEN distribution by the server.
  • Figure 2 is a schematic flow chart of a method for identity verification based on TOKEN tokens according to the second embodiment of the application. As shown in the figure, in step s102, when the user is ready to initiate an HTTP task request, it is generated on the client side.
  • a random number including:
  • a random number with the same number of digits as the user’s identity information can be generated on the client side. Since the user’s identity information has a fixed length, the random number The number is also a fixed length, and the digits of the random number are consistent with the digits of the user's identity information.
  • generating the current TOKEN token on the client according to the user's identity information, random number, and time stamp includes:
  • Step s201 splicing the user's identity information, random numbers, and time stamps in any order to generate a first character string, and adding a time stamp position identifier to the head of the first character string to generate a second character string;
  • the user's identity information, random number, and time stamp can be spliced to generate the first character string in any order.
  • the sequence can be ABC , CBA, ACB, CAB, BCA, BAC
  • a time stamp position identifier is added to the head of the first character string to identify that the time stamp is at all
  • the time stamp position identifier may be identified by a 2-digit number, for example, 00 indicates that the time stamp is at the head of the first character string, and 01 indicates that the time stamp is at the first character string.
  • 10 indicates that the time stamp is at the end of the first character string, and then generates a second character string, so that when the server receives the second character string, it reads the 2 digits in the head , The location of the time stamp can be obtained, and the specific content of the time stamp can be obtained after parsing.
  • step s202 a TOKEN token is generated on the client through the HASH algorithm of the second character string.
  • the second character string can be used to generate a TOKEN token on the client through the HASH algorithm.
  • the HASH algorithm is a HASH function, that is, an input of any length is transformed by a hash algorithm
  • the output is a fixed-length output, which is the hash value.
  • the TOKEN token can be parsed by the HASH algorithm on the server to obtain a string.
  • Figure 3 is a schematic flow chart of a method for identity verification based on TOKEN tokens according to the third embodiment of the application. As shown in the figure, in step s102, when the user is ready to initiate an HTTP task request, it is generated on the client side.
  • a random number including:
  • the arbitrary number of digits includes a positive integer of any digit.
  • generating the current TOKEN token on the client according to the user's identity information, random number, and time stamp includes:
  • Step s301 concatenating the user's identity information, random number, and time stamp to generate a character string, and placing the time stamp at the head or tail of the character string;
  • the user’s identity information, random number, and time stamp can be spliced together to generate a character string.
  • the timestamp can be placed at the head or tail of the character string and agreed with the server
  • the number and position of the timestamp for example, the timestamp can be 14 digits, which are respectively year, month, day, hour, minute and second, such as 20190424000000, and then random numbers and user information can be spliced in different orders to generate a string of strings. x, so that the server can read the corresponding timestamp through the character string x after receiving the character string x.
  • the order can be ABC, Any one of CBA, ACB, BCA, and the position and number of time stamps are agreed in advance between the client and the server. Once agreed, they will not be changed during the communication process.
  • Step s302 Generate a TOKEN token on the client through the HASH algorithm.
  • the character string can be used to generate a TOKEN token on the client through the HASH algorithm.
  • the HASH algorithm is a HASH function, which is to transform an input of any length into a hash algorithm.
  • the fixed-length output is the hash value.
  • the TOKEN token can be parsed by the HASH algorithm on the server to obtain the string.
  • a random number of any digit can be generated, and the random number is one of the components of the TOKEN, so it can improve The security of TOKEN verification.
  • FIG. 4 is a schematic flow chart of a method for identity verification based on TOKEN tokens according to the fourth embodiment of the application. As shown in the figure, in step s102, an HTTP task request is sent to the server according to the current TOKEN token. ,include:
  • Step s401 encrypt the character string
  • the character string can be backed up, one is used to generate a TOKEN token according to the HASH algorithm, and the other can be used to encrypt, and the encryption may be encrypted by a symmetric encryption algorithm
  • the encrypted secret key can be agreed in advance between the client and the server, and the secret key can be periodically updated between the client and the server, for example, a preset update time period, such as one week, one month, etc., when it expires
  • the client or server initiates a secret key update request, and updates the secret keys of both parties according to the secret key update request.
  • the secret key will not change; it can also be through an asymmetric encryption algorithm.
  • the client and the server each maintain a pair of public and private keys, that is, a public key and a private key are maintained on the client, and a public key and a private key are maintained on the server.
  • the public key is used to pair The string is encrypted, and the private key is used to decrypt the string, that is, if the string is encrypted with the public key on the client, the string is decrypted with the private key on the server.
  • Step s402 putting the encrypted character string into the header of the HTTP task request, and putting the TOKEN token into the body of the HTTP task request;
  • the HTTP task request is sent in the form of an HTTP task request data packet.
  • the HTTP task request data packet includes a header and a packet body. After the encrypted character string is generated, the encrypted character The string is put into the header of the HTTP task request data packet. After the TOKEN token is generated, the TOKEN token can be put into the body of the HTTP task request data packet.
  • Step s403 Send the HTTP task request to the server.
  • the HTTP task request data packet can be sent to the server.
  • FIG. 5 is a schematic flow chart of a method for identity verification based on TOKEN tokens according to the fifth embodiment of the application. As shown in the figure, in step s103, before verifying the user identity corresponding to the HTTP task request, include:
  • Step s501 preset a valid time period
  • the valid period of time can be preset on the server to ensure the validity of the TOKEN and avoid the security risk caused by the client not reaching the server for a long time after initiating the HTTP task request.
  • the valid period of time may be a period of time. Time, such as 5 seconds or 10 seconds.
  • Step s502 parse the header of the HTTP task request to obtain the character string in the HTTP task request, decrypt the character string, and obtain the time stamp in the character string;
  • the header in the HTTP task request data packet can be parsed to obtain the character string in the HTTP task request, and then the character string can be decrypted.
  • the decryption method of the server needs to be consistent with the encryption method of the client, that is, if the client is symmetrically encrypted, the server should decrypt symmetrically, and then obtain the time stamp in the string, because the time stamp is placed in the The header of the character string and the number of digits are pre-arranged between the client and the server. Therefore, the time stamp can be obtained as long as the initial digits of the character string are read according to the agreement.
  • Step s503 Obtain the current system time of the server, and compare the time difference between the current system time and the time stamp with the effective time period. If the current system time is different from the time stamp If the time difference is within the valid time period, the user identity is verified, otherwise, a timeout rejection feedback message is sent to the client.
  • the current system time of the server can be obtained, and then the time difference is obtained according to the client time stamp and the current system time of the server, and the time difference is compared with the preset time. If the time difference between the current system time and the time stamp is within the valid time period, the user identity is verified, otherwise, a timeout rejection feedback message is sent to the client. For example, if the preset valid time period is 30 seconds, the received time stamp is 11:25:11, the current time of the server system is 11:26:11, and the time difference is 60 seconds. The time difference is much larger than the said time. The effective time period is preset, so the server can reject this task request.
  • the validity period of the HTTP task request is obtained by parsing the time stamp in the HTTP task request on the server side, and the validity of the request is determined according to the validity period, which can improve the security of identity verification Sex.
  • Fig. 6 is a schematic flow chart of a method for identity verification based on TOKEN according to the sixth embodiment of the application.
  • step s103 the user identity corresponding to the HTTP task request is verified, and Send feedback information to the client according to the verification result, including:
  • Step s601 parse the packet body of the HTTP task request to obtain the TOKEN token in the HTTP task request;
  • the packet body in the HTTP task request data packet can be parsed to obtain the TOKEN token in the HTTP task request.
  • Step s602 generating a verification TOKEN token through the HASH algorithm according to the decrypted character string
  • a verification TOKEN token can be generated on the server side according to the HASH algorithm.
  • the verification TOKEN token is used to compare with the TOKEN in the HTTP task request to complete identity verification. Since the string x is encrypted, the TOKEN token generated on the server can be used as a comparison sample.
  • the TOKEN in the HTTP task request can be easily stolen and can be used for identity verification. If it is consistent, it means this task.
  • the request is passed, so that the server does not need to generate a TOKEN and send it to the client, reducing the load on the server.
  • step s603 the verification TOKEN token is compared with the TOKEN token in the HTTP task request. If they are consistent, the verification is passed, and the verification success feedback information and this HTTP task request are sent to the client. Corresponding data, otherwise send the verification failure rejection feedback message to the client.
  • the verification TOKEN token can be compared with the TOKEN token in the HTTP task request, and if they are consistent, the verification is passed, and the verification success feedback information and the current HTTP task are sent to the client. Request the corresponding data, otherwise send the verification failure rejection feedback message to the client.
  • Fig. 7 is a schematic flow chart of a method for identity verification based on TOKEN tokens according to the seventh embodiment of the application.
  • step s104 after the client receives the feedback information from the server, it is based on the feedback Information to update client data, including:
  • step s701 when the client receives the timeout rejection feedback information, it generates a new random number on the client and obtains a new time stamp, and generates a new random number based on the new random number, the new time stamp and the user’s identity information.
  • TOKEN token and re-initiate an HTTP task request to the server according to the new TOKEN token;
  • the client when it receives the timeout rejection feedback message, it can generate a new random number on the client and obtain a new time stamp.
  • the new random number can also be arbitrary, that is, a new random number. It can have different digits and numbers from the old random number; then generate a new TOKEN token according to the new random number, the new time stamp and the user’s identity information, and send it to the server according to the new TOKEN token Initiate the HTTP task request again.
  • Step s702 when the client receives the feedback message that the verification fails and rejects, it ends this HTTP task request;
  • the client when the client receives the feedback message of rejection of verification failure, it can directly end this HTTP task request without initiating a new HTTP task request.
  • step s703 when the client receives the feedback information of successful verification, it ends this HTTP task request, and updates according to the data corresponding to the HTTP task request sent by the server.
  • the client when the client receives the feedback information of successful verification, it can end this HTTP task request, and update according to the data corresponding to the HTTP task request sent by the server, for example, the client sends the server to the server. Initiate a request to read the user's historical order.
  • the server receives the request and starts to verify the user's identity. After the verification is successful, the user's historical order data is queried and returned to the client.
  • the client receives the request. Update the client data after the historical order data.
  • the request can be re-initiated when the timeout expires, avoiding unnecessary communication interruption, and ending the request when the verification fails, avoiding excessive requests to increase the system Burden, and update local data when successful, and improve the operating efficiency of the system.
  • FIG. 8 The structure of an identity verification device based on TOKEN in an embodiment of the present application is shown in FIG. 8, and includes:
  • the client send
  • the embodiment of the present application also discloses a computer device, the computer device includes a memory and a processor, and computer-readable instructions are stored in the memory.
  • the computer-readable instructions are executed by one or more of the processors , Enabling one or more of the processors to execute the steps in the identity verification methods in the foregoing embodiments.
  • the embodiment of the present application also discloses a computer-readable storage medium, the storage medium can be read and written by a processor, the memory stores computer-readable instructions, and the computer-readable instructions are executed by one or more processors At this time, one or more processors are caused to execute the steps in the identity verification method described in the foregoing embodiments.
  • the computer-readable storage medium may be volatile or non-volatile, which is not specifically limited here.
  • the computer program can be stored in a computer readable storage medium, and the program can be stored in a computer readable storage medium. When executed, it may include the procedures of the above-mentioned method embodiments.
  • the aforementioned storage medium may be a non-volatile storage medium such as a magnetic disk, an optical disc, a read-only memory (Read-Only Memory, ROM), or a random access memory (Random Access Memory, RAM), etc.

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)
  • Storage Device Security (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

本申请涉及信息安全领域，本申请公开了一种基于TOKEN令牌的身份校验方法及相关设备，所述方法包括：在客户端对用户的登录状态进行检测，获取所述用户的身份信息；在客户端生成一个随机数，并获取客户端的时戳，根据所述用户的身份信息、随机数以及时戳在客户端生成当前的TOKEN令牌，并根据所述当前的TOKEN令牌向服务端发送HTTP任务请求；当服务端收到所述HTTP任务请求后，对所述HTTP任务请求对应的用户身份进行校验，并根据校验结果向客户端发送反馈信息。本申请通过在客户端生成TOKEN令牌，发送给服务端，并在服务器端进行TOKEN的校验，可有效提高身份校验的安全性。

Description

基于TOKEN令牌的身份校验方法及相关设备
本申请要求于2019年09月09日提交中国专利局、申请号为201910849275.5、发明名称为“基于TOKEN令牌的身份校验方法及相关设备”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及信息安全领域，特别涉及一种基于TOKEN令牌的身份校验方法及相关设备。
背景技术
目前，大多数远程访问系统都是前后端分离，前后端分离的项目有个最难解决的问题就是怎么去做调用鉴权，即怎么才能知道这一次请求是合法的。现在一般的做法就是用户在前端登录成功之后，后端会给前端分配一个TOKEN令牌，所述TOKEN令牌用于对请求者的身份进行校验，其中TOKEN令牌一般会规定多长时间过期，过期之后所述TOKEN就会失效，但是在所述TOKEN失效之前容易被攻击者截获，然后伪造成用户去后端请求，由此造成伪造请求攻击，导致系统潜在的风险。
发明内容
本申请的目的在于针对现有技术的不足，提供一种基于TOKEN令牌的身份校验方法及相关设备，通过在客户端生成TOKEN令牌，发送给服务端，并在服务器端进行TOKEN的校验，可有效提高身份校验的安全性。
为达到上述目的，本申请的技术方案提供一种基于TOKEN令牌的身份校验方法及相关设备。
本申请公开了一种基于TOKEN令牌的身份校验方法，包括以下步骤：
在客户端对用户的登录状态进行检测，当检测到用户在客户端成功登录时，获取所述用户的身份信息；
当所述用户准备发起HTTP任务请求时，在客户端生成一个随机数，并获取客户端的时戳，根据所述用户的身份信息、随机数以及时戳在客户端生成当前的TOKEN令牌，并根据所述当前的TOKEN令牌向服务端发送HTTP任务请求；
当服务端收到所述HTTP任务请求后，对所述HTTP任务请求对应的用户身 份进行校验，并根据校验结果向客户端发送反馈信息；
当客户端收到服务端的反馈信息后，根据所述反馈信息对本次HTTP任务请求对应的数据进行更新。
本申请还公开了一种基于TOKEN令牌的身份校验装置，所述装置包括：
信息获取模块：设置为在客户端对用户的登录状态进行检测，当检测到用户在客户端成功登录时，获取所述用户的身份信息；
请求发送模块：设置为当所述用户准备发起HTTP任务请求时，在客户端生成一个随机数，并获取客户端的时戳，根据所述用户的身份信息、随机数以及时戳在客户端生成当前的TOKEN令牌，并根据所述当前的TOKEN令牌向服务端发送HTTP任务请求；
校验模块：设置为当服务端收到所述HTTP任务请求后，对所述HTTP任务请求对应的用户身份进行校验，并根据校验结果向客户端发送反馈信息；
更新模块：设置为当客户端收到服务端的反馈信息后，根据所述反馈信息对本次HTTP任务请求对应的数据进行更新。
本申请还公开了一种计算机设备，所述计算机设备包括存储器和处理器，所述存储器中存储有计算机可读指令，所述计算机可读指令被一个或多个所述处理器执行时，使得一个或多个所述处理器执行以下步骤：
在客户端对用户的登录状态进行检测，当检测到用户在客户端成功登录时，获取所述用户的身份信息；
当所述用户准备发起HTTP任务请求时，在客户端生成一个随机数，并获取客户端的时戳，根据所述用户的身份信息、随机数以及时戳在客户端生成当前的TOKEN令牌，并根据所述当前的TOKEN令牌向服务端发送HTTP任务请求；
当服务端收到所述HTTP任务请求后，对所述HTTP任务请求对应的用户身份进行校验，并根据校验结果向客户端发送反馈信息；
当客户端收到服务端的反馈信息后，根据所述反馈信息对本次HTTP任务请求对应的数据进行更新。
本申请还公开了一种计算机可读存储介质，该存储介质可以为易失性的，也可以是非易失性的，所述存储介质可被处理器读写，所述存储介质存储有计 算机指令，所述计算机可读指令被一个或多个处理器执行时，使得一个或多个处理器执行以下步骤：
在客户端对用户的登录状态进行检测，当检测到用户在客户端成功登录时，获取所述用户的身份信息；
当所述用户准备发起HTTP任务请求时，在客户端生成一个随机数，并获取客户端的时戳，根据所述用户的身份信息、随机数以及时戳在客户端生成当前的TOKEN令牌，并根据所述当前的TOKEN令牌向服务端发送HTTP任务请求；
当服务端收到所述HTTP任务请求后，对所述HTTP任务请求对应的用户身份进行校验，并根据校验结果向客户端发送反馈信息；
当客户端收到服务端的反馈信息后，根据所述反馈信息对本次HTTP任务请求对应的数据进行更新。
本申请的有益效果是：本申请通过在客户端生成由用户身份信息、时戳及随机数组成的TOKEN令牌，在服务端对此令牌进行校验，由于所述令牌中的随机数是随机产生且经过加密，并将所述随机数与用户信息和时戳一起经过hash算法生成令牌，保证了任务请求的安全性，避免了由服务端分配TOKEN导致被篡改的危险。
附图说明
图1为本申请第一个实施例的一种基于TOKEN令牌的身份校验方法的流程示意图；
图2为本申请第二个实施例的一种基于TOKEN令牌的身份校验方法的流程示意图；
图3为本申请第三个实施例的一种基于TOKEN令牌的身份校验方法的流程示意图；
图4为本申请第四个实施例的一种基于TOKEN令牌的身份校验方法的流程示意图；
图5为本申请第五个实施例的一种基于TOKEN令牌的身份校验方法的流程示意图；
图6为本申请第六个实施例的一种基于TOKEN令牌的身份校验方法的流程 示意图；
图7为本申请第七个实施例的一种基于TOKEN令牌的身份校验方法的流程示意图；
图8为本申请实施例的一种基于TOKEN令牌的身份校验装置结构示意图。
具体实施方式
为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。
本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本申请的说明书中使用的措辞“包括”是指存在所述特征、整数、步骤、操作、元件和/或组件，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。
本申请第一个实施例的一种基于TOKEN令牌的身份校验方法流程如图1所示，本实施例包括以下步骤：
步骤s101，在客户端对用户的登录状态进行检测，当检测到用户在客户端成功登录时，获取所述用户的身份信息；
具体的，当用户在客户端本地登录时，通常会输入所述用户的信息，所述用户的信息包括用户的账户名和密码，当客户端对所述用户的账户名和密码验证通过后，用户就可以在客户端成功登录，客户端也可以获取到当前登录用户的身份信息，所述用户的身份信息即为用户的账号。
步骤s102，当所述用户准备发起HTTP任务请求时，在客户端生成一个随机数，并获取客户端的时戳，根据所述用户的身份信息、随机数以及时戳在客户端生成当前的TOKEN令牌，并根据所述当前的TOKEN令牌向服务端发送HTTP任务请求；
具体的，当用户准备向服务端发起HTTP任务请求时，会在客户端生成相应的HTTP任务请求数据包，所述HTTP任务请求数据包中包含所述用户的身份信息以及任务信息，然后将所述HTTP任务请求数据包发送给服务端，以便在所述 服务端收到所述HTTP任务请求数据包后，对所述HTTP任务请求数据包进行解析，获取所述HTTP任务请求数据包中的用户身份信息及任务信息，并根据所述用户身份信息进行校验，并在校验通过后根据所述任务信息执行相应的任务。
具体的，在生成所述用户身份信息时，可在所述客户端生成一个固定位数的或者任意位数的随机数，并获取客户端的当前时戳，然后根据所述随机数、时戳以及用户的身份信息生成一个TOKEN令牌，并在所述TOKEN令牌放入所述HTTTP任务请求数据包中。
步骤s103，当服务端收到所述HTTP任务请求后，对所述HTTP任务请求对应的用户身份进行校验，并根据校验结果向客户端发送反馈信息；
具体的，当服务端收到客户端的HTTP任务请求后，可对所述HTTP任务请求进行解析，获取所述HTTP任务请求中的用户身份信息，并对所述用户身份信息进行校验，如果校验通过，则根据所述HTTP任务请求中的任务向客户端发送相应数据，否则可向客户端发送拒绝请求消息。
步骤s104，当客户端收到服务端的反馈信息后，根据所述反馈信息对本次HTTP任务请求对应的数据进行更新。
具体的，当客户端收到服务端的反馈信息后，可根据所述反馈信息进行客户端数据的更新；所述反馈信息包括成功的反馈消息及失败的反馈消息，如果客户端收到反馈信息，标识由于超时导致服务器的拒绝，客户端可以重新生成一个TOKEN，所述TOKEN包含当前的时戳、用户信息及随机数；如果由于TOKEN校验不通过导致服务端的拒绝，客户端可结束本次HTTP任务请求；如果收到成功消息，客户端可结束本次HTTP任务请求，并根据服务端的反馈数据进行客户端数据的更新。
本实施例中，通过在客户端生成由用户身份信息、时戳及随机数组成的TOKEN令牌，在服务端对此令牌进行校验，由于所述令牌中的随机数是随机产生且经过加密，并将所述随机数与用户信息和时戳一起经过hash算法生成令牌，保证了任务请求的安全性，避免了由服务端分配TOKEN导致被篡改的危险。
图2为本申请第二个实施例的一种基于TOKEN令牌的身份校验方法流程示意图，如图所示，所述步骤s102，当所述用户准备发起HTTP任务请求时，在客 户端生成一个随机数，包括：
当所述用户准备发起HTTP任务请求时，在客户端生成一个与所述用户的身份信息相同位数的随机数；
具体的，当所述用户准备发起HTTP任务请求时，可在客户端生成一个与所述用户的身份信息相同位数的随机数，由于所述用户的身份信息是固定长度的，因此所述随机数也是固定长度，且所述随机数的位数和用户的身份信息位数一致。
则所述根据所述用户的身份信息、随机数以及时戳在客户端生成当前的TOKEN令牌，包括：
步骤s201，将所述用户的身份信息、随机数以及时戳拼接以任意顺序生成第一字符串，并在所述第一字符串的头部添加时戳位置标识，生成第二字符串；
具体的，可将所述用户的身份信息、随机数以及时戳拼接以任意顺序生成第一字符串，假设用户的身份信息为A，随机数为B，时戳为C，那么顺序可以为ABC，CBA，ACB，CAB，BCA，BAC中的任一个，当所述第一字符串生成之后，在所述第一字符串的头部添加时戳位置标识，用于标识所述时戳在所述第一字符串中的位置，所述时戳位置标识可以通过2位数字标识，例如00标识所述时戳在所述第一字符串的头部，01标识所述时戳在所述第一字符串的中间，10标识所述时戳在所述第一字符串的尾部，然后生成第二字符串，这样当服务端收到所述第二字符串后，读取头部2位数字，就能获得时戳的位置，进行解析后就能获取时戳的具体内容。
步骤s202，将所述第二字符串通过HASH算法在客户端生成一个TOKEN令牌。
当所述第二字符串生成之后，可将所述第二字符串通过HASH算法在客户端生成一个TOKEN令牌，所述HASH算法是一个HASH函数，就是把任意长度的输入通过散列算法变换成固定长度的输出，该输出就是散列值，同样的在服务端可通过HASH算法对TOKEN令牌进行解析获得字符串。
本实施例中，通过将用户的身份信息、时戳及随机数以任意顺序拼接，可以提高灵活性，提高数据处理效率。
图3为本申请第三个实施例的一种基于TOKEN令牌的身份校验方法流程示 意图，如图所示，所述步骤s102，当所述用户准备发起HTTP任务请求时，在客户端生成一个随机数，包括：
当所述用户准备发起HTTP任务请求时，在客户端生成一个任意位数的随机数；
具体的，所述的任意位数包括任意位数的正整数。
则所述根据所述用户的身份信息、随机数以及时戳在客户端生成当前的TOKEN令牌，包括：
步骤s301，将所述用户的身份信息、随机数以及时戳拼接生成一个字符串，并将所述时戳放在所述字符串的头部或尾部；
具体的，可先将所述用户的身份信息、随机数以及时戳拼接生成一个字符串，在拼接过程中，可将所述时间戳放在字符串的头部或尾部，并与服务端约定所述时间戳的位数与位置，例如时间戳可以是14位，分别是年月日时分秒，如20190424000000，然后可任意的将随机数及用户信息按不同顺序进行拼接，生成一串字符串x，这样服务端在收到字符串x后可通过所述字符串x读取对应的时间戳，假设用户的身份信息为A，随机数为B，时戳为C，那么顺序可以为ABC，CBA，ACB，BCA中的任一个，且时戳的位置与位数在客户端和服务端之间是事先约定好的，一旦约定好之后，在通信过程中不再更改。
步骤s302，将所述字符串通过HASH算法在客户端生成一个TOKEN令牌。
具体的，当所述字符串生成之后，可将所述字符串通过HASH算法在客户端生成一个TOKEN令牌，所述HASH算法是一个HASH函数，就是把任意长度的输入通过散列算法变换成固定长度的输出，该输出就是散列值，同样的在服务端可通过HASH算法对TOKEN令牌进行解析获得字符串。
本实施例中，通过预先在客户端与服务端之间预先约定时戳的位置及位数，由此可生成任意位数的随机数，而随机数是TOKEN的组成部分之一，因此可提高TOKEN校验的安全性。
图4为本申请第四个实施例的一种基于TOKEN令牌的身份校验方法流程示意图，如图所示，所述步骤s102，根据所述当前的TOKEN令牌向服务端发送HTTP任务请求，包括：
步骤s401，将所述字符串进行加密；
具体的，当所述字符串生成后，可对所述字符串进行备份，一个用于根据HASH算法生成TOKEN令牌，另一个可用于进行加密，所述加密可以是通过对称加密算法进行加密，加密的秘钥可以在客户端和服务器端事先约定，所述秘钥可以定期的在客户端和服务端之间更新，例如，预先设定更新时间段，如一周，一个月等，当到期之后，由客户端或者服务端发起秘钥更新请求，并根据所述秘钥更新请求更新双方的秘钥，在所述秘钥更新之前，秘钥不会改变；也可以是通过非对称加密算法进行加密，客户端和服务器端各维护一对公钥和私钥，即在客户端维护一个公钥和一个私钥，在服务端维护一个公钥和一个私钥，所述公钥用于对字符串进行加密，所述私钥用于对字符串进行解密，即如果在客户端用公钥对所述字符串进行加密，则在服务端用私钥对所述字符串进行解密。
步骤s402，将所述加密后的字符串放入所述HTTP任务请求的包头中，并将所述TOKEN令牌放入所述HTTP任务请求的包体中；
具体的，所述HTTP任务请求是通过HTTP任务请求数据包的形式进行发送，所述HTTP任务请求数据包包含包头和包体，当所述加密的字符串生成后，可将所述加密的字符串放入所述HTTP任务请求数据包的包头中，当所述TOKEN令牌生成后，可将所述TOKEN令牌放入所述HTTP任务请求数据包的包体中。
步骤s403，将所述HTTP任务请求发送给服务端。
具体的，当所述加密的字符串和所述TOKEN令牌都放入所述HTTP任务请求数据包后，就可将所述HTTP任务请求数据包发送给服务端了。
本实施例中，通过对所述字符串进行加密并和所述TOKEN一起发送，可以提高检验的安全性。
图5为本申请第五个实施例的一种基于TOKEN令牌的身份校验方法流程示意图，如图所示，所述步骤s103，对所述HTTP任务请求对应的用户身份进行校验之前，包括：
步骤s501，预设有效时间段；
具体的，可在服务端预设有效时间段，保证TOKEN的有效性，避免客户端在发起HTTP任务请求后，长时间没有到达服务端，而引起的安全风险，所述有 效时间段可以是一段时间，例如5秒钟或者10秒钟，。
步骤s502，对所述HTTP任务请求的包头进行解析，获得所述HTTP任务请求中的字符串，对所述字符串进行解密，获得所述字符串中的时戳；
具体的，当获取到客户端的HTTP任务请求数据包后，可对所述HTTP任务请求数据包中的包头进行解析，获得所述HTTP任务请求中的字符串，然后对所述字符串进行解密，所述服务端解密的方式需与客户端加密的方式一致，即如果客户端是对称加密，那么服务端应对称解密，然后获得所述字符串中的时戳，由于时戳是放在所述字符串的首部，且位数是预先在客户端和服务端之间约定好的，因此只要按照约定读取所述字符串的初始位数就可获取时戳。
步骤s503，获取服务端当前的系统时间，并将所述当前的系统时间与所述时戳之间的时间差与所述有效时间段进行比较，如果所述当前的系统时间与所述时戳之间的时间差在所述有效时间段内，则对用户身份进行校验，否则向客户端发送超时拒绝反馈信息。
具体的，当获取到客户端时戳之后，可获取服务端当前的系统时间，然后根据所述客户端时戳和所述服务端当前的系统时间获得时间差，并将所述时间差与所述预设的有效时间段进行比较，如果所述当前的系统时间与所述时戳之间的时间差在所述有效时间段内，则对用户身份进行校验，否则向客户端发送超时拒绝反馈信息，例如，如果预设有效时间段是30秒，收到的时戳是11点25分11秒，服务端系统当前时间是11点26分11秒，时间差是60秒，所述时间差远大于所述预设有效时间段，因此服务端可拒绝本次任务请求。
本实施例中，通过在服务端对HTTP任务请求中的时戳进行解析获得所述HTTP任务请求的有效期限，并根据所述有效期限确定本次请求的有效性，可以提高身份校验的安全性。
图6为本申请第六个实施例的一种基于TOKEN令牌的身份校验方法流程示意图，如图所示，所述步骤s103，对所述HTTP任务请求对应的用户身份进行校验，并根据校验结果向客户端发送反馈信息，包括：
步骤s601，对所述HTTP任务请求的包体进行解析，获得所述HTTP任务请求中的TOKEN令牌；
具体的，当获取到客户端的HTTP任务请求数据包后，可对所述HTTP任务请求数据包中的包体进行解析，获得所述HTTP任务请求中的TOKEN令牌。
步骤s602，根据所述解密后的字符串通过HASH算法生成校验TOKEN令牌；
具体的，当解析获得解密后的字符串之后，可根据HASH算法在服务端生成校验TOKEN令牌，所述校验TOKEN令牌用于与HTTP任务请求中的TOKEN进行比较，完成身份验证，由于字符串x是经过加密的，因此可将在服务端生成的TOKEN令牌作为比对样本，而HTTP任务请求中的TOKEN容易被人窃取，可用于身份验证，如果一致，则说明本次任务请求通过，这样可以无需让服务端生成TOKEN并发送给客户端，减轻服务端的负荷。
步骤s603，将所述校验TOKEN令牌与所述HTTP任务请求中的TOKEN令牌进行比对，如果一致，则校验通过，并向客户端发送校验成功反馈信息及本次HTTP任务请求对应的数据，否则向客户端发送校验失败拒绝反馈信息。
具体的，可将所述校验TOKEN令牌与所述HTTP任务请求中的TOKEN令牌进行比对，如果一致，则校验通过，并向客户端发送校验成功反馈信息及本次HTTP任务请求对应的数据，否则向客户端发送校验失败拒绝反馈信息。
本实施例中，通过在服务端对HTTP任务请求中的TOKEN通过HASH算法进行校验，可以有效提高校验的安全性。
图7为本申请第七个实施例的一种基于TOKEN令牌的身份校验方法流程示意图，如图所示，所述步骤s104，当客户端收到服务端的反馈信息后，根据所述反馈信息进行客户端数据的更新，包括：
步骤s701，当客户端收到超时拒绝的反馈信息时，在客户端生成新的随机数并获取新的时戳，根据所述新的随机数、新的时戳以及用户的身份信息生成新的TOKEN令牌，并根据所述新的TOKEN令牌向服务端再次发起HTTP任务请求；
具体的，当客户端收到超时拒绝的反馈信息时，可在所述客户端生成新的随机数并获取新的时戳，所述新的随机数也可以是任意的，即新的随机数可以和旧的随机数不同位数，不同数字；然后根据所述新的随机数、新的时戳以及用户的身份信息生成新的TOKEN令牌，并根据所述新的TOKEN令牌向服务端再次发起HTTP任务请求。
步骤s702，当客户端收到校验失败拒绝的反馈信息时，结束本次HTTP任务请求；
具体的，当客户端收到校验失败拒绝的反馈信息时，可直接结束本次HTTP任务请求，不再发起新的HTTP任务请求。
步骤s703，当客户端收到校验成功的反馈信息时，结束本次HTTP任务请求，并根据服务端发送的与所述HTTP任务请求对应的的数据进行更新。
具体的，当客户端收到校验成功的反馈信息时，可结束本次HTTP任务请求，并根据服务端发送的与所述HTTP任务请求对应的的数据进行更新，例如，客户端向服务端发起一个读取用户历史订单的请求，服务端接收到所述请求，开始校验用户的身份，校验成功后将所述用户的历史订单数据查询出来返回给客户端，客户端收到所述历史订单数据后进行客户端数据的更新。
本实施例中，通过在客户端根据服务端的反馈信息进行进一步操作，在超时的时候可以重新发起请求，避免不必要的通信中断，在校验失败的时候结束请求，避免过多的请求增加系统负担，并在成功的时候更新本地数据，提高系统的运行效率。
本申请实施例的一种基于TOKEN令牌的身份校验装置结构如图8所示，包括：
信息获取模块801、请求发送模块802、校验模块803及更新模块804；其中，信息获取模块801与请求发送模块802相连，请求发送模块802与校验模块803相连，校验模块803与更新模块804相连；信息获取模块801设置为在客户端对用户的登录状态进行检测，当检测到用户在客户端成功登录时，获取所述用户的身份信息；请求发送模块802设置为当所述用户准备发起HTTP任务请求时，在客户端生成一个随机数，并获取客户端的时戳，根据所述用户的身份信息、随机数以及时戳在客户端生成当前的TOKEN令牌，并根据所述当前的TOKEN令牌向服务端发送HTTP任务请求；校验模块803设置为当服务端收到所述HTTP任务请求后，对所述HTTP任务请求对应的用户身份进行校验，并根据校验结果向客户端发送反馈信息；更新模块804设置为当客户端收到服务端的反馈信息后，根据所述反馈信息对本次HTTP任务请求对应的数据进行更新。
本申请实施例还公开了一种计算机设备，所述计算机设备包括存储器和处理器，所述存储器中存储有计算机可读指令，所述计算机可读指令被一个或多个所述处理器执行时，使得一个或多个所述处理器执行上述各实施例中所述身份校验方法中的步骤。
本申请实施例还公开了一种计算机可读存储介质，所述存储介质可被处理器读写，所述存储器存储有计算机可读指令，所述计算机可读指令被一个或多个处理器执行时，使得一个或多个处理器执行上述各实施例中所述身份校验方法中的步骤。需要说明的是，该计算机可读存储介质可以是易失性的，也可以是非易失性的，具体此处不做限定。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，该计算机程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，前述的存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)等非易失性存储介质，或随机存储记忆体(Random Access Memory，RAM)等。
以上所述实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。
以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对本申请专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。

Claims (20)

  1. 一种基于TOKEN令牌的身份校验方法，包括以下步骤：
    在客户端对用户的登录状态进行检测，当检测到用户在客户端成功登录时，获取所述用户的身份信息；
    当所述用户准备发起HTTP任务请求时，在客户端生成一个随机数，并获取客户端的时戳，根据所述用户的身份信息、随机数以及时戳在客户端生成当前的TOKEN令牌，并根据所述当前的TOKEN令牌向服务端发送HTTP任务请求；
    当服务端收到所述HTTP任务请求后，对所述HTTP任务请求对应的用户身份进行校验，并根据校验结果向客户端发送反馈信息；
    当客户端收到服务端的反馈信息后，根据所述反馈信息对本次HTTP任务请求对应的数据进行更新。
  2. 如权利要求1所述的基于TOKEN令牌的身份校验方法，其中，所述当所述用户准备发起HTTP任务请求时，在客户端生成一个随机数，包括：
    当所述用户准备发起HTTP任务请求时，在客户端生成一个与所述用户的身份信息相同位数的随机数；
    则所述根据所述用户的身份信息、随机数以及时戳在客户端生成当前的TOKEN令牌，包括：
    将所述用户的身份信息、随机数以及时戳拼接以任意顺序生成第一字符串，并在所述第一字符串的头部添加时戳位置标识，生成第二字符串；
    将所述第二字符串通过HASH算法在客户端生成一个TOKEN令牌。
  3. 如权利要求1所述的基于TOKEN令牌的身份校验方法，其中，所述当所述用户准备发起HTTP任务请求时，在客户端生成一个随机数，包括：
    当所述用户准备发起HTTP任务请求时，在客户端生成一个任意位数的随机数；
    则所述根据所述用户的身份信息、随机数以及时戳在客户端生成当前的TOKEN令牌，包括：
    将所述用户的身份信息、随机数以及时戳拼接生成一个字符串，并将所述时戳放在所述字符串的头部或尾部；
    将所述字符串通过HASH算法在客户端生成一个TOKEN令牌。
  4. 如权利要求3所述的基于TOKEN令牌的身份校验方法，其中，所述根据所述当前的TOKEN令牌向服务端发送HTTP任务请求，包括：
    将所述字符串进行加密；
    将所述加密后的字符串放入所述HTTP任务请求的包头中，并将所述TOKEN令牌放入所述HTTP任务请求的包体中；
    将所述HTTP任务请求发送给服务端。
  5. 如权利要求1所述的基于TOKEN令牌的身份校验方法，其中，所述对所述HTTP任务请求对应的用户身份进行校验之前，包括：
    预设有效时间段；
    对所述HTTP任务请求的包头进行解析，获得所述HTTP任务请求中的字符串，对所述字符串进行解密，获得所述字符串中的时戳；
    获取服务端当前的系统时间，并将所述当前的系统时间与所述时戳之间的时间差与所述有效时间段进行比较，如果所述当前的系统时间与所述时戳之间的时间差在所述有效时间段内，则对用户身份进行校验，否则向客户端发送超时拒绝反馈信息。
  6. 如权利要求5所述的基于TOKEN令牌的身份校验方法，其中，所述对所述HTTP任务请求对应的用户身份进行校验，并根据校验结果向客户端发送反馈信息，包括：
    对所述HTTP任务请求的包体进行解析，获得所述HTTP任务请求中的TOKEN令牌；
    根据所述解密后的字符串通过HASH算法生成校验TOKEN令牌；
    将所述校验TOKEN令牌与所述HTTP任务请求中的TOKEN令牌进行比对，如果一致，则校验通过，并向客户端发送校验成功反馈信息及本次HTTP任务请求对应的数据，否则向客户端发送校验失败拒绝反馈信息。
  7. 如权利要求6所述的基于TOKEN令牌的身份校验方法，其中，所述当客户端收到服务端的反馈信息后，根据所述反馈信息对本次HTTP任务请求对应的数据进行更新，包括：
    当客户端收到超时拒绝的反馈信息时，在客户端生成新的随机数并获取新的时戳，根据所述新的随机数、新的时戳以及用户的身份信息生成新的TOKEN令牌，并根据所述新的TOKEN令牌向服务端再次发起HTTP任务请求；
    当客户端收到校验失败拒绝的反馈信息时，结束本次HTTP任务请求；
    当客户端收到校验成功的反馈信息时，结束本次HTTP任务请求，并根据服务端发送的与所述HTTP任务请求对应的的数据进行更新。
  8. 一种基于TOKEN令牌的身份校验装置，所述装置包括：
    信息获取模块：设置为在客户端对用户的登录状态进行检测，当检测到用户在客户端成功登录时，获取所述用户的身份信息；
    请求发送模块：设置为当所述用户准备发起HTTP任务请求时，在客户端生成一个随机数，并获取客户端的时戳，根据所述用户的身份信息、随机数以及时戳在客户端生成当前的TOKEN令牌，并根据所述当前的TOKEN令牌向服务端发送HTTP任务请求；
    校验模块：设置为当服务端收到所述HTTP任务请求后，对所述HTTP任务请求对应的用户身份进行校验，并根据校验结果向客户端发送反馈信息；
    更新模块：设置为当客户端收到服务端的反馈信息后，根据所述反馈信息对本次HTTP任务请求对应的数据进行更新。
  9. 根据权利要求8所述的基于TOKEN令牌的身份校验装置，其中，所述请求发送模块，还设置为当所述用户准备发起HTTP任务请求时，在客户端生成一个与所述用户的身份信息相同位数的随机数。
  10. 根据权利要求8所述的基于TOKEN令牌的身份校验装置，其中，所述请求发送模块，还设置为当所述用户准备发起HTTP任务请求时，在客户端生成一个任意位数的随机数。
  11. 根据权利要求8所述的基于TOKEN令牌的身份校验装置，其中，所述请求发送模块，包括：
    加密单元：设置为将所述字符串进行加密；
    封装单元：设置为将所述加密后的字符串放入所述HTTP任务请求的包头中，并将所述TOKEN令牌放入所述HTTP任务请求的包体中；
    发送单元：设置为将所述HTTP任务请求发送给服务端。
  12. 根据权利要求8所述的基于TOKEN令牌的身份校验装置，其中，所述校验模块，包括：
    预置单元：设置为预设有效时间段；
    第一解析单元：设置为对所述HTTP任务请求的包头进行解析，获得所述HTTP任务请求中的字符串，对所述字符串进行解密，获得所述字符串中的时戳；
    比较单元：设置为获取服务端当前的系统时间，并将所述当前的系统时间与所述时戳之间的时间差与所述有效时间段进行比较，如果所述当前的系统时间与所述时戳之间的时间差在所述有效时间段内，则对用户身份进行校验，否则向客户端发送超时拒绝反馈信息。
  13. 根据权利要求12所述的基于TOKEN令牌的身份校验装置，其中，所述校验模块，包括：
    第二解析单元：设置为对所述HTTP任务请求的包体进行解析，获得所述HTTP任务请求中的TOKEN令牌；
    输出单元：设置为根据所述解密后的字符串通过HASH算法生成校验TOKEN令牌；
    反馈单元：设置为将所述校验TOKEN令牌与所述HTTP任务请求中的TOKEN令牌进行比对，如果一致，则校验通过，并向客户端发送校验成功反馈信息及本次HTTP任务请求对应的数据，否则向客户端发送校验失败拒绝反馈信息。
  14. 根据权利要求13所述的基于TOKEN令牌的身份校验装置，其中，所述更新模块，包括：
    接收单元：设置为当客户端收到超时拒绝的反馈信息时，在客户端生成新的随机数并获取新的时戳，根据所述新的随机数、新的时戳以及用户的身份信息生成新的TOKEN令牌，并根据所述新的TOKEN令牌向服务端再次发起HTTP任务请求；
    第一处理单元：设置为当客户端收到校验失败拒绝的反馈信息时，结束本次HTTP任务请求；
    第二处理单元：设置为当客户端收到校验成功的反馈信息时，结束本次HTTP任务请求，并根据服务端发送的与所述HTTP任务请求对应的的数据进行更新。
  15. 一种计算机设备，所述计算机设备包括存储器和处理器，所述存储器中存储有计算机可读指令，所述计算机可读指令被一个或多个所述处理器执行时，使得一个或多个所述处理器执行以下步骤：
    在客户端对用户的登录状态进行检测，当检测到用户在客户端成功登录时，获取所述用户的身份信息；
    当所述用户准备发起HTTP任务请求时，在客户端生成一个随机数，并获取客户端的时戳，根据所述用户的身份信息、随机数以及时戳在客户端生成当前的TOKEN令牌，并根据所述当前的TOKEN令牌向服务端发送HTTP任务请求；
    当服务端收到所述HTTP任务请求后，对所述HTTP任务请求对应的用户身份进行校验，并根据校验结果向客户端发送反馈信息；
    当客户端收到服务端的反馈信息后，根据所述反馈信息对本次HTTP任务请求对应的数据进行更新。
  16. 根据权利要求15所述的计算机设备，其中，所述根据所述当前的TOKEN令牌向服务端发送HTTP任务请求时，使得所述处理器执行以下步骤：
    将所述字符串进行加密；
    将所述加密后的字符串放入所述HTTP任务请求的包头中，并将所述TOKEN令牌放入所述HTTP任务请求的包体中；
    将所述HTTP任务请求发送给服务端。
  17. 根据权利要求15所述的计算机设备，其中，所述对所述HTTP任务请求对应的用户身份进行校验，并根据校验结果向客户端发送反馈信息时，使得所述处理器执行以下步骤：
    对所述HTTP任务请求的包体进行解析，获得所述HTTP任务请求中的TOKEN令牌；
    根据所述解密后的字符串通过HASH算法生成校验TOKEN令牌；
    将所述校验TOKEN令牌与所述HTTP任务请求中的TOKEN令牌进行比对，如果一致，则校验通过，并向客户端发送校验成功反馈信息及本次HTTP任务请求对应的数据，否则向客户端发送校验失败拒绝反馈信息。
  18. 一种计算机可读存储介质，所述存储介质可被处理器读写，所述存储介质存储有计算机指令，所述计算机可读指令被一个或多个处理器执行时，使得一个或多个处理器执行以下步骤：
    在客户端对用户的登录状态进行检测，当检测到用户在客户端成功登录时，获取所述用户的身份信息；
    当所述用户准备发起HTTP任务请求时，在客户端生成一个随机数，并获取客户端的时戳，根据所述用户的身份信息、随机数以及时戳在客户端生成当前的TOKEN令牌，并根据所述当前的TOKEN令牌向服务端发送HTTP任务请求；
    当服务端收到所述HTTP任务请求后，对所述HTTP任务请求对应的用户身份进行校验，并根据校验结果向客户端发送反馈信息；
    当客户端收到服务端的反馈信息后，根据所述反馈信息对本次HTTP任务请求对应的数据进行更新。
  19. 根据权利要求18所述的存储介质，其中，所述根据所述当前的TOKEN令牌向服务端发送HTTP任务请求时，使得一个或多个所述处理器执行以下步骤：
    将所述字符串进行加密；
    将所述加密后的字符串放入所述HTTP任务请求的包头中，并将所述TOKEN令牌放入所述HTTP任务请求的包体中；
    将所述HTTP任务请求发送给服务端。
  20. 根据权利要求18所述的存储介质，其中，所述对所述HTTP任务请求 对应的用户身份进行校验，并根据校验结果向客户端发送反馈信息时，使得一个或多个所述处理器执行以下步骤：
    对所述HTTP任务请求的包体进行解析，获得所述HTTP任务请求中的TOKEN令牌；
    根据所述解密后的字符串通过HASH算法生成校验TOKEN令牌；
    将所述校验TOKEN令牌与所述HTTP任务请求中的TOKEN令牌进行比对，如果一致，则校验通过，并向客户端发送校验成功反馈信息及本次HTTP任务请求对应的数据，否则向客户端发送校验失败拒绝反馈信息。
PCT/CN2019/117322 2019-09-09 2019-11-12 基于token令牌的身份校验方法及相关设备 WO2021047012A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201910849275.5A CN110493258B (zh) 2019-09-09 2019-09-09 基于token令牌的身份校验方法及相关设备
CN201910849275.5 2019-09-09

Publications (1)

Publication Number Publication Date
WO2021047012A1 true WO2021047012A1 (zh) 2021-03-18

Family

ID=68557013

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2019/117322 WO2021047012A1 (zh) 2019-09-09 2019-11-12 基于token令牌的身份校验方法及相关设备

Country Status (2)

Country Link
CN (1) CN110493258B (zh)
WO (1) WO2021047012A1 (zh)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111756702B (zh) * 2020-05-29 2022-11-08 北京沃东天骏信息技术有限公司 数据安全防护方法、装置、设备和存储介质
CN112822175B (zh) * 2020-12-31 2022-06-28 联想(北京)有限公司 一种信息访问方法、装置及电子设备
CN113179277B (zh) * 2021-05-07 2022-08-02 济南云拓互动传媒有限公司 一种隐藏于标准http明文消息头的校验方法
CN113285808B (zh) * 2021-05-18 2024-03-26 挂号网（杭州）科技有限公司 一种身份信息核验方法、装置、设备和存储介质
CN113395282A (zh) * 2021-06-15 2021-09-14 济南浪潮智投智能科技有限公司 一种阻止第三方访问服务端资源的方法及系统
CN113542235B (zh) * 2021-06-28 2023-04-07 上海浦东发展银行股份有限公司 一种基于令牌互信机制的安全互访方法
CN113709162A (zh) * 2021-08-30 2021-11-26 康键信息技术（深圳）有限公司 内网数据的获取方法、装置、设备及存储介质
CN113726513B (zh) * 2021-08-31 2022-08-09 西安交通大学 一种用于视频实时传输安全监测方法、系统、设备及可读存储介质
CN114124534A (zh) * 2021-11-24 2022-03-01 航天信息股份有限公司 一种数据交互系统及方法
CN114650175B (zh) * 2022-03-21 2024-04-02 网宿科技股份有限公司 一种验证方法及装置
CN114938313B (zh) * 2022-07-26 2022-10-04 北京盛邦赛云科技有限公司 一种基于动态令牌的人机识别方法及装置

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004062187A1 (en) * 2002-12-31 2004-07-22 American Express Travel Related Services Company, Inc. Method and system for modular authentication and session management
CN103188344A (zh) * 2013-02-22 2013-07-03 浪潮电子信息产业股份有限公司 一种安全调用rest api的方法
WO2014078605A1 (en) * 2012-11-14 2014-05-22 Google Inc. Client token storage for cross-site request forgery protection
CN105227551A (zh) * 2015-09-24 2016-01-06 四川长虹电器股份有限公司 Xbrl应用平台的统一权限管理方法
CN105471916A (zh) * 2016-01-13 2016-04-06 西安电子科技大学 防范安全套接层潜信道密钥恢复的方法
CN106161032A (zh) * 2015-04-24 2016-11-23 华为技术有限公司 一种身份认证的方法及装置
CN108494740A (zh) * 2018-03-01 2018-09-04 捷开通讯(深圳)有限公司 令牌生成和校验方法、智能终端及服务器

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106936570B (zh) * 2015-12-31 2021-08-20 华为技术有限公司 一种密钥配置方法及密钥管理中心、网元
CN108737326B (zh) * 2017-04-14 2021-03-30 北京京东尚科信息技术有限公司 用于进行令牌验证的方法、系统、装置及电子设备

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004062187A1 (en) * 2002-12-31 2004-07-22 American Express Travel Related Services Company, Inc. Method and system for modular authentication and session management
WO2014078605A1 (en) * 2012-11-14 2014-05-22 Google Inc. Client token storage for cross-site request forgery protection
CN103188344A (zh) * 2013-02-22 2013-07-03 浪潮电子信息产业股份有限公司 一种安全调用rest api的方法
CN106161032A (zh) * 2015-04-24 2016-11-23 华为技术有限公司 一种身份认证的方法及装置
CN105227551A (zh) * 2015-09-24 2016-01-06 四川长虹电器股份有限公司 Xbrl应用平台的统一权限管理方法
CN105471916A (zh) * 2016-01-13 2016-04-06 西安电子科技大学 防范安全套接层潜信道密钥恢复的方法
CN108494740A (zh) * 2018-03-01 2018-09-04 捷开通讯(深圳)有限公司 令牌生成和校验方法、智能终端及服务器

Also Published As

Publication number Publication date
CN110493258B (zh) 2022-09-30
CN110493258A (zh) 2019-11-22

Similar Documents

Publication Publication Date Title
WO2021047012A1 (zh) 基于token令牌的身份校验方法及相关设备
US11533297B2 (en) Secure communication channel with token renewal mechanism
US8196186B2 (en) Security architecture for peer-to-peer storage system
US7979707B2 (en) Secure seed generation protocol
JP4746333B2 (ja) コンピューティングシステムの効率的かつセキュアな認証
US9137017B2 (en) Key recovery mechanism
US8555069B2 (en) Fast-reconnection of negotiable authentication network clients
WO2022021992A1 (zh) 一种基于NB-IoT通信的数据传输方法、系统及介质
JP2022501971A (ja) 鍵管理のための方法、ユーザ・デバイス、管理デバイス、記憶媒体及びコンピュータ・プログラム製品
CN111080299B (zh) 一种交易信息的防抵赖方法及客户端、服务器
CN111130798B (zh) 一种请求鉴权方法及相关设备
KR20150135032A (ko) Puf를 이용한 비밀키 업데이트 시스템 및 방법
CN114900304A (zh) 数字签名方法和装置、电子设备和计算机可读存储介质
CN110581829A (zh) 通信方法及装置
WO2022042198A1 (zh) 身份验证方法、装置、计算机设备和存储介质
WO2020211348A1 (zh) 用户信息加解密方法、系统和计算机设备
US20240064143A1 (en) Methods, mediums, and systems for verifying devices in an encrypted messaging system
JPWO2020065633A5 (zh)
US11277269B2 (en) System and methods for generating and authenticating verifiable network traffic
US11743035B2 (en) Methods, mediums, and systems for verifying devices in an encrypted messaging system
US11658955B1 (en) Methods, mediums, and systems for verifying devices in an encrypted messaging system
JP2004274134A (ja) 通信方法並びにこの通信方法を用いた通信システム、サーバおよびクライアント
US11843636B1 (en) Methods, mediums, and systems for verifying devices in an encrypted messaging system
CN116506120B (zh) 密钥加载方法、密钥系统以及可读存储介质
CN109981678B (zh) 一种信息同步方法及装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19944880

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 22/07/2022)

122 Ep: pct application non-entry in european phase

Ref document number: 19944880

Country of ref document: EP

Kind code of ref document: A1