Resource access method and device, electronic device, and computer-readable storage medium

Abstract

The embodiment of the present application discloses a resource access method and device, an electronic device, and a computer-readable storage medium, the method comprising: receiving a resource access request sent by a client, wherein the resource access request carries a JWT token, the JWT token includes user login related information and a first salt value information, then, performing a salt value calculation on the user login related information according to a preset salt value encryption algorithm to obtain a second salt value information, then, verifying the first salt value information according to the second salt value information, if the verification passes, determining that the JWT token is legal, and returning the resource data corresponding to the resource access request to the client. The technical solution of the embodiment of the present application greatly optimizes the resource access solution.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a resource access method, a resource access device, an electronic device, and a computer-readable storage medium. Background Art

[0002] In the prior art, when the client requests to access resources from the server, it carries a JWT (json web token) token, and the server verifies the legitimacy of the JWT token through a pre-stored key; however, once the key is leaked by an attack, the attacker can modify the JWT token to generate a forged JWT token. At this time, the server cannot identify the legitimacy of the JWT token and will return the resource data to the client. It can be seen that the security of resource data access in the prior art is low.

[0003] Therefore, how to improve the security of resource data access is an urgent problem to be solved. Summary of the invention

[0004] To solve the above technical problems, the embodiments of the present application provide a resource access method and device, an electronic device, and a computer-readable storage medium, thereby improving the security of resource data access at least to a certain extent.

[0005] According to one aspect of an embodiment of the present application, a resource access method is provided, which is applied to a server, and the method includes: receiving a resource access request sent by a client; wherein the resource access request carries a JWT token, and the JWT token includes user login related information and first salt value information; performing a salt value calculation on the user login related information according to a preset salt value encryption algorithm to obtain second salt value information; verifying the first salt value information according to the second salt value information; if the verification passes, determining that the JWT token is legal, and returning resource data corresponding to the resource access request to the client.

[0006] According to one aspect of an embodiment of the present application, a resource access device is provided, which is configured on a server side, and the device includes: a receiving module, configured to receive a resource access request sent by a client; wherein the resource access request carries a JWT token, and the JWT token includes user login related information and first salt value information; a generating module, configured to perform a salt value calculation on the user login related information according to a preset salt value encryption algorithm to obtain second salt value information; a verifying module, configured to verify the first salt value information according to the second salt value information; and a sending module, configured to determine that the JWT token is legal if the verification passes, and return the resource data corresponding to the resource access request to the client.

[0007] In one embodiment of the present application, based on the aforementioned scheme, the device also includes: a salt value calculation module, configured to perform salt value calculation on the user login related information corresponding to the client according to the preset salt value encryption algorithm to obtain the first salt value information; the generation module is also configured to generate the JWT token according to the first salt value information; the sending module is also configured to send the JWT token to the client.

[0008] In one embodiment of the present application, based on the aforementioned scheme, the JWT token includes a JWT field, and the JWT field stores the user login related information; the generation module includes: a first storage unit, configured to store the first salt value information in the JWT field, and obtain a JWT field storing the first salt value information; a second storage unit, configured to encrypt the user login related information obtained from the JWT field according to a key, generate signature information, and store the signature information in the JWT field, and obtain a JWT field storing the signature information; a generation unit, configured to integrate the JWT field storing the first salt value information and the JWT field storing the signature information to generate the JWT token.

[0009] In one embodiment of the present application, based on the aforementioned scheme, the JWT field includes a header field, a body field and a signature field; the first storage unit is specifically configured to segment the first salt value information to obtain multiple sub-salt value information, and store each sub-salt value information in the header field and / or the body field respectively.

[0010] In one embodiment of the present application, based on the aforementioned scheme, the JWT field includes a header field, a body field and a signature field; the second storage unit is specifically configured to encrypt the user login-related information obtained from the body field according to the key, generate the signature information, and store the signature information in the signature field.

[0011] In one embodiment of the present application, based on the aforementioned scheme, the device also includes: the receiving module, which is also configured to receive a login request sent by the client; wherein the login request carries user account information and password information; a verification module, which is configured to perform identity verification on the user based on the user account information and the password information; and an acquisition module, which is configured to allow the client to log in if the verification passes, and obtain the user login related information corresponding to the client.

[0012] In one embodiment of the present application, based on the aforementioned scheme, the JWT token includes a JWT field, and the first salt value information is segmented into multiple sub-salt value information and stored in the JWT field; the verification module includes: a combination unit, configured to obtain multiple sub-salt value information from the JWT field, and combine each sub-salt value information to obtain the first salt value information; a verification unit, configured to verify the first salt value information according to the second salt value information.

[0013] In one embodiment of the present application, based on the aforementioned scheme, the device also includes: a decoding module, configured to decode the JWT token to obtain a JWT field; a decryption module, configured to decrypt the signature information contained in the JWT field according to a key to obtain decrypted user login related information; a matching module, configured to match the decrypted user login related information with the user login related information contained in the decoded JWT field; an execution module, configured to execute the step of verifying the first salt value information according to the second salt value information if the match is successful; a determination module, configured to determine that the JWT token is illegal if the match fails.

[0014] According to one aspect of an embodiment of the present application, there is provided an electronic device, comprising: one or more processors; a storage device for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the electronic device implements the resource access method as described above.

[0015] According to one aspect of an embodiment of the present application, a computer-readable storage medium is provided, on which computer-readable instructions are stored. When the computer-readable instructions are executed by a processor of a computer, the computer executes the resource access method as described above.

[0016] According to one aspect of an embodiment of the present application, a computer program product is provided, including computer instructions, which implement the resource access method as described above when executed by a processor.

[0017] In the technical solution provided in the embodiment of the present application, when the client requests access to resources from the server, the resource access request carries a JWT token, and the JWT token includes user login related information and a first salt value information; therefore, the server can generate a second salt value information based on the user login related information contained in the JWT token, and use the generated second salt value information to verify the first salt value information contained in the JWT token. If the verification passes, it indicates that the JWT token is legal, and the resource data corresponding to the resource access request can be returned to the client. In this way, the legitimacy of the JWT token can be determined simply and quickly, avoiding the problem of low security of resource data access due to key leakage, and greatly improving the security of resource data access.

[0018] It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] The drawings herein are incorporated into the specification and constitute a part of the specification, showing embodiments consistent with the present application, and together with the specification, are used to explain the principles of the present application. Obviously, the drawings described below are only some embodiments of the present application, and for those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative work. In the drawings:

[0020] Figure 1 is a schematic diagram of an exemplary implementation environment to which the technical solution of the embodiments of the present application can be applied;

[0021] Figure 2 is a flow chart of a resource access method shown in an exemplary embodiment of the present application;

[0022] Figure 3 is a flow chart of a resource access method shown in an exemplary embodiment of the present application;

[0023] Figure 4 is a flow chart of a resource access method shown in an exemplary embodiment of the present application;

[0024] Figure 5 yes Figure 3 A flowchart of step S320 in the illustrated embodiment in an exemplary embodiment;

[0025] Figure 6 is a schematic diagram of a JWT field shown in an exemplary embodiment of the present application;

[0026] Figure 7 yes Figure 5 A flowchart of step S510 in the illustrated embodiment in an exemplary embodiment;

[0027] Figure 8 yes Figure 5 A flowchart of step S520 in the illustrated embodiment in an exemplary embodiment;

[0028] Fig. 9 yes Figure 2 A flowchart of step S230 in the illustrated embodiment in an exemplary embodiment;

[0029] Fig.10 is a flow chart of a resource access method shown in an exemplary embodiment of the present application;

[0030] Fig.11 is a flow chart of a resource access method shown in an exemplary embodiment of the present application;

[0031] Fig.12 is a flow chart of a resource access method shown in an exemplary embodiment of the present application;

[0032] Fig.13 is a flow chart of a resource access method shown in an exemplary embodiment of the present application;

[0033] Fig.14 is a schematic diagram of the structure of a resource access device shown in an exemplary embodiment of the present application;

[0034] Fig.15 It is a structural diagram of a computer system suitable for implementing an electronic device of an embodiment of the present application. DETAILED DESCRIPTION

[0035] Here, exemplary embodiments will be described in detail, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The implementations described in the following exemplary embodiments do not represent all implementations consistent with the present application. Instead, they are only examples of devices and methods consistent with some aspects of the present application as detailed in the attached claims.

[0036] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities may be implemented in software form, or in one or more hardware modules or integrated circuits, or in different networks and / or processor devices and / or microcontroller devices.

[0037] The flowcharts shown in the accompanying drawings are only exemplary and do not necessarily include all the contents and operations / steps, nor must they be executed in the order described. For example, some operations / steps can be decomposed, and some operations / steps can be combined or partially combined, so the actual execution order may change according to actual conditions.

[0038] It should also be noted that the "multiple" mentioned in this application refers to two or more than two. "And / or" describes the association relationship of the associated objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. The character " / " generally indicates that the previous and next associated objects are in an "or" relationship.

[0039] In the prior art, when the client requests access to resources from the server, it carries the JWT token, and the server verifies the legitimacy of the JWT token using a pre-stored key. However, once the key is leaked by an attacker, the attacker can modify the JWT token to generate a forged JWT token. At this time, the server cannot identify the legitimacy of the JWT token and will return the resource data to the client. It can be seen that the security of resource data access in the prior art is low.

[0040] In this regard, the related technologies have adopted methods such as adding identification fields, shortening the expiration time of JWT tokens, and combining server-side storage of tokens for double verification to defend against JWT token cracking attacks. Among them, adding identification fields will increase the number of JWT fields corresponding to the JWT token, which is more complex; shortening the expiration time of the JWT token will increase the calls to the refresh token interface, so that the client needs to log in again in a short time, and the user experience satisfaction is low; for double verification, it is necessary to store the mapping relationship between token and JWT on the server side, which occupies the storage space of the server side, and a mapping relationship between token and JWT will be stored for each client, which puts more pressure on the server side. It can be seen that there is no good solution for resource data access in the related technologies.

[0041] Based on this, the embodiments of the present application provide a resource access method and device, an electronic device, and a computer-readable storage medium, which can improve the security of resource data access and optimize resource data access solutions.

[0042] See also Figure 1 , Figure 1 1 is a schematic diagram of an exemplary implementation environment of the present application, wherein the implementation environment includes a terminal device 110 and a server 120, and the terminal device 110 and the server 120 communicate with each other via a wired or wireless network.

[0043] It should be understood that Figure 1The number of terminal devices 110 and servers 120 in the embodiment is only for illustration. Any number of terminal devices 110 and servers 120 may be provided according to actual needs.

[0044] Among them, the terminal device 110 corresponds to the client, which can be any electronic device with a user input interface, including but not limited to smart phones, tablets, laptops, computers, etc., wherein the user input interface includes but is not limited to touch screens, keyboards, physical buttons, audio pickup devices, etc.

[0045] Among them, server 120 corresponds to the service end, which can be a server that provides various services. It can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers. It can also be a cloud server that provides cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN (Content Delivery Network) and basic cloud computing services such as big data and artificial intelligence platforms. This is not restricted here.

[0046] In some embodiments of the present application, the resource access method may be executed by the server 120, and accordingly, the resource access device is configured in the server 120. The server 120 may obtain the resource access request sent by the terminal device 110, wherein the resource access request carries a JWT token, and the JWT token includes user login related information and first salt value information; then, the user login related information is subjected to salt value calculation according to a preset salt value encryption algorithm to obtain second salt value information; then, the first salt value information is verified according to the second salt value information, and if the verification passes, it is determined that the JWT token is legal, and the resource data corresponding to the resource access request is returned to the terminal device 110.

[0047] The following is a detailed description of various implementation details of the technical solution of the embodiment of the present application:

[0048] See also Figure 2 , Figure 2 is a flowchart of a resource access method shown in an embodiment of the present application. The method can be applied to Figure 1 In the implementation environment shown, and by Figure 1 The server 120 in the implementation environment shown is executed. Figure 2 As shown, the resource access method at least includes steps S210 to S230, which are described in detail as follows:

[0049] Step S210, receiving a resource access request sent by a client; wherein the resource access request carries a JWT token, and the JWT token includes user login related information and first salt value information.

[0050] In the embodiment of the present application, a resource access request refers to a request initiated by the client to obtain resource data when the client needs to access resource data in the server. In this way, the server can determine whether the client has a need to access resources based on the resource access request. At this time, it is necessary to verify the legitimacy of the JWT token carried in the resource access request and determine whether to return the resource data to the client based on the verification result.

[0051] The JWT token carried in the resource access request in the embodiment of the present application is the JWT token to be verified for legitimacy. The JWT token includes user login related information and the first salt value information, where:

[0052] User login related information refers to a series of related information about the user login, where the user login related information includes but is not limited to the user name, user password, user login time, the time when the JWT token is created based on the user login time, the set JWT token expiration time, etc.

[0053] The first salt value information refers to the salt value obtained by the server side through salt value calculation of the user login related information according to the preset salt value encryption algorithm. The second salt value information mentioned later also refers to the salt value obtained by the server side through salt value calculation of the user login related information according to the preset salt value encryption algorithm. The difference between the two is that the first salt value information is obtained by the server side through salt value calculation of the user login related information obtained when the user logs in, and the JWT token is generated according to the first salt value information and sent to the client to serve as the identity credential for the client to request access to resources; and the second salt value information is obtained by the server side through salt value calculation based on the user login related information contained in the JWT token carried by the resource access request when the server side receives the resource access request sent by the client, so as to verify the legitimacy of the JWT token.

[0054] In one embodiment of the present application, see Figure 3 Before the process of receiving the resource access request sent by the client in step S210, steps S310 to S330 may also be included, which are described in detail as follows:

[0055] Step S310, calculating the salt value of the user login related information corresponding to the client according to a preset salt value encryption algorithm to obtain first salt value information;

[0056] Step S320, generating a JWT token according to the first salt value information;

[0057] Step S330, sending the JWT token to the client.

[0058] That is, in an optional embodiment, the server calculates the salt value of the user login-related information corresponding to the client according to a preset salt value encryption algorithm to obtain the first salt value information, and then generates a JWT token based on the first salt value information. Then, the generated JWT token is sent to the client, so that the client carries the JWT token as an identity credential when making subsequent requests to access resources.

[0059] Among them, the preset salt value encryption algorithm in the optional embodiment includes but is not limited to the salted MD (Message Digest Algorithm) series algorithm, the salted SHA (Secure Hash Algorithm) series algorithm and the salted PBKDF (Password-Based Key Derivation Function) series algorithm; among them, the salted MD series algorithm has low security, the salted SHA series algorithm has moderate security, and the salted PBKDF series algorithm has high security. In practical applications, the preset salt value encryption algorithm can be selected according to the specific application scenario; for example, in a scenario with low security requirements, the salted MD series algorithm can be used, and correspondingly, in a scenario with moderate security requirements, the salted SHA series algorithm can be used, and correspondingly, in a scenario with high security requirements, the salted PBKDF series algorithm can be used.

[0060] It is understandable that, since different clients have different user login related information, the first salt value information obtained by performing salt value calculation on the user login related information corresponding to the client according to the preset salt value encryption algorithm is different. For example, please refer to Table 1 below, which is an exemplary server generating different first salt value information for different clients.

[0061] User login information corresponding to the client First salt value information User login related information A1 of client 1 K1 User login related information A2 of client 2 K2 User login related information A3 of client 3 K3 …… ……

[0062] Table 1

[0063] It is understandable that since the user corresponding to the same client logs in at different times, the generated user login related information may be different; for example, when the user login related information includes the user login time and the time to create the JWT token according to the user login time, the generated user login related information is different, and at this time, the first salt value information obtained by calculating the salt value of the user login related information corresponding to the client according to the preset salt value encryption algorithm is also different. For example, please refer to Table 2 below, which is an exemplary server that generates different first salt value information for the same client.

[0064] User login information corresponding to client 1 First salt value information User login related information A11 K11 User login related information A12 K12 User login related information A13 K13 …… ……

[0065] Table 2

[0066] In one embodiment of the present application, see Figure 4 In step S310, before the process of calculating the salt value of the user login related information corresponding to the client according to the preset salt value encryption algorithm to obtain the first salt value information, steps S410 to S430 may also be included, which are described in detail as follows:

[0067] Step S410, receiving a login request sent by a client; wherein the login request carries user account information and password information;

[0068] Step S420, verifying the user's identity based on the user account information and password information;

[0069] Step S430: If the verification is passed, the client is allowed to log in, and the user login related information corresponding to the client is obtained.

[0070] That is, in an optional embodiment, when the client receives a login operation performed by a user, a login request is generated and sent to the server. Accordingly, the server receives the login request sent by the client and performs identity verification on the user according to the user account information and password information carried in the login request. If the verification passes, the client is allowed to log in, and the user login related information corresponding to the client is obtained, so that the salt value of the user login related information corresponding to the client can be calculated according to the preset salt value encryption algorithm to obtain the first salt value information; if the verification fails, a message indicating that the verification failed can be sent to the client, so that the user can re-execute the login operation according to the verification failed information.

[0071] In one embodiment of the present application, the JWT token includes a JWT field, in which user login related information is stored; see Figure 5 The process of generating a JWT token according to the first salt value information in step S320 may include steps S510 to S530, which are described in detail as follows:

[0072] Step S510, storing the first salt value information in the JWT field, and obtaining the JWT field storing the first salt value information;

[0073] Step S520, encrypting the user login related information obtained from the JWT field according to the key, generating signature information, and storing the signature information in the JWT field, thereby obtaining a JWT field storing the signature information;

[0074] Step S530: Integrate the JWT field storing the first salt value information and the JWT field storing the signature information to generate a JWT token.

[0075] That is, in an optional embodiment, the server stores the first salt value information in the JWT field to obtain a JWT field storing the first salt value information, and then encrypts the user login-related information obtained from the JWT field according to the key to generate signature information, and stores the signature information in the JWT field to obtain a JWT field storing the signature information, and then integrates the JWT field storing the first salt value information and the JWT field storing the signature information to generate a JWT token.

[0076] In one embodiment of the present application, see Figure 6 , is an exemplary JWT field; Figure 6 As shown, the JWT field includes a header field, a body field, and a signature field. Among them, the header field usually stores information such as the token type and the encryption algorithm used; the body field is also called the payload field, which usually stores valid information of the JWT token such as user login related information; the signature field usually stores the encrypted signature of the JWT token, specifically, the valid information of the JWT token stored in the body field is encrypted by a key to generate signature information and store it, so as to prevent the information included in the JWT token from being tampered with.

[0077] In one embodiment of the present application, see Figure 7 The process of storing the first salt value information in the JWT field in step S510 may include steps S710 to S720, which are described in detail as follows:

[0078] Step S710, segmenting the first salt value information to obtain a plurality of sub-salt value information;

[0079] Step S720: Store each sub-salt value information in the header field and / or the body field respectively.

[0080] That is, in an optional embodiment, the server segmented the first salt value information to obtain a plurality of sub-salt value information, and then stored each sub-salt value information in the header field and / or the body field respectively.

[0081] Among them, in an optional embodiment, all sub-salt value information can be stored in the header field; for example, the first salt value information is segmented to obtain 10 sub-salt value information, and the 10 sub-salt value information are stored in the header field according to a preset salt value adding algorithm.

[0082] Among them, in an optional embodiment, all sub-salt value information can be stored in the main field; for example, the first salt value information is segmented to obtain 10 sub-salt value information, and the 10 sub-salt value information are stored in the main field according to a preset salt value addition algorithm.

[0083] Among them, in an optional embodiment, part of the sub-salt value information can be stored in the header field, and part of the sub-salt value information can be stored in the body field; for example, the first salt value information is segmented to obtain 10 sub-salt value information, 5 of which are stored in the header field according to a preset salt value addition algorithm, and the other 5 sub-salt value information are stored in the body field according to a preset salt value addition algorithm.

[0084] It is understandable that the preset salt value adding algorithm in the optional embodiment can be flexibly adjusted according to the specific application scenario, and the present invention does not make any specific limitation to this.

[0085] In this way, segmenting the salt value information and storing it in the JWT field using a preset salt value addition algorithm can greatly improve the security of the JWT token. Because if an attacker wants to forge a JWT token, he or she must forge the first salt value information, and the forged first salt value information needs to be correctly segmented and correctly stored in the JWT field, which greatly increases the difficulty of forging the JWT token and can effectively defend against cracking attacks on the JWT token.

[0086] In one embodiment of the present application, see Figure 8 In step S520, the process of encrypting the user login related information obtained from the JWT field according to the key, generating signature information, and storing the signature information in the JWT field may include steps S810 to S820, which are described in detail as follows:

[0087] Step S810, encrypting the user login related information obtained from the subject field according to the key to generate signature information;

[0088] Step S820: Store the signature information in the signature field.

[0089] That is, in an optional embodiment, the server encrypts the user login related information obtained in the subject field according to the key to generate signature information, and then stores the signature information in the signature field.

[0090] Among them, the key in the optional embodiment is stored on the server side, and the key is used to encrypt the user login related information obtained from the subject field to generate signature information.

[0091] Step S220: Calculate the salt value of the user login related information according to a preset salt value encryption algorithm to obtain second salt value information.

[0092] In the embodiment of the present application, after the server receives the resource access request sent by the client, it is necessary to calculate the salt value of the user login related information according to the preset salt value encryption algorithm to obtain the second salt value information.

[0093] It can be understood that the preset salt value encryption algorithm used for the second salt value information obtained by calculating the salt value of the user login related information is the same as the preset salt value encryption algorithm used for the first salt value information obtained by calculating the salt value of the user login related information; in this way, as long as the user login related information does not change, the first salt value information contained in the JWT token must be the same as the newly generated second salt value information, and therefore, the first salt value information can be verified by the second salt value information.

[0094] Step S230: verify the first salt value information according to the second salt value information.

[0095] In the embodiment of the present application, a salt value is calculated for user login related information according to a preset salt value encryption algorithm. After obtaining the second salt value information, the first salt value information needs to be verified according to the second salt value information.

[0096] It is understandable that the JWT token includes a JWT field, and the first salt value information is segmented into multiple sub-salt value information and stored in the JWT field. Optionally, the JWT field includes a header field, a body field, and a signature field. The server stores each sub-salt value information in the header field and / or the body field according to a preset salt value addition algorithm. Please refer to the above introduction for details.

[0097] In one embodiment of the present application, see Fig. 9 The process of verifying the first salt value information according to the second salt value information in step S230 may include steps S910 to S920, which are described in detail as follows:

[0098] Step S910, obtaining multiple sub-salt value information from the JWT field, and combining each sub-salt value information to obtain first salt value information;

[0099] Step S920: verify the first salt value information according to the second salt value information.

[0100] That is, in an optional embodiment, the server obtains multiple sub-salt value information from the JWT field, and combines the sub-salt value information to obtain the first salt value information, and then verifies the first salt value information according to the second salt value information.

[0101] It can be understood that the first salt value information is verified according to the second salt value information, and specifically, it can be determined whether the second salt value information is the same as the first salt value information. If the second salt value information is the same as the first salt value information, it indicates that the user login related information has not changed (that is, the user login related information has not been tampered with), and the verification is passed at this time; if the second salt value information is different from the first salt value information, it indicates that the user login related information has changed (that is, the user login related information has been tampered with), and the verification fails at this time.

[0102] In one embodiment of the present application, see Fig.10 Before the process of verifying the first salt value information according to the second salt value information in step S230, steps S1010 to S1050 may also be included, which are described in detail as follows:

[0103] Step S1010, decode the JWT token to obtain the JWT field;

[0104] Step S1020, decrypting the signature information contained in the JWT field according to the key to obtain decrypted user login related information;

[0105] Step S1030, matching the decrypted user login related information with the user login related information contained in the decoded JWT field;

[0106] Step S1040, if the match is successful, then executing the step of verifying the first salt value information according to the second salt value information;

[0107] Step S1050: If the match fails, it is determined that the JWT token is illegal.

[0108] That is, in an optional embodiment, the server can first decode the JWT token to obtain the JWT field, and then decrypt the signature information contained in the JWT field according to the key to obtain the decrypted user login related information, and then match the decrypted user login related information with the user login related information contained in the decoded JWT field.

[0109] Among them, in the optional embodiment, part of the information stored in the JWT field is simply encoded, and part is encrypted; for example, the JWT field includes a header field, a body field, and a signature field, wherein the information stored in the header field and the body field is simply encoded information, and the information stored in the signature field is generated after encryption by a key, that is, part of the information is public and can be obtained, and part of the information is undisclosed and cannot be obtained. Therefore, the server decodes the JWT token and can obtain plaintext (that is, information that can be obtained after decoding) and ciphertext (that is, information that needs to be further decrypted after decoding), wherein the plaintext includes user login related information, and the ciphertext also includes user login related information.

[0110] It can be understood that the decrypted user login related information and the user login related information contained in the decoded JWT field are matched, and specifically, it can be determined whether the decrypted user login related information and the user login related information contained in the decoded JWT field are the same. Among them, if they are the same, it means that the first step of verification has passed, but at this time it cannot be determined whether the key has been leaked. Therefore, it is necessary to perform the step of verifying the first salt value information according to the second salt value information to perform the second step of verification to determine whether the JWT token is legal; if they are not the same, it means that the first step of verification has not passed, that is, the key has not been leaked, and at this time it can be directly determined that the JWT token is illegal.

[0111] In this way, when the decrypted user login related information and the decoded user login related information contained in the JWT field do not match, the first salt value information is verified according to the second salt value information to determine whether the JWT token is legal. This can save system resources to a certain extent and improve the efficiency of determining the legality of the JWT token.

[0112] In one embodiment of the present application, a verification JWT token may also be generated based on the second salt value information. The specific generation process is similar to the process of generating the JWT token based on the first salt value information, and will not be repeated here.

[0113] Step S240: If the verification passes, the JWT token is determined to be legal, and the resource data corresponding to the resource access request is returned to the client.

[0114] In the embodiment of the present application, the first salt value information is verified according to the second salt value information. If the verification passes, it can be determined that the JWT token is legal. Therefore, the resource data corresponding to the resource access request can be returned to the client.

[0115] In the embodiment of the present application, when the client requests access to resources from the server, the resource access request carries a JWT token, and the JWT token includes user login related information and a first salt value information; therefore, the server can generate a second salt value information based on the user login related information contained in the JWT token, and use the generated second salt value information to verify the first salt value information contained in the JWT token. If the verification passes, it indicates that the JWT token is legal, and the resource data corresponding to the resource access request can be returned to the client. In this way, the legitimacy of the JWT token can be determined simply and quickly, and in the process of determining the legitimacy of the JWT token, there is no need to add an identification field, and the user experience will not be reduced. The pressure on the server is also small, and it is simple and easy to implement, which greatly improves the security of resource data access and optimizes the resource data access scheme.

[0116] The specific application scenarios of the embodiments of the present application are described in detail below:

[0117] See also Fig.11 , Fig.11 FIG. 1 is a flow chart of a resource access method according to an embodiment of the present application. Fig.11 As shown, the resource access method at least includes steps S1110 to S1140, which are described in detail as follows:

[0118] Step S1110, the client sends a login request to the server; wherein the login request carries user account information and password information.

[0119] In step S1120, the server verifies the identity of the user based on the user account information and password information, and after the verification is passed, calculates the salt value of the user login-related information according to the preset salt value encryption algorithm to obtain the first salt value information, and generates a JWT token based on the first salt value information, and sends the JWT token to the client.

[0120] Step S1130, the client sends a resource access request to the server; wherein the resource access request carries a JWT token, and the JWT token includes user login related information and a first salt value information.

[0121] In step S1140, the server calculates the salt value of the user login related information according to the preset salt value encryption algorithm to obtain the second salt value information, and verifies the first salt value information according to the second salt value information. If the verification passes, it is determined that the JWT token is legal, and the resource data corresponding to the resource access request is sent to the client.

[0122] Understandably, Fig.11 This is an exemplary description in combination with two ends; optionally, the specific implementation process of steps S1110 to S1140 can refer to the technical solutions of the aforementioned embodiments.

[0123] See also Fig.12 , Fig.12 FIG. 1 is a flow chart of a resource access method according to an embodiment of the present application. Fig.12 As shown, the resource access method at least includes steps S1210 to S1270, which are described in detail as follows:

[0124] Step S1210: The user account and user password input by the user are received in the login interface displayed by the client.

[0125] In step S1220, the server determines whether the user account and user password are correct; if the user account is incorrect, execute step S1230; if the user password is incorrect, execute step S1240; if both are correct, execute step S1250.

[0126] The client sends the received user account and password to the server, which determines whether the user account and password are correct.

[0127] Step S1230: The client prompts the user that the account is incorrect.

[0128] If the server determines that the user account is incorrect, it returns the user account error information to the client, so that the client displays the user account error information, and the user can re-enter the user account.

[0129] Step S1240: The client prompts the user that the password is incorrect.

[0130] If the server determines that the user password is incorrect, it returns the user password error information to the client, so that the client displays the user password error information, and the user can re-enter the user password.

[0131] Step S1250: The server calculates the salt value of the user login related information corresponding to the client according to a preset salt value encryption algorithm to obtain first salt value information.

[0132] Among them, user login related information includes user name, user password, user login time, time when the JWT token is created based on the user login time, and the set JWT token expiration time.

[0133] Step S1260, segment the first salt value information to obtain multiple sub-salt value information, and store each sub-salt value information in a JWT field to generate a JWT token.

[0134] Step S1270, the server sends the JWT token to the client.

[0135] At this point, the process of generating the JWT token is completed; optionally, the specific implementation process of steps S1210 to S1270 can refer to the technical solution of the aforementioned embodiment.

[0136] See also Fig.13 , Fig.13 FIG. 1 is a flow chart of a resource access method according to an embodiment of the present application. Fig.13 As shown, the resource access method at least includes steps S1310 to S1390, which are described in detail as follows:

[0137] Step S1310, the client receives the resource request operation input by the user and generates a resource access request; wherein the resource access request carries a JWT token, the JWT token includes user login related information and the first salt value information, and sends the resource access request to the server.

[0138] The JWT token carried in the resource access request can be Fig.12 The JWT token generated in .

[0139] Step S1320, the server decodes the JWT token to obtain the JWT field.

[0140] In step S1330, the server decrypts the signature information contained in the JWT field according to the key to obtain the decrypted user login related information.

[0141] In step S1340, the server matches the decrypted user login related information with the user login related information contained in the decoded JWT field; if the match is successful, step S1350 is executed; if the match fails, step S1390 is executed.

[0142] Step S1350: The server calculates the salt value of the user login related information according to a preset salt value encryption algorithm to obtain second salt value information.

[0143] Step S1360: The server verifies the first salt value information according to the second salt value information.

[0144] Step S1370, if the verification passes, the server determines that the JWT token is legal.

[0145] Step S1380: the server sends resource data corresponding to the resource access request to the client.

[0146] Step S1390, the server determines that the JWT token is invalid.

[0147] At this point, the verification process of the JWT token is completed; optionally, the specific implementation process of steps S1310 to S1390 can refer to the technical solution of the aforementioned embodiment.

[0148] In the embodiment of the present application, the legitimacy of the JWT token can be determined simply and quickly. In the process of determining the legitimacy of the JWT token, there is no need to add identification fields, the user experience will not be reduced, the pressure on the server is also small, it is simple and easy to implement, and the security of resource data access is greatly improved.

[0149] Fig.14 FIG. 1 is a block diagram of a resource access device according to an embodiment of the present application. Fig.14 As shown, the device is configured at the server end, and the device includes:

[0150] The receiving module 1410 is configured to receive a resource access request sent by a client; wherein the resource access request carries a JWT token, and the JWT token includes user login related information and a first salt value information;

[0151] The generating module 1420 is configured to calculate the salt value of the user login related information according to a preset salt value encryption algorithm to obtain second salt value information;

[0152] A verification module 1430, configured to verify the first salt value information according to the second salt value information;

[0153] The sending module 1440 is configured to determine that the JWT token is legal if the verification passes, and return the resource data corresponding to the resource access request to the client.

[0154] In one embodiment of the present application, the device further includes:

[0155] A salt value calculation module is configured to calculate a salt value for user login related information corresponding to the client according to a preset salt value encryption algorithm to obtain first salt value information;

[0156] The generating module 1420 is further configured to generate a JWT token according to the first salt value information;

[0157] The sending module 1440 is further configured to send the JWT token to the client.

[0158] In one embodiment of the present application, the JWT token includes a JWT field, in which user login related information is stored; the generation module 1420 includes:

[0159] A first storage unit is configured to store the first salt value information in the JWT field to obtain the JWT field storing the first salt value information;

[0160] The second storage unit is configured to encrypt the user login related information obtained from the JWT field according to the key, generate signature information, and store the signature information in the JWT field to obtain the JWT field storing the signature information;

[0161] The generating unit is configured to integrate the JWT field storing the first salt value information and the JWT field storing the signature information to generate a JWT token.

[0162] In one embodiment of the present application, the JWT field includes a header field, a body field and a signature field; the first storage unit is specifically configured to segment the first salt value information to obtain multiple sub-salt value information, and store each sub-salt value information in the header field and / or the body field respectively.

[0163] In one embodiment of the present application, the JWT field includes a header field, a body field and a signature field; the second storage unit is specifically configured to encrypt the user login-related information obtained from the body field according to the key, generate signature information, and store the signature information in the signature field.

[0164] In one embodiment of the present application, the device further includes:

[0165] The receiving module 1410 is further configured to receive a login request sent by a client; wherein the login request carries user account information and password information;

[0166] A verification module, configured to verify the identity of the user based on the user account information and password information;

[0167] The acquisition module is configured to allow the client to log in if the verification passes, and obtain the user login related information corresponding to the client.

[0168] In one embodiment of the present application, the JWT token includes a JWT field, the first salt value information is segmented into a plurality of sub-salt value information and stored in the JWT field; the verification module 1430 includes:

[0169] A combining unit, configured to obtain multiple sub-salt value information from the JWT field, and combine each sub-salt value information to obtain first salt value information;

[0170] The verification unit is configured to verify the first salt value information according to the second salt value information.

[0171] In one embodiment of the present application, the device further includes:

[0172] A decoding module, configured to decode the JWT token to obtain a JWT field;

[0173] A decryption module is configured to decrypt the signature information contained in the JWT field according to the key to obtain the decrypted user login related information;

[0174] A matching module configured to match the decrypted user login related information with the user login related information contained in the decoded JWT field;

[0175] an execution module, configured to execute a step of verifying the first salt value information according to the second salt value information if the match is successful;

[0176] The determination module is configured to determine that the JWT token is invalid if the match fails.

[0177] It should be noted that the resource access device provided in the above embodiment and the resource access method provided in the above embodiment belong to the same concept, wherein the specific manner in which each module and unit performs operations has been described in detail in the method embodiment and will not be repeated here.

[0178] An embodiment of the present application also provides an electronic device, comprising: one or more processors; a storage device for storing one or more programs, when the one or more programs are executed by one or more processors, the electronic device implements the resource access method provided in the aforementioned embodiments.

[0179] Fig.15 A schematic diagram of the structure of a computer system suitable for implementing an electronic device of an embodiment of the present application is shown.

[0180] It should be noted that Fig.15 The computer system 1500 of the electronic device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0181] like Fig.15 As shown, the computer system 1500 includes a central processing unit (CPU) 1501, which can perform various appropriate actions and processes according to the program stored in the read-only memory (ROM) 1502 or the program loaded from the storage part 1508 to the random access memory (RAM) 1503, such as executing the method in the above embodiment. In RAM 1503, various programs and data required for system operation are also stored. CPU 1501, ROM 1502 and RAM 1503 are connected to each other through bus 1504. Input / output (I / O) interface 1505 is also connected to bus 1504.

[0182] The following components are connected to the I / O interface 1505: an input section 1506 including a keyboard, a mouse, etc.; an output section 1507 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 1508 including a hard disk, etc.; and a communication section 1509 including a network interface card such as a LAN (Local Area Network) card, a modem, etc. The communication section 1509 performs communication processing via a network such as the Internet. A drive 1510 is also connected to the I / O interface 1505 as needed. A removable medium 1511, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 1510 as needed so that a computer program read therefrom is installed into the storage section 1508 as needed.

[0183] In particular, according to an embodiment of the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, an embodiment of the present application includes a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a computer program for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication section 1509, and / or installed from a removable medium 1511. When the computer program is executed by a central processing unit (CPU) 1501, various functions defined in the system of the present application are executed.

[0184] It should be noted that the computer-readable medium shown in the embodiment of the present application can be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium can be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media can include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), a flash memory, an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present application, a computer-readable storage medium can be any tangible medium containing or storing a program, which can be used by an instruction execution system, device or device or used in combination with it. In the present application, a computer-readable signal medium can include a data signal propagated in a baseband or as a part of a carrier wave, wherein a computer-readable computer program is carried. Such propagated data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, which may send, propagate, or transmit programs for use by or in conjunction with an instruction execution system, apparatus, or device. The computer program contained on the computer-readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wired, etc., or any suitable combination of the above.

[0185] The flowchart and block diagram in the accompanying drawings illustrate the possible architecture, functions and operations of the system, method and computer program product according to various embodiments of the present application. Wherein, each box in the flowchart or block diagram can represent a module, a program segment, or a part of the code, and the above-mentioned module, program segment, or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flowchart, and the combination of boxes in the block diagram or flowchart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0186] The units involved in the embodiments described in this application may be implemented by software or hardware, and the units described may also be set in a processor. The names of these units do not, in some cases, constitute limitations on the units themselves.

[0187] Another aspect of the present application also provides a computer-readable storage medium on which a computer program is stored, and when the computer program is executed by a processor, the resource access method as described above is implemented. The computer-readable storage medium may be included in the electronic device described in the above embodiment, or may exist independently without being assembled into the electronic device.

[0188] Another aspect of the present application also provides a computer program product or a computer program, which includes a computer instruction stored in a computer-readable storage medium. A processor of a computer device reads the computer instruction from the computer-readable storage medium, and the processor executes the computer instruction, so that the computer device executes the resource access method provided in each of the above embodiments.

[0189] The above content is only a preferred exemplary embodiment of the present application and is not intended to limit the implementation scheme of the present application. A person skilled in the art can easily make corresponding changes or modifications based on the main concept and spirit of the present application. Therefore, the scope of protection of the present application shall be based on the scope of protection required by the claims.

Claims

1. A resource access method, characterized in that: Applied to the server, the method includes: Receive a resource access request sent by a client; wherein the resource access request carries a JWT token, and the JWT token includes user login related information and a first salt value information; Calculate the salt value of the user login related information in the JWT token according to a preset salt value encryption algorithm to obtain second salt value information; verifying the first salt value information according to the second salt value information; If the verification passes, the JWT token is determined to be legal, and the resource data corresponding to the resource access request is returned to the client; Before receiving the resource access request sent by the client, the method further includes: Calculate the salt value of the user login related information corresponding to the client according to the preset salt value encryption algorithm to obtain the first salt value information; Generate the JWT token according to the first salt value information; Send the JWT token to the client; Before verifying the first salt value information according to the second salt value information, the method further includes: Decode the JWT token to obtain the JWT field; Decrypt the signature information contained in the JWT field according to the key to obtain the decrypted user login related information; Match the decrypted user login related information with the user login related information contained in the JWT field; If the match is successful, executing the step of verifying the first salt value information according to the second salt value information; If the match fails, it is determined that the JWT token is illegal.

2. The method according to claim 1, characterized in that The JWT token includes a JWT field, in which the user login related information is stored; and generating the JWT token according to the first salt value information includes: Storing the first salt value information in the JWT field to obtain a JWT field storing the first salt value information; Encrypt the user login related information obtained from the JWT field according to the key, generate signature information, and store the signature information in the JWT field to obtain the JWT field storing the signature information; The JWT field storing the first salt value information and the JWT field storing the signature information are integrated to generate the JWT token.

3. The method according to claim 2, characterized in that The JWT field includes a header field, a body field, and a signature field; and storing the first salt value information in the JWT field includes: Segmenting the first salt value information to obtain a plurality of sub-salt value information, and storing each sub-salt value information in the header field and / or the body field respectively; The encrypting the user login related information obtained from the JWT field according to the key, generating signature information, and storing the signature information in the JWT field includes: The user login related information obtained from the subject field is encrypted according to the key to generate the signature information, and the signature information is stored in the signature field.

4. The method according to claim 1, characterized in that Before calculating the salt value of the user login related information corresponding to the client according to the preset salt value encryption algorithm to obtain the first salt value information, the method further includes: Receiving a login request sent by the client; wherein the login request carries user account information and password information; Performing identity verification on the user according to the user account information and the password information; If the verification is passed, the client is allowed to log in, and the user login related information corresponding to the client is obtained.

5. The method according to claim 1, characterized in that The JWT token includes a JWT field, the first salt value information is segmented into a plurality of sub-salt value information and stored in the JWT field; and the verifying the first salt value information according to the second salt value information includes: Acquire multiple sub-salt value information from the JWT field, and combine the sub-salt value information to obtain the first salt value information; The first salt value information is verified according to the second salt value information.

6. A resource access device, characterized in that: Configured at the server end, the device includes: A receiving module configured to receive a resource access request sent by a client; wherein the resource access request carries a JWT token, and the JWT token includes user login related information and a first salt value information; A generation module is configured to calculate a salt value for the user login related information in the JWT token according to a preset salt value encryption algorithm to obtain second salt value information; a verification module, configured to verify the first salt value information according to the second salt value information; A sending module, configured to determine that the JWT token is legal if the verification passes, and return resource data corresponding to the resource access request to the client; Before receiving the resource access request sent by the client, the method further includes: Calculate the salt value of the user login related information corresponding to the client according to the preset salt value encryption algorithm to obtain the first salt value information; Generate the JWT token according to the first salt value information; Send the JWT token to the client; Before verifying the first salt value information according to the second salt value information, the method further includes: Decode the JWT token to obtain the JWT field; Decrypt the signature information contained in the JWT field according to the key to obtain the decrypted user login related information; Match the decrypted user login related information with the user login related information contained in the JWT field; If the match is successful, executing the step of verifying the first salt value information according to the second salt value information; If the match fails, it is determined that the JWT token is illegal.

7. An electronic device, characterized in that: include: one or more processors; A storage device for storing one or more programs, which, when executed by the one or more processors, enables the electronic device to implement the resource access method as described in any one of claims 1 to 5.

8. A computer readable medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the resource access method according to any one of claims 1 to 5 is implemented.

Images