Access verification method and device, computer device and computer readable storage medium

Abstract

The application provides an access verification method and device, computer equipment and a computer readable storage medium, and belongs to the technical field of Internet of Things. The method comprises the following steps: receiving an access request sent by a terminal device, wherein the access request comprises a short-time token and a long-time token, and the long-time token is generated based on valid identity information of a user; analyzing the access request to obtain the short-time token and the long-time token; determining whether the short-time token is valid, and if not, determining whether the long-time token is valid according to the long-time token and the valid identity information of the user stored on the authentication server; in the case that the long-time token is valid, generating a new short-time token for the terminal device according to the long-time token and sending the short-time token to the terminal device, and forwarding the access request to a data server. The application can improve the access security.

Description

Technical Field

[0001] The present application relates to the field of Internet of Things technology, and more specifically, to an access verification method, apparatus, computer device, and computer-readable storage medium. Background Art

[0002] With the development of information technology, Internet of Things technology has entered people's work and life. For example, users may need to log in to the Internet of Things management system on their terminal devices to obtain data or files stored on the data server through the Internet of Things management system, so that users can view, manage or adjust various devices of the Internet of Things.

[0003] In the related art, generally, when a user logs in to the Internet of Things management system, he needs to enter the corresponding account and password so that the Internet of Things management system can verify the user's identity. Specifically, the user can send the account and password to the server for verification through the terminal device. After the account and password are verified, the server can generate a cookie file that is valid for a period of time based on the account and password and send it to the terminal device. When the terminal device subsequently sends an access request to the server, it will carry the cookie file. The server can determine whether the user's identity is verified by identifying whether the cookie file is valid. Only when the user's identity is verified will the terminal device be allowed to access the server.

[0004] However, all Cookie files in the related art need to be stored on the terminal device, and the user information recorded in the Cookie file can be easily tampered with or intercepted, which leads to the problem of poor access security in the solution of the related art. Summary of the Invention

[0005] The purpose of this application is to provide an access verification method, apparatus, computer device and computer-readable storage medium, which can improve access security.

[0006] The embodiment of the present application is implemented as follows:

[0007] In a first aspect of an embodiment of the present application, an access verification method is provided, which is applied to an authentication server in an Internet of Things access system. The method includes:

[0008] Receiving an access request sent by a terminal device, the access request including: a short-term token and a long-term token, the long-term token being generated based on valid identity information of the user;

[0009] Parsing the access request to obtain the short-term token and the long-term token;

[0010] Determining whether the short-term token is valid, and if not, determining whether the long-term token is valid based on the long-term token and the valid identity information of the user stored on the authentication server;

[0011] When the long-term token is valid, a new short-term token is generated for the terminal device according to the long-term token, the short-term token is sent to the terminal device, and the access request is forwarded to the data server.

[0012] Optionally, before receiving the access request sent by the terminal device, the method further includes:

[0013] receiving a login request sent by the terminal device, wherein the login request includes identity information to be authenticated input by the user on the terminal device;

[0014] authenticating the identity information to be authenticated;

[0015] When the identity information to be authenticated is authenticated successfully, a short-term token and a long-term token are generated according to the identity information to be authenticated, and the short-term token and the long-term token are sent to the terminal device.

[0016] Optionally, the identity information to be authenticated includes account information and an identifier of the account information;

[0017] The generating of a short-term token and a long-term token according to the identity information to be authenticated includes:

[0018] Generate the short-term token according to the first encryption algorithm and the account information;

[0019] The long-term token is generated according to a second encryption algorithm, the short-term token and an identifier of the account information.

[0020] Optionally, generating the short-term token according to the first encryption algorithm and the account information includes:

[0021] Converting the account information into character information;

[0022] Convert the character information into a character string of a preset base;

[0023] The character string and the first validity duration in the configuration information of the authentication server are encrypted based on the first encryption algorithm to generate the short-term token.

[0024] Optionally, generating a long-term token according to the second encryption algorithm, the short-term token, and the identifier of the account information includes:

[0025] Concatenate the short-lived token and the identifier of the account information to obtain an index identifier;

[0026] Encrypting the index identifier based on the second encryption algorithm to obtain the long-term token;

[0027] The long-term token is bound to the valid identity information, and the valid identity information is stored.

[0028] Optionally, after binding the long-term token with the valid identity information and storing the valid identity information, the method further includes:

[0029] Determining a storage period for the valid identity information to be stored in the authentication server;

[0030] Comparing the storage duration with a second validity duration in the configuration information of the authentication server;

[0031] If the storage duration is greater than or equal to the second validity duration, the valid identity information is deleted.

[0032] Optionally, determining whether the long-term token is valid according to the long-term token and valid identity information of the user stored on the authentication server includes:

[0033] Decrypting the long-term token based on a first decryption algorithm to obtain an index identifier, and reading an identifier of the account information from the index identifier;

[0034] Determine whether the identifier of the account information matches the valid identity information of the user, and if so, determine that the long-term token is valid.

[0035] Optionally, generating a new short-term token for the terminal device according to the long-term token and sending the short-term token to the terminal device includes:

[0036] Decrypting the long-term token based on a first decryption algorithm to obtain an index identifier, and reading the short-term token from the index identifier;

[0037] Decrypt the short-term token based on a second decryption algorithm to obtain a character string and a first validity period corresponding to the short-term token;

[0038] A new short-term token is generated according to the current time, the character string and the first validity period, and the new short-term token is sent to the terminal device.

[0039] A second aspect of the embodiments of the present application provides an access verification device, which is applied to an authentication server in an Internet of Things access system. The device includes:

[0040] A receiving module, configured to receive an access request sent by a terminal device, wherein the access request includes: a short-term token and a long-term token, wherein the long-term token is generated based on valid identity information of the user;

[0041] A parsing module, configured to parse the access request to obtain the short-term token and the long-term token;

[0042] an authentication module, configured to determine whether the short-term token is valid, and if not, to determine whether the long-term token is valid based on the long-term token and the valid identity information of the user stored on the authentication server;

[0043] The authentication module is further configured to generate a new short-term token for the terminal device based on the long-term token when the long-term token is valid, send the short-term token to the terminal device, and forward the access request to the data server.

[0044] In a third aspect of an embodiment of the present application, a computer device is provided, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the access verification method described in the first aspect above.

[0045] According to a fourth aspect of an embodiment of the present application, a computer-readable storage medium is provided, wherein the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the access verification method described in the first aspect is implemented.

[0046] The beneficial effects of the embodiments of the present application include:

[0047] An access verification method provided by an embodiment of the present application receives an access request sent by a terminal device, parses the access request, and obtains the short-term token and the long-term token. The short-term token and the long-term token can be used to indicate whether the terminal device or the account logged in on the terminal device has the authority to access the data server. Since the short-term token and the long-term token can be stored in the request header information of the access request, when the authentication server parses the access request to obtain the short-term token and the long-term token for identity verification, it can only parse and read the request header information of the access request without parsing the entire access request to determine whether the terminal device can access the data server. In this way, the processing pressure of the authentication server can be reduced and the efficiency of access verification can be improved.

[0048] Determine whether the short-lived token is valid. If not, determine whether the long-lived token is valid based on the long-lived token and the valid identity information of the user stored on the authentication server. Since both the short-lived token and the long-lived token are encrypted, even if other people obtain the short-lived token and the long-lived token, they cannot decrypt or tamper with them, and thus cannot obtain the valid identity information recorded in them. This reduces the risk of tampering with the short-lived token and the long-lived token, and improves the security of the valid identity information recorded in them.

[0049] When the long-term token is valid, a new short-term token is generated for the terminal device based on the long-term token and the short-term token is sent to the terminal device, and the access request is forwarded to the data server, and the data matching the content information sent by the data server is received, and the data matching the content information is forwarded to the corresponding terminal device. In this way, the terminal device can correctly access the data server when the short-term token and / or long-term token is valid.

[0050] In addition, if both the short-term token and the long-term token are invalid, the terminal device sending the access request will fail the verification, output a corresponding prompt message to inform the user that the access failed, and terminate the process. In this way, terminal devices with invalid short-term tokens and long-term tokens can be prevented from accessing the data server, thereby preventing users without corresponding permissions from obtaining data in the data server.

[0051] If the short-lived token is valid, the terminal device can be directly confirmed to have passed the verification. In this case, the access request can be directly forwarded to the data server. In this way, there is no need to verify the validity of the long-lived token, which can reduce the processing pressure of the cache unit in the authentication server.

[0052] In this way, the access security and the efficiency of access verification can be improved. BRIEF DESCRIPTION OF THE DRAWINGS

[0053] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments. It should be understood that the following drawings only show certain embodiments of the present application and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other relevant drawings can be obtained based on these drawings without paying any creative work.

[0054] Figure 1 A schematic diagram of the structure of an Internet of Things access system provided in an embodiment of the present application;

[0055] Figure 2 A flowchart of the first access verification method provided in an embodiment of the present application;

[0056] Figure 3 A flowchart of the second access verification method provided in an embodiment of the present application;

[0057] Figure 4 A flowchart of the third access verification method provided in an embodiment of the present application;

[0058] Figure 5 A flowchart of the fourth access verification method provided in an embodiment of the present application;

[0059] Figure 6 A flowchart of the fifth access verification method provided in an embodiment of the present application;

[0060] Figure 7 A flowchart of the sixth access verification method provided in an embodiment of the present application;

[0061] Figure 8 A flowchart of the seventh access verification method provided in an embodiment of the present application;

[0062] Figure 9 A schematic diagram of the structure of an access verification device provided in an embodiment of the present application;

[0063] Figure 10 A schematic diagram of the structure of a computer device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0064] To make the objectives, technical solutions, and advantages of the embodiments of the present application more clear, the technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the accompanying drawings of the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Generally, the components of the embodiments of the present application described and shown in the drawings herein can be arranged and designed in various different configurations.

[0065] Therefore, the following detailed description of the embodiments of the present application provided in the accompanying drawings is not intended to limit the scope of the present application for protection, but merely represents selected embodiments of the present application. All other embodiments obtained by persons of ordinary skill in the art based on the embodiments in the present application without creative work are within the scope of protection of the present application.

[0066] It should be noted that similar reference numerals and letters denote similar items in the following drawings, and therefore, once an item is defined in one drawing, it does not need to be further defined or explained in subsequent drawings.

[0067] In the related art, generally, when a user logs in to the Internet of Things management system, he needs to enter the corresponding account and password so that the Internet of Things management system can verify the user's identity. Specifically, the user can send the account and password to the server for verification through the terminal device. After the account and password are verified, the server can generate a cookie file that is valid for a period of time based on the account and password and send it to the terminal device. When the terminal device subsequently sends an access request to the server, it will carry the cookie file. The server can determine whether the user's identity has been verified by identifying whether the cookie file is valid. Only when the user's identity has been verified will the terminal device be allowed to access the server. However, the cookie files in the related art need to be stored entirely on the terminal device, and the user information recorded in the cookie file can be easily tampered with or intercepted, which leads to the problem of poor access security in the related art solution.

[0068] To this end, an embodiment of the present application provides an access verification method, which receives an access request sent by a terminal device, parses the access request, obtains the short-term token and the long-term token, and determines whether the short-term token is valid. If not, it determines whether the long-term token is valid based on the long-term token and the valid identity information of the user stored on the authentication server. If the long-term token is valid, a new short-term token is generated for the terminal device based on the long-term token and the short-term token is sent to the terminal device, and the access request is forwarded to the data server, which can achieve the effect of improving access security.

[0069] The embodiments of the present application are described using an access verification method applied in an IoT access system as an example, but this does not mean that the embodiments of the present application can only be applied to IoT access systems for access verification.

[0070] In one possible implementation, see Figure 1 The Internet of Things access system may include an authentication server A, multiple terminal devices B, and multiple data servers C.

[0071] Each terminal device B is respectively connected to the authentication server A for communication, and the authentication server A is respectively connected to the data servers for communication.

[0072] Optionally, each terminal device B may run software or applications for managing, controlling, and viewing each device in the Internet of Things.

[0073] Each terminal device B may send a login request, an access request, and any other possible requests and / or data to the authentication server A.

[0074] Each data server C stores information or data such as parameters, status, and configuration of each device in the Internet of Things.

[0075] Authentication server A can be used to authenticate the identity of each terminal device B based on the login request sent by each terminal device B, and generate a corresponding token and send it to each terminal device B. Authentication server A can also be used to verify the token in the access request sent by each terminal device B to determine whether each terminal device B can access each data server C. Authentication server A can also be used to forward the access request to each data server C if it is determined that each terminal device B can access each data server C, so that each terminal device B can obtain the corresponding data or information from each data server C.

[0076] Specifically, the authentication server A may include an authentication unit D and a cache unit E.

[0077] The authentication unit D may be used to authenticate the login request sent by each terminal device B and generate a corresponding token, and may also be used to verify the access request sent by the terminal device B.

[0078] The cache unit E may generate a corresponding token according to the login request sent by each terminal device B, and may also store the valid identity information of the user and delete the valid identity information after the valid identity information expires or becomes invalid.

[0079] It should be noted that authentication unit D can be an authentication gateway server. Specifically, authentication unit D can accept HTTP requests from the outside, filter the token in the access request, authenticate the identity of terminal device B, and forward the access request to each data server C if the authentication is successful. If the authentication fails, it returns a corresponding prompt message to the terminal device. Cache unit E can be a device for deploying a KV cache database or a NoSQL (Not only SQL) database. Both KV cache databases and NoSQL databases are index databases that can quickly access character or binary data structures.

[0080] That is, the cache unit E can perform KV cache service.

[0081] The above is only a schematic diagram of the structure of an Internet of Things access system provided by this application, and does not mean that the Internet of Things access system provided by the embodiment of this application can only be used Figure 1 The structural deployment shown does not mean that the access verification method provided in the embodiment of the present application can only be applied to Figure 1 The structure shown is the IoT access system.

[0082] The access verification method provided in the embodiment of the present application is explained in detail below.

[0083] Figure 2This is a flowchart of an access verification method provided by this application. This method can be applied to an authentication server in an IoT access system. The authentication server can be the authentication server A mentioned above. Figure 2 , an embodiment of the present application provides an access verification method, comprising:

[0084] Step 1001: Receive an access request sent by a terminal device.

[0085] Optionally, the terminal device may be the aforementioned terminal device B. Furthermore, the access request may be received by an authentication unit in the authentication server.

[0086] Optionally, the access request includes: a short-term token and a long-term token. The access request may also include content information, which may include data, information or files that the terminal device or the user operating the terminal device needs to obtain.

[0087] The access request may be a request of the HTTP protocol, a request of the HTTPS protocol, or a request of any other possible protocol, which is not limited in the embodiments of the present application.

[0088] Optionally, the short-term token may be a token generated based on a digital signature algorithm, and the long-term token may be a token generated based on an Advanced Encryption Standard (AES) algorithm.

[0089] Generally, the validity period of the short-term token can be shorter, generally one day. The validity period of the long-term token can be longer, generally one week. This embodiment of the present application does not limit this.

[0090] The long-term token is generated based on the valid identity information of the user. The short-term token can also be generated based on the valid identity information.

[0091] The valid identity information may refer to the identity information corresponding to the identity information to be verified, which is read or obtained by the authentication server after the user inputs account information through the terminal device to wait for identity information verification and the identity information to be verified passes the verification.

[0092] The account information may include an account number and an account password.

[0093] The valid identity information may include the account information entered by the user, the identifier of the account information corresponding to the account information entered by the user, the user name, gender, age, setting content, and other information, which is not limited in this embodiment of the present application.

[0094] In addition, the short-term token can be generated only based on the account information in the valid identity information, and the long-term token can be generated based on the identifier of the short-term token and the account information in the valid identity information. This embodiment of the present application does not limit this.

[0095] Since the short-term token and the long-term token can be used to indicate whether the terminal device or the account logged in on the terminal device has the authority to access the data server, it is convenient to perform subsequent access verification operations.

[0096] Step 1002: Parse the access request to obtain the short-term token and the long-term token.

[0097] Optionally, generally, the short-term token and the long-term token may be stored in the request header information of the access request.

[0098] Then, the operation of parsing the access request can specifically be parsing the request header information of the access request. After parsing the request header information, it can first be determined whether the access request includes both the short-term token and the long-term token. If so, the short-term token and the long-term token are read. If not, it can be directly determined that the terminal device sending the access request failed to pass the verification, and a corresponding prompt message for prompting the user that the access failed can be output, and the process ends. In this way, if the access request does not include both the short-term token and the long-term token, it can be directly determined that the terminal device failed to pass the verification and the process ends. In this way, there is no need to perform subsequent operations, thereby reducing the processing pressure of the authentication server.

[0099] It is worth noting that when the authentication server parses the access request to obtain the short-term token and the long-term token for identity verification, it can only parse and read the request header information of the access request without parsing the entire access request. In this way, the processing pressure of the authentication server can be reduced and the efficiency of access verification can be improved.

[0100] Step 1003: Determine whether the short-term token is valid. If not, determine whether the long-term token is valid based on the long-term token and the valid identity information of the user stored on the authentication server.

[0101] Optionally, since the short-lived token can be encrypted by a digital signature algorithm, the short-lived token can be decrypted by a decryption algorithm corresponding to the digital signature algorithm to determine whether the account information in the short-lived token is verified or valid.

[0102] Specifically, whether the account information in the short-lived token is verified or valid can be determined by checking whether the account information in the short-lived token matches the account that has been successfully logged in.

[0103] For example, the authentication unit in the authentication server may determine whether the short-term token is valid, and the cache unit in the authentication server may also determine whether the long-term token is valid. This embodiment of the present application does not limit this.

[0104] It is worth noting that since the long-term token can be based on the identifier of the account information in the valid identity information, it is possible to determine whether the long-term token is valid by parsing the identifier of the account information in the long-term token and determining whether the identifier of the account information in each valid identity information stored in the authentication server matches the identifier of the account information in the long-term token.

[0105] Generally, if there is a match, it can be determined that the long-term token is valid; otherwise, it can be determined that the long-term token is invalid.

[0106] It is worth noting that since the short-term token is encrypted using a digital signature algorithm and the long-term token is encrypted using an AES algorithm, the short-term token and long-term token sent by the authentication server to the terminal device, or the short-term token and long-term token in the access request, are all encrypted tokens. Therefore, even if other people obtain the short-term token and the long-term token, they cannot decrypt or tamper with them, nor can they obtain the valid identity information recorded in them. This reduces the risk of tampering with the short-term token and the long-term token and improves the security of the valid identity information recorded in them.

[0107] Step 1004: If the long-term token is valid, generate a new short-term token for the terminal device based on the long-term token and send the short-term token to the terminal device, and forward the access request to the data server.

[0108] Optionally, the data server may be the data server C mentioned above.

[0109] Exemplarily, a new short-term token may be generated according to the remaining validity time of the long-term token.

[0110] It is worth noting that when the access request is forwarded to the data server, the data server can parse the access request and read the content information in the access request, and then traverse the various data stored in the data server to determine the data that matches the content information, and send the data that matches the content information to the authentication server.

[0111] After the authentication server receives the data that matches the content information, it can forward the data that matches the content information to the corresponding terminal device. In this way, the terminal device can correctly access the data server when the short-term token and / or long-term token is valid.

[0112] It is worth noting that a new short-term token is generated for the terminal device based on the long-term token and the short-term token is sent to the terminal device. In this way, when the long-term token is valid, it can be ensured that the terminal device can continue to access the data server without the user having to repeatedly enter the login account and password through the terminal device.

[0113] One possible approach is to directly confirm that the terminal device has passed verification if the short-lived token is valid. In this case, the access request can be directly forwarded to the data server. This eliminates the need to verify the validity of the long-lived token, thus reducing the processing pressure on the cache unit in the authentication server.

[0114] In one possible approach, if both the short-lived token and the long-lived token are invalid, the terminal device sending the access request will fail verification, output a corresponding prompt message to inform the user that the access failed, and terminate the process. This prevents terminal devices with invalid short-lived and long-lived tokens from accessing the data server, thereby preventing users without corresponding permissions from accessing data on the data server.

[0115] In an embodiment of the present application, an access request sent by a terminal device is received, the access request is parsed, and the short-term token and the long-term token are obtained. Furthermore, the short-term token and the long-term token can be used to indicate whether the terminal device or the account logged in on the terminal device has permission to access the data server. Furthermore, since the short-term token and the long-term token can be stored in the request header information of the access request, when the authentication server parses the access request to obtain the short-term token and the long-term token for identity verification, it can only parse and read the request header information of the access request, without having to parse the entire access request, to determine whether the terminal device can access the data server. This can reduce the processing pressure on the authentication server and improve the efficiency of access verification.

[0116] Determine whether the short-lived token is valid. If not, determine whether the long-lived token is valid based on the long-lived token and the valid identity information of the user stored on the authentication server. Since both the short-lived token and the long-lived token are encrypted, even if other people obtain the short-lived token and the long-lived token, they cannot decrypt or tamper with them, and thus cannot obtain the valid identity information recorded in them. This reduces the risk of tampering with the short-lived token and the long-lived token, and improves the security of the valid identity information recorded in them.

[0117] When the long-term token is valid, a new short-term token is generated for the terminal device based on the long-term token and the short-term token is sent to the terminal device, and the access request is forwarded to the data server, and the data matching the content information sent by the data server is received, and the data matching the content information is forwarded to the corresponding terminal device. In this way, the terminal device can correctly access the data server when the short-term token and / or long-term token is valid.

[0118] In addition, if both the short-term token and the long-term token are invalid, the terminal device sending the access request will fail the verification, output a corresponding prompt message to inform the user that the access failed, and terminate the process. In this way, terminal devices with invalid short-term tokens and long-term tokens can be prevented from accessing the data server, thereby preventing users without corresponding permissions from obtaining data in the data server.

[0119] If the short-lived token is valid, the terminal device can be directly confirmed to have passed the verification. In this case, the access request can be directly forwarded to the data server. In this way, there is no need to verify the validity of the long-lived token, which can reduce the processing pressure of the cache unit in the authentication server.

[0120] In this way, the access security and the efficiency of access verification can be improved.

[0121] In one possible implementation, see Figure 3 Before receiving the access request sent by the terminal device, the method further includes:

[0122] Step 1005: Receive a login request sent by the terminal device.

[0123] Optionally, the login request includes identity information to be authenticated input by the user on the terminal device.

[0124] Optionally, the identity information to be authenticated includes account information and an identifier of the account information.

[0125] Step 1006: Authenticate the identity information to be authenticated.

[0126] Optionally, the authentication method for the identity information to be authenticated may specifically include: reading the account number and password in the account information, determining an account corresponding to the account in the account information among multiple accounts stored in the authentication server, and determining whether the password of the account corresponding to the account in the account information is the same as the password in the account information; if they are the same, determining that the identity information to be authenticated is authenticated. Otherwise, determining that the identity information to be authenticated is authenticated.

[0127] It is worth noting that if it is determined that the identity information to be authenticated has been authenticated, that is, if the account and password match, it can also be confirmed that the terminal device that sent the identity information to be authenticated can successfully log in. If it is determined that the identity information to be authenticated has not been authenticated, that is, if the account and password do not match, it can also be confirmed that the terminal device that sent the identity information to be authenticated cannot log in. In this way, it can be ensured that only when the correct account and password are entered can the authentication server be logged in or the data server be accessed, thus improving the reliability and security of access verification.

[0128] Step 1007: When the identity information to be authenticated is authenticated successfully, a short-term token and a long-term token are generated according to the identity information to be authenticated, and the short-term token and the long-term token are sent to the terminal device.

[0129] It is worth noting that in this way, a short-term token and a long-term token can be accurately generated based on the identity information to be authenticated entered by the user through the terminal device, and the short-term token and the long-term token will only be generated when the account number and password in the identity information to be authenticated match. Since the short-term token and the long-term token can be used to indicate whether the terminal device or the account logged in on the terminal device has permission to access the data server, it can also ensure that the terminal device can only obtain permission to access the data server when the correct account number and password are entered. In this way, the security of access to the data server can be improved.

[0130] In one possible implementation, see Figure 4 , generating a short-term token and a long-term token based on the identity information to be authenticated, including:

[0131] Step 1008: Generate the short-term token according to the first encryption algorithm and the account information.

[0132] Optionally, the first encryption algorithm may be the above-mentioned digital signature algorithm.

[0133] Specifically, the account information can be encrypted using the first encryption algorithm, and the encrypted string can be used as the short-term token, which is not limited in the embodiment of the present application.

[0134] Step 1009: Generate the long-term token according to the second encryption algorithm, the short-term token and the identifier of the account information.

[0135] Optionally, the second encryption algorithm may be the aforementioned AES algorithm.

[0136] Specifically, the short-term token and the identifier of the account information can be encrypted using the second encryption algorithm, and the encrypted string can be used as the long-term token. This embodiment of the present application does not limit this.

[0137] In this way, the generated short-term token and the long-term token are both encrypted. Therefore, even if other people obtain the short-term token and the long-term token, they cannot decrypt or tamper with them, nor can they obtain the valid identity information recorded in them. This reduces the risk of tampering with the short-term token and the long-term token, and improves the security of the valid identity information recorded in them.

[0138] In one possible implementation, see Figure 5 , generating the short-term token according to the first encryption algorithm and the account information, including:

[0139] Step 1010: Convert the account information into character information.

[0140] Optionally, the account number and password in the account information may be converted into character information through any encoding algorithm or encoder.

[0141] The character information may include multiple characters, and each character may be in the form of numbers, English letters, special symbols, etc.

[0142] In this way, the account information can be converted into multiple disordered and random characters, so that other people can ensure that they cannot restore the account information even if they get the character information.

[0143] Step 1011: Convert the character information into a character string of a preset base.

[0144] Optionally, the preset base may be various bases such as hexadecimal and binary. The preset base may be set according to actual needs, and the embodiments of the present application do not limit this.

[0145] By converting the character information into a string of a preset base, this is equivalent to further encrypting the character information, so that other people cannot restore the account information based on the string.

[0146] Step 1012: Encrypt the character string and the first validity period in the configuration information of the authentication server based on the first encryption algorithm to generate the short-term token.

[0147] Optionally, the configuration information can be set by relevant technical personnel. The configuration information can be used to indicate the request protocols supported by the authentication server, such as HTTP, HTTPS and other protocols. The configuration information can also be used to indicate the validity period or validity duration of the short-term token and the long-term token generated by the authentication server.

[0148] The first validity period can be used to indicate the validity period or validity period of the short-term token. Generally, the value of the first validity period can be adjusted by relevant technical personnel according to actual needs, such as one day, and this embodiment of the application does not limit this.

[0149] Specifically, the character string and the first effective duration can be encrypted using the first encryption algorithm, and the encrypted character string and the encrypted first effective duration can be concatenated as the short-term token, which is not limited in this embodiment of the present application.

[0150] In one possible implementation, see Figure 6 , generating a long-term token according to a second encryption algorithm, the short-term token, and the identifier of the account information, including:

[0151] Step 1013: Concatenate the short-term token and the identifier of the account information to obtain an index identifier.

[0152] Optionally, the index identifier may refer to an identifier of the cache unit, and the index identifier may be used to indicate an association relationship between the account information and the valid identity information.

[0153] In addition, the short-term token can be spliced ​​after the identifier of the account information, or the identifier of the account information can be spliced ​​after the short-term token, or the identifier of the account information can be inserted into the short-term token. This embodiment of the present application does not limit this.

[0154] Step 1014: Encrypt the index identifier based on the second encryption algorithm to obtain the long-term token.

[0155] That is to say, the long-term token only includes the encrypted short-term token and the encrypted identifier of the account information, while the short-term token only includes the account information and the first effective period. Therefore, it can be ensured that the long-term token and the short-term token generated by the authentication server do not include the user name, gender, age, setting content and other information corresponding to the account information entered by the user.

[0156] In this way, the long-term token can be generated, and it can also be ensured that all the user's information will not be sent to the terminal device, which can reduce the risk of all the user's information being leaked, thereby improving the security of access.

[0157] Step 1015: Bind the long-term token to the valid identity information and store the valid identity information.

[0158] Optionally, the valid identity information may be stored in the cache unit.

[0159] It is worth noting that since the long-term token is bound to the valid identity information, when verifying the long-term token, it is possible to match the corresponding valid identity information with the long-term token and determine whether the account information in the matched valid identity information is the same as the account information in the long-term token, and whether the identifier of the account information in the matched valid identity information is the same as the identifier of the account information in the long-term token. In other words, it is possible to determine whether the long-term token is valid in this way.

[0160] Specifically, if the account information and identifier in the matched valid identity information are respectively the same as the account information and identifier of the long-term token, the long-term token is determined to be valid. If the account information or identifier in the matched valid identity information is different from the account information or identifier of the long-term token, or if no valid identity information that matches the long-term token is matched, the long-term token is determined to be invalid.

[0161] In this way, it can also be ensured that the authentication server can accurately and reliably verify whether the long-term token is valid.

[0162] In one possible implementation, see Figure 7 After binding the long-term token to the valid identity information and storing the valid identity information, the method further includes:

[0163] Step 1016: Determine the storage duration of the valid identity information in the authentication server.

[0164] Optionally, the storage duration may be a time length obtained by starting at the time when the valid identity information is stored in the cache unit and ending at the current time.

[0165] In this way, the length of time that the valid identity information is stored in the cache unit of the authentication server can be accurately determined, making it easier to determine whether the long-term token is valid.

[0166] Step 1017: Compare the storage duration with the second validity duration in the configuration information of the authentication server.

[0167] Optionally, the second validity period can be used to indicate the validity period or validity period of the long-term token generated by the authentication server. Generally, the value of the second validity period can be adjusted by relevant technical personnel according to actual needs, such as one week, and this embodiment of the application does not limit this.

[0168] Step 1018: If the storage duration is greater than or equal to the second validity duration, the valid identity information is deleted.

[0169] It is worth noting that after deleting the valid identity information, even if the authentication server receives the long-term token, it cannot determine the valid identity information that matches the long-term token. Therefore, the authentication server can ensure that the long-term token is invalid if the storage duration is greater than or equal to the second validity duration. Since the validity duration of the long-term token is greater than the validity duration of the short-term token, the terminal device can be prevented from accessing the data server if the storage duration is greater than or equal to the second validity duration.

[0170] This can improve access security.

[0171] In one possible implementation, see Figure 8 , determining whether the long-term token is valid based on the long-term token and the valid identity information of the user stored on the authentication server, including:

[0172] Step 1019: Decrypt the long-term token based on the first decryption algorithm to obtain an index identifier, and read the identifier of the account information from the index identifier.

[0173] Optionally, the first decryption algorithm may be a decryption algorithm corresponding to the above-mentioned second encryption algorithm, that is, it may decrypt the long-term token encrypted by the AES encryption algorithm.

[0174] In this way, it is convenient to find the valid identity information that matches the long-term token in the valid identity information stored in the authentication server according to the identifier of the account information.

[0175] Step 1020: Determine whether the identifier of the account information matches the valid identity information of the user. If so, determine that the long-term token is valid.

[0176] In this way, it is possible to accurately determine whether the long-term token is valid.

[0177] Obviously, if the identifier of the account information does not match the valid identity information of the user, the long-term token is determined to be invalid.

[0178] In one possible approach, when it is determined that the long-term token is invalid or the terminal device cannot pass the verification, information can be output to prompt the user to re-enter the above-mentioned login request and re-login, so that the authentication server can regenerate the short-term token and the long-term token and send them to the terminal device.

[0179] In one possible implementation, generating a new short-term token for the terminal device based on the long-term token and sending the short-term token to the terminal device includes:

[0180] The long-term token is decrypted based on the first decryption algorithm to obtain the index identifier, and the short-term token is read from the index identifier.

[0181] It is worth noting that, since the index identifier is generated by concatenating the short-term token and the identifier of the account information, the short-term token can be obtained from the long-term token.

[0182] The short-term token is decrypted based on the second decryption algorithm to obtain a character string and a first validity duration corresponding to the short-term token.

[0183] Optionally, the second decryption algorithm may be a decryption algorithm corresponding to the first encryption algorithm, that is, it may decrypt a short-term token encrypted by a digital signature algorithm.

[0184] A new short-term token is generated according to the current time, the character string and the first validity period, and the new short-term token is sent to the terminal device.

[0185] In this way, a new short-term token with the first validity period can be regenerated, and the starting time of the validity period of the new short-term token is updated to the time when the new short-term token is generated. In this way, it can be ensured that when the long-term token is valid, the new short-term token can be re-sent to the terminal device, that is, the terminal device can be re-authorized to access the data server.

[0186] In one possible approach, after generating a new short-term token based on the current time, the character string, and the first validity duration, the method may further include:

[0187] A new long-term token is regenerated based on the new short-term token and the identifier of the account information, and the new short-term token and the new long-term token are sent to the terminal device.

[0188] The storage duration of the valid identity information corresponding to the new long-term token is reset to zero.

[0189] In this way, after the terminal device accesses the data server, a new long-term token can be resent to the terminal device, thereby granting the terminal device access to the data server. Furthermore, by resetting the storage duration of the valid identity information corresponding to the new long-term token to zero, the validity period or duration of the new long-term token can be updated, eliminating the need for the user to repeatedly enter their login account and password through the terminal device.

[0190] The following describes the apparatus, device, and computer-readable storage medium used to execute the access verification method provided by the present application. The specific implementation process and technical effects are described above and will not be repeated below.

[0191] Figure 9 This is a schematic diagram of the structure of an access verification device provided in an embodiment of the present application, see Figure 9 , the device comprises:

[0192] The receiving module 201 is configured to receive an access request sent by a terminal device, wherein the access request includes a short-term token and a long-term token, wherein the long-term token is generated based on valid identity information of the user;

[0193] Parsing module 202, used to parse the access request to obtain the short-term token and the long-term token;

[0194] Authentication module 203, configured to determine whether the short-lived token is valid, and if not, to determine whether the long-lived token is valid based on the long-lived token and the valid identity information of the user stored on the authentication server;

[0195] The authentication module 204 is further configured to generate a new short-term token for the terminal device based on the long-term token when the long-term token is valid, send the short-term token to the terminal device, and forward the access request to the data server.

[0196] The above-mentioned device is used to execute the method provided in the above-mentioned embodiment. Its implementation principle and technical effect are similar and will not be repeated here.

[0197] The above modules can be one or more integrated circuits configured to implement the above methods, such as one or more application-specific integrated circuits (ASICs), one or more microprocessors, or one or more field programmable gate arrays (FPGAs). For another example, when a module is implemented by scheduling program code through a processing element, the processing element can be a general-purpose processor, such as a central processing unit (CPU) or other processor that can call program code. For another example, these modules can be integrated together and implemented in the form of a system-on-a-chip (SOC).

[0198] Figure 10 This is a schematic diagram of the structure of a computer device provided in an embodiment of the present application. Figure 10 The computer device includes: a memory 301 and a processor 302. The memory 301 stores a computer program that can be run on the processor 302. When the processor 302 executes the computer program, the steps in any of the above method embodiments are implemented.

[0199] An embodiment of the present application further provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, the steps in the above-mentioned method embodiments can be implemented.

[0200] Optionally, the present application also provides a program product, such as a computer-readable storage medium, comprising a program, which is used to execute any of the above-mentioned access verification method embodiments when executed by a processor.

[0201] In the several embodiments provided by the present invention, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed can be through some interface, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0202] Units described as separate components may or may not be physically separate, and components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0203] In addition, the functional units in various embodiments of the present invention may be integrated into a single processing unit, each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or hardware plus software functional units.

[0204] The above-mentioned integrated unit implemented in the form of a software functional unit can be stored in a computer-readable storage medium. The above-mentioned software functional unit is stored in a storage medium and includes a number of instructions for causing a computer device (which can be a personal computer, server, or network device, etc.) or a processor (English: processor) to perform some steps of the methods of various embodiments of the present invention. The aforementioned storage medium includes: a USB flash drive, a mobile hard disk, a read-only memory (English: Read-Only Memory, abbreviated: ROM), a random access memory (English: Random Access Memory, abbreviated: RAM), a magnetic disk or an optical disk, and other media that can store program code.

[0205] The above are only specific embodiments of the present application, but the scope of protection of this application is not limited to them. Any changes or substitutions that can be easily conceived by any person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

[0206] The above description is merely a preferred embodiment of the present application and is not intended to limit the present application. Various modifications and variations are possible for those skilled in the art. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of the present application shall be included within the scope of protection of the present application.

Claims

1. An access verification method, characterized in that: Applied to an authentication server in an Internet of Things access system, the method includes: Receiving an access request sent by a terminal device, the access request including: a short-term token and a long-term token, the long-term token being generated based on valid identity information of the user; Parsing the access request to obtain the short-term token and the long-term token; Determining whether the short-term token is valid, and if not, determining whether the long-term token is valid based on the long-term token and the valid identity information of the user stored on the authentication server; If the long-term token is valid, generating a new short-term token for the terminal device according to the long-term token and sending the new short-term token to the terminal device, and forwarding the access request to the data server; Generating a new short-term token for the terminal device according to the long-term token and sending the new short-term token to the terminal device includes: Decrypting the long-term token based on a first decryption algorithm to obtain an index identifier, and reading the short-term token from the index identifier; Decrypt the short-term token based on a second decryption algorithm to obtain a character string and a first validity period corresponding to the short-term token; A new short-term token is generated according to the current time, the character string and the first validity period, and the new short-term token is sent to the terminal device.

2. The access verification method according to claim 1, wherein: Before receiving the access request sent by the terminal device, the method further includes: receiving a login request sent by the terminal device, wherein the login request includes identity information to be authenticated input by the user on the terminal device; authenticating the identity information to be authenticated; When the identity information to be authenticated is authenticated successfully, a short-term token and a long-term token are generated according to the identity information to be authenticated, and the short-term token and the long-term token are sent to the terminal device.

3. The access verification method according to claim 2, wherein: The identity information to be authenticated includes account information and an identifier of the account information; The generating of a short-term token and a long-term token according to the identity information to be authenticated includes: Generate the short-term token according to the first encryption algorithm and the account information; The long-term token is generated according to a second encryption algorithm, the short-term token and an identifier of the account information.

4. The access verification method according to claim 3, wherein: Generating the short-term token according to the first encryption algorithm and the account information includes: Converting the account information into character information; Convert the character information into a character string of a preset base; The character string and the first validity duration in the configuration information of the authentication server are encrypted based on the first encryption algorithm to generate the short-term token.

5. The access verification method according to claim 3, wherein: Generating a long-term token according to the second encryption algorithm, the short-term token, and the identifier of the account information includes: Concatenate the short-lived token and the identifier of the account information to obtain an index identifier; Encrypting the index identifier based on the second encryption algorithm to obtain the long-term token; The long-term token is bound to the valid identity information, and the valid identity information is stored.

6. The access verification method according to claim 5, wherein: After binding the long-term token to the valid identity information and storing the valid identity information, the method further includes: Determining a storage period for the valid identity information to be stored in the authentication server; Comparing the storage duration with a second validity duration in the configuration information of the authentication server; If the storage duration is greater than or equal to the second validity duration, the valid identity information is deleted.

7. The access verification method according to any one of claims 1 to 6, wherein: The determining whether the long-term token is valid according to the long-term token and the valid identity information of the user stored on the authentication server includes: Decrypting the long-term token based on a first decryption algorithm to obtain an index identifier, and reading an identifier of the account information from the index identifier; Determine whether the identifier of the account information matches the valid identity information of the user, and if so, determine that the long-term token is valid.

8. An access verification device, characterized in that: An authentication server used in an Internet of Things access system, the device comprising: A receiving module, configured to receive an access request sent by a terminal device, wherein the access request includes: a short-term token and a long-term token, wherein the long-term token is generated based on valid identity information of the user; A parsing module, configured to parse the access request to obtain the short-term token and the long-term token; an authentication module, configured to determine whether the short-term token is valid, and if not, to determine whether the long-term token is valid based on the long-term token and the valid identity information of the user stored on the authentication server; The authentication module is further configured to, when the long-term token is valid, generate a new short-term token for the terminal device based on the long-term token, send the new short-term token to the terminal device, and forward the access request to the data server; The authentication module is specifically used to decrypt the long-term token based on a first decryption algorithm to obtain an index identifier, and read the short-term token from the index identifier; decrypt the short-term token based on a second decryption algorithm to obtain the character string and the first effective duration corresponding to the short-term token; generate a new short-term token based on the current time, the character string and the first effective duration, and send the new short-term token to the terminal device.

9. A computer device, characterized in that: include: A memory and a processor, wherein the memory stores a computer program that can be run on the processor, and when the processor executes the computer program, the steps of the method described in any one of claims 1 to 7 are implemented.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, which, when executed by a processor, implements the steps of the method according to any one of claims 1 to 7.

Images