CN115001714A - Resource access method and device, electronic equipment and storage medium - Google Patents

Abstract

The application discloses a resource access method and device, electronic equipment and a storage medium, wherein the method comprises the following steps: receiving a resource access request sent by a client; the resource access request carries user information and a user token, and the user token contains a signature algorithm to be verified; determining a target signature algorithm matched with the user information according to a mapping relation between preset user information and the signature algorithm; verifying the signature algorithm to be verified according to the target signature algorithm to obtain a first verification result; and determining whether to respond to the resource access request according to the first verification result. According to the method and the device, the signature algorithm of the user token carried by the resource access request is firstly verified after the resource access request is received, so that the condition that the signature algorithm in the user token is maliciously modified or deleted to forge the token which can bypass signature verification so as to illegally obtain the access resource is avoided, and the information security in the user token transmission process is ensured.

Description

Resource access method and device, electronic device, storage medium

technical field

The present application relates to the technical field of character recognition, and in particular, to a method and device for accessing resources, an electronic device, and a storage medium.

Background technique

JWT (Jsonwebtoken, an open standard based on Json) is a JSON-based open standard implemented for transferring claims between web application environments. It is generally used to transfer authenticated users between identity providers and service providers. Identity information, in order to obtain resources from the resource server, and some additional declaration information necessary for other business logic can also be added. The token can also be used directly for authentication or encrypted.

JWT consists of payload (header), header (load) and signature (visa). On the one hand, the signature mechanism of JWT token ensures the integrity of information, but on the other hand, it also brings great problems. The payload and header information of JWT are public. If the token is maliciously obtained during the transmission process, by modifying or deleting the signature algorithm in the header, it is possible to forge a token that can bypass the signature verification, obtain access resources, and provide information to the information system. pose a great security risk.

SUMMARY OF THE INVENTION

To solve the above technical problems, embodiments of the present application provide a resource access method and apparatus, electronic device, computer-readable storage medium, and computer program product.

According to an aspect of the embodiments of the present application, a resource access method is provided, including: receiving a resource access request sent by a client; wherein the resource access request carries user information and a user token, and the user token contains the signature algorithm to be verified; according to the preset user information and signature algorithm mapping relationship, determine the target signature algorithm that matches the user information; verify the signature algorithm to be verified according to the target signature algorithm, and obtain the first Verification result; determine whether to respond to the resource access request according to the first verification result.

According to an aspect of the embodiments of the present application, a resource access device includes: an acquisition unit, configured to receive a resource access request sent by a client, wherein the resource access request carries real-time user information and a user token, and the resource access request The user token contains a signature algorithm to be verified; a determination unit is used to determine a target signature algorithm matching the real-time user information according to the mapping relationship between the preset user information and the signature algorithm; a verification unit is used to determine the target signature algorithm based on the target signature The algorithm verifies the to-be-verified signature algorithm to obtain a verification result; an execution unit is configured to determine whether to respond to the resource access request based on the verification result.

In another exemplary embodiment, before receiving the resource access request sent by the client, the method further includes: receiving a token acquisition request sent by the client; wherein the token acquisition request carries There is user information; select the signature algorithm corresponding to the user information, and store the user information in association with the signature algorithm corresponding to the user information, and generate a mapping relationship between the preset signature algorithm and the user information; according to the The user information and the signature algorithm corresponding to the user information are used to generate the user token.

In another exemplary embodiment, the user information includes a user ID and a login timestamp; and the generating the user token according to the user information and the signature algorithm corresponding to the user information includes: according to The user ID, the login timestamp and the pre-stored basic key are used to generate a user key; wherein, the basic key is a pre-set key; according to the user key and the signature algorithm , to generate the user token.

In another exemplary embodiment, generating the user token according to the user information and the signature algorithm corresponding to the user information includes: acquiring payload data, and combining the user information with the user information. The load data is associated and stored, and the preset load data and user information mapping relationship is generated; wherein, the load data is data related to the user and the user token to be generated; according to the load data, the user key and all The signature algorithm is used to generate the user token.

In another exemplary embodiment, the user token further contains payload data to be verified, and the determining whether to respond to the resource access request according to the first verification result includes: if the first verification result represents In order to pass the verification, the target load data matching the user information is determined according to the preset load data and the user information mapping relationship; the to-be-verified load data is verified according to the target load data to obtain a second verification Result: if the second verification result indicates that the verification is passed, responding to the resource access request to allow the client to access the resource.

In another exemplary embodiment, the method further includes: receiving an invalidation request for the user token sent by the client; acquiring a user key and a basic key corresponding to the user token; wherein, The basic key is preset, and the user key is determined according to the basic key; the user key is modified to the basic key to make the user token invalid.

In another exemplary embodiment, the modifying the user key to the basic key includes: if it is detected that the invalidation request carries an immediate invalidation instruction, changing the immediate invalidation instruction according to the immediate invalidation instruction. The user key is modified to the basic key; wherein, the instant invalidation instruction is used to instruct the user token to be invalidated immediately.

According to an aspect of the embodiments of the present application, an electronic device includes: one or more processors; and a storage device for storing one or more programs, when the one or more programs are stored by the one or more programs When executed by the processor, the electronic device implements the resource access method as before.

According to one aspect of the embodiments of the present application, a computer-readable storage medium stores computer-readable instructions thereon, and when the computer-readable instructions are executed by a processor of a computer, causes the computer to perform the above-mentioned resource access method.

According to one aspect of the embodiments of the present application, there is provided a computer program product or computer program, where the computer program product or computer program includes computer instructions, and the computer instructions are stored in a computer-readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the resource access methods provided in the various optional embodiments described above.

In the technical solutions provided by the embodiments of the present application, before responding to the received resource access request, the carried user token is verified to verify the legitimacy of the token of the resource access request. The mapping relationship between user information and signature algorithm, determine the target signature algorithm that matches the user information carried in the resource access request, and then verify the signature algorithm to be verified in the user token according to the target signature algorithm, and determine whether to respond to the resource access request according to the verification result. . In this way, since there is a mapping relationship between the preset user information and the signature algorithm, after the resource access request is received, the verification of the signature algorithm of the user token carried by it can be realized through the mapping relationship between the preset user information and the signature algorithm. This avoids the situation of illegally obtaining access resources by maliciously modifying or deleting the signature algorithm in the user token to forge a token that can bypass the signature verification in the related art, and ensuring the security of the user token transmission process.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not limiting of the present application.

Description of drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the application and together with the description serve to explain the principles of the application. Obviously, the drawings in the following description are only some embodiments of the present application, and for those skilled in the art, other drawings can also be obtained from these drawings without creative effort. In the attached image:

1 is a schematic diagram of an implementation environment involved in the present application;

FIG. 2 is a flowchart of a method for accessing resources according to an exemplary embodiment of the present application;

FIG. 3 is a flowchart of a method for accessing a resource shown in an exemplary embodiment of the step of generating a user token before step S201 in the embodiment shown in FIG. 2;

FIG. 4 is a flowchart of step S204 in the embodiment shown in FIG. 2 in an exemplary embodiment;

5 is a flowchart of a method for accessing resources according to an exemplary embodiment of the present application;

6 is a flowchart of a method for accessing resources according to an exemplary embodiment of the present application;

7 is a flowchart of a resource access method shown in an exemplary embodiment of the steps of performing identity verification on the invalidation request and verifying the carried user token before step S400 in the embodiment shown in FIG. 5;

8 is a flowchart of a method for accessing resources according to an exemplary embodiment of the present application;

FIG. 9 is a block diagram of a resource access apparatus shown in an exemplary embodiment of the present application;

FIG. 10 is a schematic structural diagram of a computer system suitable for implementing the electronic device according to the embodiment of the present application.

Detailed ways

The description will now be made in detail of exemplary embodiments, examples of which are illustrated in the accompanying drawings. Where the following description refers to the drawings, the same numerals in different drawings refer to the same or similar elements unless otherwise indicated. The implementations described in the illustrative examples below are not intended to represent all implementations consistent with this application. Rather, they are merely examples of apparatus and methods consistent with some aspects of the present application as recited in the appended claims.

The block diagrams shown in the figures are merely functional entities and do not necessarily necessarily correspond to physically separate entities. That is, these functional entities may be implemented in software, or in one or more hardware modules or integrated circuits, or in different networks and/or processor devices and/or microcontroller devices entity.

The flowcharts shown in the figures are only exemplary illustrations and do not necessarily include all contents and operations/steps, nor do they have to be performed 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 be changed according to the actual situation.

The "plurality" mentioned in this application means two or more. "And/or" describes the association relationship between associated objects, indicating that there can be three kinds of relationships, for example, A and/or B can indicate that A exists alone, A and B exist at the same time, and B exists alone. The character "/" generally indicates that the associated objects are an "or" relationship.

In related technologies, JWT (JSON Web Token) is an open industry standard, which defines a concise, self-contained protocol format for transferring json objects between communication parties, and the transferred information can be verified and trusted through digital signatures. The JWT token consists of three parts: Header (header), Payload (payload), and Signature (visa). Each part is separated by a dot ".".

The header includes the type of token (ie JWT) and the signature algorithm used (eg HMACSHA256 or RSA256). The content of the payload is also a json object, which is where valid information is stored. It can store ready-made fields provided by jwt, such as: iss (issuer), exp (expiration timestamp), sub (user-oriented), etc., or custom fields. The visa part is used to prevent the JWT content from being tampered with. In the visa part, use base64url to encode the header and payload respectively to get the first and second parts of the JWT token, and then use dot "." after encoding to form a string, and finally use the header to select and The claimed signature algorithm is signed to get the third part of the JWT token. Only the third part of the three parts of the JWT is encrypted. Through the digital signature mechanism, the data integrity can be guaranteed and the data source can be authenticated. In this way, the JWT token has the advantages of convenient parsing based on json and the advantages of customizing rich content in the token and easy expansion.

However, since the payload and header information of JWT are public, if the token is maliciously obtained during the transmission process, by modifying or deleting the signature algorithm in the header, it is possible to forge a token that can bypass the signature verification, and finally follow the resource access request. It is illegal to obtain access resources at times, and when verifying the token, only the payload information in the token is verified, which brings great security risks to the information system.

In order to solve the above problems, the embodiments of the present application propose a resource access method and device, electronic equipment, and computer-readable storage medium, which mainly relate to the character recognition technology of machine vision included in artificial intelligence technology. These embodiments will be described below. Detailed description.

First, please refer to FIG. 1 , which is a schematic diagram of an implementation environment involved in the present application. The implementation environment includes a terminal 10 and a server 20, and communication between the terminal 10 and the server 20 is performed through a wired or wireless network.

After receiving the resource access request, the server 20 is configured to verify the user token carried in the resource access request, and verify the legitimacy of the token of the resource access request. First, the resource access is determined by presetting the mapping relationship between the user information and the signature algorithm. Request the target signature algorithm that matches the user information carried, and then verify the signature algorithm to be verified in the user token according to the target signature algorithm, determine whether to respond to the resource access request according to the verification result, and determine whether to respond to the resource access request. The result is transmitted to the terminal 10, so that the terminal 10 performs resource access to the server 20 when it receives the feedback determined to respond to the resource access request. Compared with the resource access scheme in the prior art, the resource access method provided by this implementation environment can ensure the information security in the process of user token transmission.

It should be noted that the terminal 10 in the implementation environment shown in FIG. 1 can be any electronic device such as a smart phone, tablet, notebook computer, computer, etc.; the server 20 server can be an independent server, or can provide cloud services and cloud databases. , cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, Content Delivery Network (CDN), and cloud servers for basic cloud computing services such as big data and artificial intelligence platforms , which is not restricted here.

FIG. 2 is a flowchart of a method for accessing resources according to an exemplary embodiment of the present application. The method can be applied to the implementation environment shown in FIG. 1 , and is specifically executed by the server where the server 20 is located in the embodiment environment shown in FIG. 1 . In other implementation environments, the method may be executed by devices in other implementation environments, which is not limited in this embodiment.

As shown in FIG. 2, in an exemplary embodiment, the resource access method may include steps S201 to S204, which are described in detail as follows:

Step S201: Receive a resource access request sent by a client; wherein, the resource access request carries user information and a user token, and the user token contains a signature algorithm to be verified.

The server receives the resource access request sent by the client, and the resource access request is used by the client to request the server for the right to access resources. In addition, the resource access request carries user information and user token associated with it, wherein the user information may include basic information of the user such as user name, user account, and login password; Before the request, the token corresponding to the client's user information is obtained from the server, and the server verifies the legitimacy of the client's access through the user token. Therefore, the user token carried in the resource access request contains the signature algorithm to be verified.

Step S202: Determine a target signature algorithm matching the user information according to the preset mapping relationship between the user information and the signature algorithm.

The server stores the mapping relationship between the preset user information and the signature algorithm, and can obtain and store the mapping relationship between the preset user information and the signature algorithm when the server generates the token corresponding to the client in advance, that is, the user token has been obtained. Each client has a unique and correct signature algorithm, which is reflected in the preset user information and signature algorithm mapping relationship. In this way, after receiving the resource access request sent by the client and obtaining the user information carried by the resource access request, the target signature algorithm that matches the user information can be determined through the user information carried in the resource access request, which is used for the signature algorithm to be verified. verify.

Step S203, verifying the signature algorithm to be verified according to the target signature algorithm to obtain a first verification result.

After the target signature algorithm matching the user information is determined according to the preset user information and signature algorithm mapping relationship, the signature algorithm to be verified is obtained from the user token carried in the resource access request at the same time. The signature algorithm to be verified is verified by judging whether the signature algorithm to be verified is consistent with the target signature algorithm, and the first verification result is obtained. Indicates that the verification fails.

Step S204, determining whether to respond to the resource access request according to the first verification result.

The server determines whether to respond to the resource access request based on the content represented by the first verification result. If the verification is passed, the server responds to the resource access request and allows the client to access resources. If the verification fails, the server returns Exception message to the client and refuse to respond to the resource access request.

As can be seen from the above, in the method provided in this embodiment, the validity of the token of the resource access request is verified by verifying the user token carried in the resource access request. First, the preset user information stored in the server is used. The mapping relationship with the signature algorithm determines the target signature algorithm that matches the user information carried in the resource access request, and then verifies the consistency of the signature algorithm to be verified in the user token according to the target signature algorithm. The result determines whether the server responds to the resource access request. In this way, after the resource access request is received, the signature algorithm of the user token carried in the resource access request is first verified by using the preset mapping relationship between the user information and the signature algorithm, so as to avoid malicious modification or deletion of the signature algorithm in the user token. , in order to forge a token that can bypass the signature verification and illegally obtain the right to access resources, which ensures the security of the user's token transmission process and avoids security risks such as information leakage.

Please refer to FIG. 3 . FIG. 3 is a flowchart of an exemplary embodiment of the resource access method provided by the present application further including the step of generating a user token at the server before step S201 in the embodiment shown in FIG. 2 . As shown in FIG. 3, the step of generating a user token may specifically include steps S301 to S305, and the user token is generated according to the token acquisition request through the above steps, and the details are as follows:

Step S301, receiving a token acquisition request sent by a client.

The client obtains the user token by sending a token obtaining request to the server. Since the server needs to generate a user token associated with the server according to the token obtaining request, the token obtaining request sent by the client carries the user token. The information is not only used to generate the user token, but also plays the role of identification so that the generated user token corresponds to the client.

Step S302, select a signature algorithm corresponding to the user information, associate and store the user information and the signature algorithm corresponding to the user information, and generate a mapping relationship between the preset signature algorithm and the user information.

The server selects a signature algorithm corresponding to the user information, and the selected signature algorithm may include, but is not limited to, a symmetric signature algorithm (HS256) or an asymmetric signature algorithm (RS256). And the selected signature algorithm is associated with the user request carried in the token acquisition request, and then the association relationship is stored to generate a preset signature algorithm and user information mapping relationship, which is used to verify the user token of the resource access request. When preparing, the target signature algorithm is determined from the stored mapping relationship between the preset signature algorithm and the user information.

Among them, the method of selecting the corresponding signature algorithm can be selected according to user needs, or according to different user types corresponding to different signature algorithms set in advance, and can also be selected according to relevant JWT specifications, which is not limited here.

Further, the user information carried in the token acquisition request includes a user ID and a login timestamp. In step S303, a user key is generated according to the user ID, the login timestamp and a pre-stored basic key.

Obtain the user ID and login timestamp included in the user information, obtain the user key in the form of basic key + user ID + login timestamp and store it. data is encrypted. The basic key mentioned above is a preset key, which may be a key randomly generated by the server during the initialization phase, and used as the basic key.

Step S304: Acquire load data, associate and store the user information and the load data, and generate a preset mapping relationship between the load data and the user information.

Obtain payload data for adding to the payload portion of the token, payload data refers to data related to the user and the user token to be generated, which can include but is not limited to the subject, the token issuer, the party receiving the token, the order The issuance time of the token, the expiration time of the token, the time when the token is available, the identity of the token, and other custom user information such as username and other information. And the obtained load data is associated with the user request carried in the token obtaining request, and then the association is stored to generate the preset load data and user information mapping relationship.

Step S305: Generate a user token according to the payload data, the user key and the signature algorithm.

After acquiring or generating the payload data, user key and signature algorithm according to the above steps, describe the selected signature algorithm in the header part, add the acquired payload data in the payload part, and then use the signature algorithm and the user key to pair the header part with the payload. Part of the data is combined and encrypted, and the encrypted data is written into the visa part. Finally, the three parts of the header, the payload and the visa are combined to form a string, and each part is separated by "." to form the entire JWT token object. The user token corresponding to the token acquisition request sent by the client.

In addition, it should be noted that the step of generating and storing the mapping relationship between the preset signature algorithm and the user information may be after the signature algorithm is selected, or when the user token is generated or after the user token is generated. It is described in step S302, only for the convenience of understanding, and does not limit the implementation order of this step to the meaning that the preset signature algorithm and the user information mapping relationship can be generated after selecting the signature algorithm; and, generate and store the generated preset. The mapping relationship between the load data and the user information may also be after the load data is acquired, or when the user token is generated or after the user token is generated.

In another embodiment of the present application, before the server selects a corresponding signature algorithm according to the user information carried in the received token acquisition request in step S302, the method further includes the step of authenticating the client user, which may specifically be Including: acquiring account data included in the user information, such as account number and login password, performing identity verification based on the account data, and if the identity verification is passed, then executing the step S302 of selecting a signature algorithm, and implementing the step of generating a user token; If passed, return exception information to the client and refuse to respond to the token acquisition request.

In the above-mentioned embodiments provided in this application, a user token matching the client is generated according to the token acquisition request, and a preset signature for verifying the user token carried in the resource access request is generated when the resource access request is subsequently received The mapping relationship between the algorithm and the user information can verify the signature algorithm of the user token, ensure the security of the user token transmission process, and avoid security risks such as information leakage.

Please refer to FIG. 4 , which is a flowchart of step S204 in the embodiment shown in FIG. 2 in an exemplary embodiment. As shown in FIG. 4 , step S204 may include steps S401 to S403, and the above steps are used to further verify the payload data to be verified contained in the user token. The details are as follows:

Step S401 , if the first verification result indicates that the verification is passed, the target load data matching the user information is determined according to the mapping relationship between the preset load data and the user information.

If the first verification result indicates that the verification is passed, it means that the signature algorithm of the user token is consistent with the determined target signature algorithm, and then the payload data of the user token needs to be verified. Before performing verification, it is necessary to obtain the target load data matching the user information. In this embodiment, according to the pre-stored mapping relationship between the preset load data and the user information, it is determined that the target load data matching the user information carried in the resource access request is determined. Load data, as the target load data.

Step S402, verifying the load data to be verified according to the target load data to obtain a second verification result.

At the same time, the server will also obtain the load data to be verified contained in the user token, so that after obtaining the target load data, it will verify the load data to be verified by determining whether the load data to be verified is consistent with the target load data, and obtain the second If the verification results are determined to be consistent, the second verification result is characterized as passed the verification; otherwise, if it is determined to be inconsistent, the second verification result is represented as the verification failed.

Obtaining the second verification result may also be: obtaining the signature algorithm to be verified or the target signature algorithm verified by the signature algorithm, and the user secret key corresponding to the signature algorithm to be verified or the target signature algorithm, and extracting the header part of the user token at the same time The payload data of the data and the payload part; the header part data and the payload part data are combined and encrypted by the obtained user secret key and the signature algorithm to be verified or the target signature algorithm to obtain new encrypted data, that is, the new visa part; Compare the new visa part with the visa part of the user token carried in the resource access request to determine whether they are consistent. In this way, it is verified whether the payload data part of the user token or even the user secret key has been tampered with, thereby ensuring the security of the user token transmission process.

Step S403, if the second verification result indicates that the verification is passed, the resource access request is responded to to allow the client to access the resource.

If the second verification result indicates that the verification is passed, it means that the user token carried in the resource access request has passed the verification of the payload data after the signature algorithm has passed the verification, and the server needs to respond to the resource access request and allow the client to access the resource. . If the second verification result indicates that the verification fails, the server needs to return exception information to the client and refuse to respond to the resource access request.

It can be seen from the above that in the method provided in this embodiment, the user load information verification is performed on the basis of verifying that the signature algorithm is correct, so as to further ensure the security of the user token transmission process, and avoid the possibility that the token itself may be damaged due to the structure of the token itself. By maliciously modifying or deleting the signature algorithm in the header, to forge the token problem that can bypass signature verification.

In addition, for the user token generated on the server side, after it is sent to the client, the token is independent of the server side, even if the user token has been revoked on the server side but has not expired. It may be maliciously used, which further increases the security risk to the information system, and most of them use a random secret key to invalidate the token every time the token needs to be invalidated. To save a large number of random keys, there is a problem of occupying a lot of computing resources.

Further, for the user token provided by the above embodiments, please refer to FIG. 5 . FIG. 5 is a flowchart of a resource access method shown in an exemplary embodiment of the present application, which specifically includes steps S501 to S503. Through the above steps to instruct the invalidation request for the user token provided by the above embodiments, the details are as follows:

Step S501, receiving an invalidation request for the user token sent by the client.

When the user needs to send offline or logout services through the client, the client will send an invalidation request for the user token to the server, and the server will carry the user token corresponding to the client user according to the invalidation request. Perform invalidation processing to complete the offline or logout service.

Step S502, acquiring the user key and the basic key corresponding to the user token.

The basic key is obtained in advance, and the user key is determined according to the basic key. Specifically, when the user token is generated, the user secret key is obtained in the form of basic key + user ID + login timestamp, and the user ID and login timestamp are obtained from user information. The basic key mentioned above is a preset key, which may be a key randomly generated by the server during the initialization phase, and used as the basic key.

Step S503, modifying the user key to the basic key to invalidate the user token.

After obtaining the user key and basic key corresponding to the user token, modify the user key to the basic key, that is, the composition of the user key is in the form of basic key + user ID + login timestamp, and becomes only The form of the base key.

In this way, in this embodiment, for the invalidation instruction transmitted by the user token, by changing the user key corresponding to the user token to the basic key, the previous user token is invalidated, and the password cannot be used for the next login. It uses the preset basic key to modify the user's key, which solves the problem that the key is randomly generated when the token is invalid, which leads to the occupation of more computing resources. At the same time, it avoids the revoked user token and malicious use. It further ensures the security of the user token transmission process, and avoids security risks such as information leakage.

In another embodiment, the invalidation request also carries an immediate invalidation instruction. As shown in FIG. 6 , step S503 in the embodiment shown in FIG. 5 can be specifically expressed as:

Step S600, if it is detected that the invalidation request carries an instant invalidation instruction, the user key is modified into a basic key according to the instant invalidation instruction.

The above-mentioned instant invalidation instruction is used to instruct the user token to be invalidated immediately, and the user token invalidation processing of immediately modifying the user key to the basic key can avoid the time gap between receiving the invalidation instruction and implementing the invalidation processing. The internal user token is being used maliciously.

Please refer to FIG. 7 . FIG. 7 shows that before step S502 in the embodiment shown in FIG. 5 , the resource access method provided by the present application further includes the steps of performing identity verification on the invalidation request and verifying the carried user token. In an example Flowchart in the exemplary embodiment. As shown in FIG. 7, it may specifically include steps S701 to S704, which are described in detail as follows:

Step S701, performing identity verification based on the user information carried in the invalidation request.

Acquire the account data included in the user information carried in the invalidation request, such as the account number and login password, and perform authentication based on the account data to verify the legitimacy of the user login in real time.

Step S702, if the identity verification is passed, the target signature algorithm and target payload data matching the user information are determined according to the preset user information and signature algorithm mapping relationship and the preset load data and user information mapping relationship.

On the contrary, if the authentication fails, it will return an exception message and refuse to respond to the invalid request.

Step S703: Based on the target signature algorithm and the target load data, the signature algorithm and the load of the user token to be invalidated carried by the invalidation request are respectively verified in sequence, and a third verification result is obtained.

The server will also obtain the signature algorithm and payload data contained in the user token to be expired, so that after obtaining the target payload data, the signature algorithm of the expired user token is first verified by whether the signature algorithm is consistent with the target signature algorithm. If the verification of the signature algorithm fails, the third verification result indicates that the verification fails; if the verification of the signature algorithm passes, the payload data of the invalid user token is verified by whether the payload data is consistent with the target payload data. The third verification result is characterized as passing the verification, otherwise, if it is determined that the verification is inconsistent, the third verification result is characterized as failing the verification.

Step S704, if the third verification result indicates that the verification is passed, the user token is invalidated in response to the invalidation request.

If the third verification result is represented as passing, the steps of the embodiment shown in FIG. 5 are performed to perform invalidation processing on the user token; if the third verification result is represented as failing, abnormal information is returned and the invalidation request is rejected.

Therefore, with the method of this embodiment, before the application performs invalidation processing on the user token according to the invalidation request, the validity of the user token is also verified through the signature algorithm and the payload data in turn, avoiding malicious modification or The signature algorithm in the user token is deleted to forge the token that can bypass the signature verification and thus become an illegal or even malicious invalid token, which ensures the security of the user token transmission process.

Please refer to FIG. 8. FIG. 8 is a flowchart of the resource access method provided by the present application in an exemplary embodiment, which may include steps S801 to S811, as follows:

Step S801, receiving a token acquisition request sent by a client.

Step S802, perform identity verification according to the user information carried in the token acquisition request, and determine whether the identity verification is passed, if the identity verification is passed, jump to step S803, and if the identity verification fails, jump to step S811.

Step S803, select a signature algorithm, generate a user secret key according to the user information and the basic key, acquire payload data, and generate a user token according to the payload data, the user key and the signature algorithm.

Step S804, storing the mapping relationship between the preset user information and the signature algorithm and the mapping relationship between the preset load data and the user information.

Step S805: Receive a resource access request that carries user information and a user token and is sent by the client.

Step S806, receiving an invalidation request for the user token sent by the client.

Step S807, according to the preset user information and signature algorithm mapping relationship, determine the target signature algorithm that matches the user information, verify the signature algorithm to be verified according to the target signature algorithm to obtain a first verification result, and determine whether the first verification result is represented as passing. , if passed, go to step S808, if not pass, go to step S811.

Step S808: Determine the target load data matching the user information according to the mapping relationship between the preset load data and the user information, verify the load data to be verified according to the target load data to obtain a second verification result, and determine whether the second verification result is characterized as Pass, if pass and receive a resource access request, go to step S809; if pass and receive an invalidation request, go to step S810, if not pass, go to step S811.

Step S809, responding to the resource access request to allow the client to access the resource.

Step S810, modifying the user key to the basic key to invalidate the user token.

Step S811, returning abnormal information and rejecting the response request.

In the above embodiment, when the user token is generated, the preset user information and signature algorithm mapping relationship and the preset load data and user information mapping relationship are stored, which are used for the signature algorithm when a resource access request or invalidation request is received. And the payload data are verified in turn, avoiding the malicious modification or deletion of the signature algorithm in the user token to forge tokens that can bypass the signature verification and thus illegal or even malicious invalid tokens, ensuring the user token transmission process. security in.

FIG. 9 is a block diagram of a resource access apparatus 900 according to an exemplary embodiment of the present application. As shown in Figure 9, the device includes:

The obtaining unit 901 is configured to receive a resource access request sent by a client, wherein the resource access request carries real-time user information and a user token, and the user token contains a signature algorithm to be verified;

A determining unit 902, configured to determine a target signature algorithm that matches the real-time user information according to the mapping relationship between the preset user information and the signature algorithm;

A verification unit 903, configured to verify the signature algorithm to be verified based on the target signature algorithm to obtain a verification result;

The executing unit 904 is configured to determine whether to respond to the resource access request based on the verification result.

The device applies the resource access method provided in this application, and after receiving the resource access request sent by the client through the obtaining unit 901, the determining unit 902 determines the resource access request by using the preset user information and the signature algorithm mapping relationship stored in the server in advance. The target signature algorithm that matches the user information carried in the request is requested, and then the verification unit 903 verifies the consistency of the signature algorithm to be verified in the user token according to the target signature algorithm, and finally the execution unit 904 determines the server according to the obtained first verification result. Whether to respond to resource access requests. In this way, the signature algorithm of the user token carried in the resource access request is verified by presetting the mapping relationship between the user information and the signature algorithm, avoiding malicious modification or deletion of the signature algorithm in the user token, and ensuring that the user token is transmitted during the transmission process. security, avoiding security risks such as information leakage.

In another exemplary embodiment, the apparatus further includes:

A token generation unit, configured to receive a token acquisition request sent by the client; select a signature algorithm corresponding to the user information, associate and store the user information and the signature algorithm corresponding to the user information, and generate a preset signature algorithm and user information mapping relationship; generate user key according to user ID, login timestamp and pre-stored basic key; obtain load data, associate and store user information and load data, and generate preset load data and user information mapping relationship; Data, user key, and signature algorithm to generate user token.

In another exemplary embodiment, the verification unit 903 is further configured to determine the target load data matching the user information according to the preset load data and the user information mapping relationship if the first verification result is characterized as passing the verification ; Verify the load data to be verified according to the target load data to obtain a second verification result; if the second verification result is characterized as passing the verification, respond to the resource access request to allow the client to access resources.

In another exemplary embodiment, the apparatus further includes:

The token invalidation unit is used to receive the invalidation request for the user token sent by the client; obtain the user key and the basic key corresponding to the user token; wherein, the basic key is preset, and the user key is Determined from the base key; the user key is modified to the base key to invalidate the user token.

In another exemplary embodiment, the token expiry unit is further configured to modify the user key to the basic key according to the instant expiry instruction if it is detected that the expiry request carries the instant expiry instruction; wherein the instant expiry instruction Used to indicate immediate invalidation of the user token.

It should be noted that the resource access device provided by the above embodiments and the resource access method provided by the above embodiments belong to the same concept, and the specific manner in which each module and unit performs operations has been described in detail in the method embodiments. It is not repeated here. In practical applications of the resource access device provided by the above-mentioned embodiments, the above-mentioned function allocation can be completed by different functional modules according to needs, that is, the internal structure of the device is divided into different functional modules, so as to complete all or part of the functions described above. , and this is not restricted here.

Embodiments of the present application also provide an electronic device, including: one or more processors; and a storage device for storing one or more programs, when the one or more programs are executed by the one or more processors, The electronic device is made to implement the resource access methods provided in the above embodiments.

FIG. 10 shows a schematic structural diagram of a computer system suitable for implementing the electronic device according to the embodiment of the present application. It should be noted that the computer system 1000 of the electronic device shown in FIG. 10 is only an example, and should not impose any limitations on the functions and scope of use of the embodiments of the present application.

As shown in FIG. 10 , the computer system 1000 includes a central processing unit (Central Processing Unit, CPU) 1001, which can be loaded into a random access memory (RAM) according to a program stored in a read-only memory (Read-Only Memory, ROM) 1002 or from a storage part 1008 Random Access Memory (RAM) 1003 to execute various appropriate actions and processes, such as executing the methods in the above-mentioned embodiments. In the RAM 1003, various programs and data necessary for system operation are also stored. The CPU 1001 , the ROM 1002 , and the RAM 1003 are connected to each other through a bus 1004 . An Input/Output (I/O) interface 1005 is also connected to the bus 1004 .

The following components are connected to the I/O interface 1005: an input section 1006 including a keyboard, a mouse, etc.; an output section 1007 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a hard disk, etc. The storage part 1008; and the communication part 1009 including a network interface card such as a LAN (Local Area Network) card, a modem, and the like. The communication section 1009 performs communication processing via a network such as the Internet. A drive 1010 is also connected to the I/O interface 1005 as needed. A removable medium 1011, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is mounted on the drive 1010 as needed so that a computer program read therefrom is installed into the storage section 1008 as needed.

In particular, according to embodiments of the present application, the processes described above with reference to the flowcharts may be implemented as computer software programs. For example, embodiments of the present application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program comprising a computer program for performing the method illustrated in the flowchart. In such an embodiment, the computer program may be downloaded and installed from the network via the communication portion 1009, and/or installed from the removable medium 1011. When the computer program is executed by the central processing unit (CPU) 1001, various functions defined in the system of the present application are executed.

It should be noted that the computer-readable medium shown in the embodiments of the present application may 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, apparatus or device, or a combination of any of the above. More specific examples of computer readable storage media may include, but are not limited to, electrical connections with one or more wires, portable computer disks, hard disks, random access memory (RAM), read only memory (ROM), erasable Erasable Programmable Read Only Memory (EPROM), flash memory, optical fiber, portable compact disk read only memory (Compact Disc Read-Only Memory, CD-ROM), optical storage device, magnetic storage device, or any suitable combination of the above. In this application, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying a computer-readable computer program thereon. 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 foregoing. A computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium that can transmit, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device . A computer program embodied on a computer-readable medium may be transmitted using any suitable medium, including but not limited to: wireless, wired, etc., or any suitable combination of the foregoing.

The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present application. Wherein, each block in the flowchart or block diagram may represent a module, program segment, or part of code, and the above-mentioned module, program segment, or part of code contains one or more executables for realizing the specified logical function instruction. It should also be noted that, in some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It is also noted that each block of the block diagrams or flowchart illustrations, and combinations of blocks in the block diagrams or flowchart illustrations, can be implemented in special purpose hardware-based systems that perform the specified functions or operations, or can be implemented using A combination of dedicated hardware and computer instructions is implemented.

The units involved in the embodiments of the present application may be implemented in software or hardware, and the described units may also be provided in a processor. Among them, the names of these units do not constitute a limitation on the unit itself under certain circumstances.

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, implements the foregoing resource access method. The computer-readable storage medium may be included in the electronic device described in the above embodiments, or may exist alone without being assembled into the electronic device.

Another aspect of the present application also provides a computer program product or computer program comprising computer instructions stored in a computer-readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the resource access methods provided in the foregoing embodiments.

The above are only preferred embodiments of the present application, and are not intended to limit the present application. Any modifications, equivalent replacements or improvements made within the spirit and principles of the present application shall be included in the protection scope of the present application. Inside.

Claims (10)

1. a resource access method, is characterized in that, comprises: Receive a resource access request sent by the client; wherein, the resource access request carries user information and a user token, and the user token contains a signature algorithm to be verified; According to the preset user information and the signature algorithm mapping relationship, determine the target signature algorithm that matches the user information; Verifying the signature algorithm to be verified according to the target signature algorithm to obtain a first verification result; Whether to respond to the resource access request is determined according to the first verification result. 2. The method according to claim 1, characterized in that, before receiving the resource access request sent by the client, the method further comprises: receiving a token acquisition request sent by the client; wherein the token acquisition request carries user information; Selecting a signature algorithm corresponding to the user information, storing the user information in association with the signature algorithm corresponding to the user information, and generating a mapping relationship between the preset signature algorithm and the user information; The user token is generated according to the user information and the signature algorithm corresponding to the user information. 3 . The method according to claim 2 , wherein the user information includes a user ID and a login timestamp; the user information is generated according to the signature algorithm corresponding to the user information and the user information. 4 . Tokens, including: Generate a user key according to the user ID, the login timestamp and a pre-stored basic key; wherein the basic key is a preset key; The user token is generated according to the user key and the signature algorithm. 4. The method according to claim 3, wherein the generating the user token according to the user information and the signature algorithm corresponding to the user information comprises: Acquire load data, store the user information in association with the load data, and generate a preset mapping relationship between the load data and the user information; wherein the load data is data related to the user and the user token to be generated; The user token is generated according to the payload data, the user key and the signature algorithm. 5. The method according to any one of claims 1 to 4, wherein the user token further contains payload data to be verified, and the determination of whether to respond to the resource access according to the first verification result requests, including: If the first verification result indicates that the verification is passed, then according to the preset load data and user information mapping relationship, determine the target load data that matches the user information; Verifying the load data to be verified according to the target load data to obtain a second verification result; If the second verification result indicates that the verification is passed, the resource access request is responded to to allow the client to access the resource. 6. The method according to any one of claims 1 to 4, wherein the method further comprises: receiving an invalidation request for the user token sent by the client; Obtain the user key and the basic key corresponding to the user token; wherein, the basic key is preset and obtained, and the user key is determined according to the basic key; Modify the user key to the base key to invalidate the user token. 7. The method according to claim 6, wherein the modifying the user key to the base key comprises: If it is detected that the invalidation request carries an immediate invalidation instruction, the user key is modified to the basic key according to the immediate invalidation instruction; wherein, the immediate invalidation instruction is used to instruct the user to immediately The token is invalidated. 8. A resource access device, comprising: an acquisition unit, configured to receive a resource access request sent by a client, wherein the resource access request carries real-time user information and a user token, and the user token contains a signature algorithm to be verified; a determining unit, configured to determine a target signature algorithm matching the real-time user information according to the preset user information and the signature algorithm mapping relationship; a verification unit, configured to verify the signature algorithm to be verified based on the target signature algorithm to obtain a verification result; An execution unit, configured to determine whether to respond to the resource access request based on the verification result. 9. An electronic device, characterized in that, comprising: one or more processors; storage means for storing one or more programs which, when executed by the one or more processors, cause the electronic device to implement the electronic device as claimed in any one of claims 1 to 7 The resource access method described above. 10. A computer-readable storage medium, wherein a computer-readable instruction is stored thereon, and when the computer-readable instruction is executed by a processor of the computer, the computer is made to execute any one of claims 1 to 7. The resource access method described in item.

Images