Resource access method, device and system and electronic equipment

Abstract

The invention provides a resource access method, device and system and electronic equipment, and relates to the technical field of computers. The method comprises the following steps: receiving a resource access request initiated by a user due to acquisition of target information in a client access process; the resource access request is used for indicating a target resource requested to be accessed by a user; the target information in the resource access request is analyzed; if the target information is analyzed to obtain an access token, performing identity verification and authority verification on the user according to the access token to determine whether the user can be authorized to access the target resource; and if the user passes the verification, returning related information of the target resource to the client. The problem that the resource access process is not safe enough in the prior art is solved.

Description

Technical Field

[0001] This application relates to the field of computer technology. Specifically, this application relates to a resource access method, apparatus, system, and electronic device. Background Art

[0002] In modern Internet applications, user authentication and authorization are very important links. Usually, users need to provide a username and password for authentication, and then the server will decide whether to allow them to access the corresponding resources based on the user's permissions. However, this method has some security risks, such as password leakage and malicious attacks.

[0003] As can be seen from the above, the problem of insufficient security in the process of resource access needs to be solved. Summary of the Invention

[0004] This application provides a resource access method, apparatus, electronic device, storage medium, and computer program product, which can solve the problem of insufficient security in the process of resource access in related technologies. The technical solutions are as follows:

[0005] According to one aspect of this application, a resource access method is executed by a server. The method includes: receiving a resource access request initiated by a user during the access to a client due to obtaining target information; the resource access request is used to indicate the target resource that the user requests to access; parsing the target information in the resource access request; if an access token is parsed from the target information, performing identity authentication and permission verification on the user according to the access token to determine whether the user can be authorized to access the target resource; if the user passes the verification, returning relevant information of the target resource to the client.

[0006] According to one aspect of this application, a resource access apparatus is deployed on a server. The apparatus includes: an acquisition module, configured to receive a resource access request initiated by a user during the access to a client due to obtaining target information; the resource access request is used to indicate the target resource that the user requests to access; a parsing module, configured to parse the target information in the resource access request; a verification module, configured to, if an access token is parsed from the target information, perform identity authentication and permission verification on the user according to the access token to determine whether the user can be authorized to access the target resource; a return module, configured to, if the user passes the verification, return relevant information of the target resource to the client.

[0007] According to one aspect of the present application, a resource access system includes a server and a client. Among them, the client is used to store the user's identity information and permission information as the target information, and encapsulate the target information based on the acquisition of the target information; send the resource access request to the server based on the encapsulation of the target information; the server is used to receive the resource access request initiated by the user due to obtaining the target information during the access to the client; the resource access request is used to indicate the target resource that the user requests to access; parse the target information in the resource access request; if an access token is parsed from the target information, perform identity verification and permission verification on the user according to the access token to determine whether the user can be authorized to access the target resource; if the user passes the verification, return the relevant information of the target resource to the client.

[0008] According to one aspect of the present application, an electronic device includes at least one processor and at least one memory. Among them, a computer program is stored on the memory, and when the computer program is executed by the processor, the resource access method described above is implemented.

[0009] According to one aspect of the present application, a storage medium stores a computer program, and when the computer program is executed by one or more processors, the resource access method described above is implemented.

[0010] According to one aspect of the present application, a computer program product includes a computer program, and when the computer program is executed by one or more processors, the resource access method described above is implemented.

[0011] The beneficial effects brought by the technical solution provided by the present application are as follows:

[0012] In the above technical solution, by using the access token technology, security problems such as malicious attacks and password leakage can be effectively prevented. Further, on the server side, by performing identity verification and permission verification on the access token, the user's identity verification and authorization (authorizing access to the target resource) process can be integrated together through the access token, which not only improves security but also simplifies the verification process. Thus, the development process is simplified. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following will briefly introduce the drawings required for the description of the embodiments of the present application. Obviously, the drawings in the following description are only some embodiments of the present application, and those skilled in the art can obtain other drawings without creative efforts based on these drawings.

[0014] Figure 1is a schematic diagram of the implementation environment involved in the present application;

[0015] Figure 2 is a hardware structure diagram of an electronic device shown according to an exemplary embodiment;

[0016] Figure 3 is a flowchart of a resource access method shown according to an exemplary embodiment;

[0017] Figure 4 is Figure 2 a flowchart of the steps before step 310 in the corresponding embodiment in one embodiment;

[0018] Figure 5 is Figure 3 a flowchart of step 410 in the corresponding embodiment in one embodiment;

[0019] Figure 6 is Figure 2 a flowchart of step 330 in the corresponding embodiment in one embodiment;

[0020] Figure 7 is Figure 2 a flowchart of step 350 in the corresponding embodiment in one embodiment;

[0021] Figure 8 is a specific implementation schematic diagram of a resource access method in an application scenario;

[0022] Figure 9 is a structural block diagram of a resource access device shown according to an exemplary embodiment;

[0023] Figure 10 is a structural block diagram of an electronic device shown according to an exemplary embodiment. Detailed Description of the Specific Embodiment

[0024] The embodiments of the present application will be described in detail below. The examples of the embodiments are shown in the accompanying drawings, where the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described by referring to the accompanying drawings are exemplary and are only used to explain the present application and should not be construed as limiting the present application.

[0025] Those skilled in the art can understand that, unless specifically stated otherwise, the singular forms "a", "an", "the" and "said" used herein may also include the plural forms. It should be further understood that the term "comprising" used in the specification of the present disclosure means the presence of the stated features, integers, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components and / or their groups. It should be understood that when we say that an element is "connected" or "coupled" to another element, it can be directly connected or coupled to other elements, or there may also be intermediate elements. In addition, the "connection" or "coupling" used herein may include wireless connection or wireless coupling. The term "and / or" used herein includes all or any unit and all combinations of one or more associated listed items.

[0026] As described above, the user needs to provide a username and password for authentication, and then the server will decide whether to allow access to the corresponding resources according to the user's permissions, which has security risks.

[0027] Specifically, in the user's access operation, during the process of using the username and password for authentication, the username and password need to be sent to the server. If the user triggers the access operation multiple times, then the frequency of the password transmitted in the network will increase, thereby increasing the risk of password leakage, and there is also a possibility of brute force password cracking.

[0028] As can be seen from the above, there are still defects in the related technology that the process of resource access is not secure enough.

[0029] Therefore, the resource access method provided by this application can effectively improve the accuracy of resource access. Correspondingly, this resource access method is applicable to a resource access device, and this resource access device can be deployed on an electronic device, and this electronic device can be a computer device configured with a von Neumann architecture. For example, this computer device includes a desktop computer, a laptop computer, a server, etc.

[0030] To make the purpose, technical solutions and advantages of this application clearer, the following will further describe the embodiments of this application in detail with reference to the accompanying drawings.

[0031] Figure 1 It is a schematic diagram of an implementation environment involved in a resource access method. It should be noted that this implementation environment is only an example adapted to the present invention and cannot be considered as providing any limitation to the scope of use of the present invention.

[0032] This implementation environment includes a client 110 and a server 130.

[0033] Specifically, the client 110 can be the port where the user triggers a resource access request, such as a browser, an application, etc.

[0034] The server 130 can be an electronic device such as a desktop computer, a laptop, a server, etc., or a computer cluster composed of multiple servers, or even a cloud computing center composed of multiple servers. Among them, the server 130 is used to provide background services. For example, the background services include but are not limited to resource access services, etc.

[0035] A network communication connection is pre-established between the server 130 and the client 110 by means of wire or wireless, etc., and data transmission between the server 130 and the client 110 is realized through this network communication connection. The transmitted data includes but is not limited to: target resources, etc.

[0036] In an application scenario, a resource access system includes a server and a client;

[0037] Among them, the server is used to receive a resource access request initiated by the user due to obtaining target information during the access to the client; the resource access request is used to indicate the target resource that the user requests to access; parse the target information in the resource access request; if an access token is parsed from the target information, then perform identity verification and permission verification on the user according to the access token to determine whether the user can be authorized to access the target resource; if the user passes the verification, then return the relevant information of the target resource to the client.

[0038] The client is used to store the user's identity information and permission information as target information, and encapsulate the target information based on the acquisition of the target information; send a resource access request to the server based on the encapsulation of the target information.

[0039] Please refer to Figure 2 , Figure 2 is a hardware structure diagram of an electronic device shown according to an exemplary embodiment. This electronic device is applicable to Figure 1 the server 130 in the implementation environment shown in

[0040] It should be noted that this electronic device is only an example adapted to the present application and cannot be considered as providing any limitation to the scope of use of the present application. This electronic device cannot be interpreted as requiring dependence on or necessarily having Figure 2 one or more components in the exemplary electronic device 200 shown in

[0041] The hardware structure of the electronic device 200 may vary greatly due to different configurations or performances, such as Figure 2As shown, the electronic device 200 includes: a power supply 210, an interface 230, at least one memory 250, and at least one central processing unit (CPU) 270.

[0042] Specifically, the power supply 210 is used to provide operating voltage for each hardware device on the electronic device 200.

[0043] The interface 230 includes at least one wired or wireless network interface 231 for interacting with external devices. For example, for the interaction between the client 110 and the server 130 in the illustrated implementation environment. Figure 1 As shown in the illustrated implementation environment.

[0044] Of course, in other examples adapted to this application, the interface 230 may further include at least one serial-to-parallel conversion interface 233, at least one input / output interface 235, and at least one USB interface 237, etc., as Figure 2 shown, and this is not specifically limited herein.

[0045] The memory 250, as a carrier for resource storage, can be a read-only memory, a random access memory, a magnetic disk, or an optical disc, etc. The resources stored thereon include an operating system 251, application programs 253, and data 255, etc., and the storage method can be temporary storage or permanent storage.

[0046] Among them, the operating system 251 is used to manage and control each hardware device and application program 253 on the electronic device 200 to enable the central processing unit 270 to perform operations and processing on the massive data 255 in the memory 250. It can be Windows ServerTM, Mac OS XTM, UnixTM, LinuxTM, FreeBSD TM, etc.

[0047] The application program 253 is a computer program formed by computer-readable instructions that complete at least one specific task based on the operating system 251. It may include at least one module ( Figure 2 not shown), and each module can respectively contain corresponding computer-readable instructions. For example, the resource access device can be regarded as an application program 253 deployed on the electronic device 200.

[0048] The data 255 can be photos, pictures, etc. stored on a magnetic disk, or target information, target resources, etc., and is stored in the memory 250.

[0049] The central processing unit 270 may include one or more processors and is configured to communicate with the memory 250 via at least one communication bus to read the computer program stored in the memory 250, thereby implementing the operation and processing of the massive data 255 in the memory 250. For example, the resource access method is completed in the form of the central processing unit 270 reading the application program 253 stored in the memory 250.

[0050] In addition, this application can also be implemented by hardware circuits or a combination of hardware circuits and software. Therefore, the implementation of this application is not limited to any specific hardware circuit, software, or the combination of both.

[0051] Please refer to Figure 3 , an embodiment of this application provides a resource access method, which is applicable to an electronic device. For example, the electronic device may be Figure 1 the server 130 in the shown implementation environment, and the hardware structure of the electronic device may be as Figure 2 shown.

[0052] In the following method embodiments, for the convenience of description, the execution subject of each step of the method is taken as an example of an electronic device for illustration, but this is not a specific limitation.

[0053] As Figure 3 shown, the method may include the following steps:

[0054] Step 310, receiving a resource access request initiated by a user for obtaining target information during the process of accessing the client.

[0055] Among them, the resource access request is used to indicate the target resource that the user requests to access. The resource access request includes the user's target information. The resource access request is a request sent by the client to the server. For example, an HTTP request. The access request can be used to request a specific resource or perform a specific operation. Specifically, the access request may include a request header, a request method, a request path, etc. The request header may be Authorization, the request path may refer to the path of the target resource requested, and the request method may refer to specific operations such as get, put, post, delete, etc., which are not specifically limited herein.

[0056] Regarding the client, it may refer to an application program or device that sends the resource access request, such as a mobile application, a browser, etc., which are not specifically limited herein.

[0057] It should be noted that after the user triggers the resource access request through the client, corresponding target information will be generated. The target information may include the user's identity information and permission information.

[0058] In a possible implementation manner, as Figure 4As shown, the following steps may also be included before step 310:

[0059] Step 410, the client stores the user's identity information and permission information as target information, and encapsulates the target information based on the acquisition of the target information.

[0060] Among them, the target information includes identity information and permission information, and the user's identity information may include a user account and a user password.

[0061] First of all, it should be noted that before the user triggers a resource access request through the client, the user needs to input a user account and a user password on the client for subsequent identity verification. However, if the user account and user password are directly transmitted to the server, then if attacked during the transmission process, there will be a problem of leakage of the user account and user password.

[0062] Based on this, in order to avoid the above situation, the target information can be encapsulated according to the set rules to generate an access token, and in the subsequent process of generating a resource access request, the resource access request carries the access token.

[0063] In a possible implementation, the HttpUser class is used to obtain the target information. The HttpUser class contains a User property, that is, the user's user account or user ID, and it returns a UserConfig object, which contains the target information.

[0064] In another possible implementation, the UserConfig object is stored in the target cache. The target cache refers to the cache system used by the client to store the target object UserConfig. The target cache can be implemented by distributed cache systems such as Redis and Memcached, and no specific limitation is made here. The reading speed of the target cache is much faster than database query, and it can reduce the access pressure on the database through the target cache.

[0065] For example, in the user interface of the application, the user can enter a username and password to log in. After successful login, the application will use the HttpUser class to obtain the target information, use the User property included in the HttpUser class to obtain the UserConfig object in the target cache, and display it in the user interface.

[0066] Among them, the set rules are used to generate the corresponding access token. The access token can be a JWT token, an OAuthToken token, etc. The specific set rules are related to the corresponding token type, and different token types have different set rules.

[0067] The access token may include the user's identity identifier (such as user ID, username), access permissions (such as user role, permission list). In addition, it may also include other claims (such as token expiration period, token issuer), etc., which are not specifically limited herein.

[0068] Furthermore, the composition of the access token may include a header, a payload part, and a signature part. Among them, the header includes the token type and the signature algorithm; the payload includes the identity identifier (such as sub), user role (such as role), access permissions, expiration period (such as exp), etc. The signature part is to sign the header and the payload part using a key to prevent tampering.

[0069] It should be supplemented that regarding the expiration period, it can be configured according to the user role (role). For example, if the user role is admin (administrator), then an expiration period of 1 hour can be configured for it; if the user role is user (ordinary user), then an expiration period of 30 minutes can be configured for it, which is not specifically limited herein.

[0070] In addition, it can also be configured according to the security level. For example, an expiration period of 5 minutes is configured for high-security-level operations, and an expiration period of 30 minutes is configured for ordinary operations, which is not limited herein.

[0071] Specifically, regarding the setting rules, in a possible implementation, as Figure 5 shown, step 450 may further include the following steps:

[0072] Step 451, configure the token type and signature algorithm of the access token for the access token to obtain the header.

[0073] Among them, the access token can be a JWT token, an OAuth Token token, etc. The signature algorithm is used to encrypt the header and the payload part, and it can be the HS256 algorithm, the RS256 algorithm, etc., which are not specifically limited herein.

[0074] Step 453, configure the claims for the access token based on the target information to obtain the payload part.

[0075] Regarding the payload part, it can include user information and other claims. Among them, the user information can be obtained according to the identity information in the target information. For example, sub: user ID, name: username, role: user role (such as admin, user).

[0076] Regarding the claim configuration, it is a key-value pair in the payload part, used to describe information such as user identity, permissions, token attributes, etc. Specifically, if the claim configuration is a registered claim, that is, a claim defined by the JWT standard, it can include iss (Issuer), sub (Subject), aud (Audience), exp (Expiration Time), nbf (Not Before), iat (Issued At), and jti (JWT ID).

[0077] Furthermore, users can also customize the claim configuration, but they need to avoid conflicts with the registered claims; they can also perform private claim configuration for custom claims in specific business scenarios, and of course, they also need to avoid conflicts with the registered claims, and no specific restrictions are made here.

[0078] In a possible implementation, using the Registered Claims method, the information needed can be encapsulated in custom fields.

[0079] Step 455: Encode and splice the header and the payload part respectively to obtain intermediate information.

[0080] Regarding encoding, Base64Url can be used to encode the header and the payload part respectively, and then use the "." symbol to splice the encoded header and payload part to obtain the intermediate information.

[0081] Step 457: Sign the intermediate information using a signature algorithm to obtain the signature part.

[0082] Then, the signature algorithm specified in the header can be used to sign the intermediate information to obtain the signature part.

[0083] Step 459: Package based on the header, the payload part, and the signature part to obtain the access token.

[0084] Specifically, the packaging process can include that the client encodes the header, the payload part, and the signature part obtained in the above steps respectively. This encoding needs to be consistent with the encoding type in Step 455, and then use the "." symbol to splice the encoded header, payload part, and signature part to obtain the access token.

[0085] Through the above process, the signature algorithm is used for signing to ensure the integrity and authenticity of the access token and prevent tampering; by setting the expiration period of the access token, the abuse of long-term valid access tokens is prevented; it can also dynamically declare configurations to meet the requirements of different business scenarios; the access rules corresponding to the token type are used to ensure compatibility with other systems; in addition, by embedding the identity information and permission information into the access token, in subsequent access requests, the server can extract the user's identity information and permission information from the access token without receiving the user account or user password.

[0086] Step 430: Send a resource access request to the server based on the encapsulation of the target information.

[0087] It can be understood that after encapsulating the target information, an access token can be obtained, and the access token can be regarded as the encrypted target information.

[0088] In a possible implementation, authorization header information can be generated based on the access token, such as (Authorization: Bearer <token>) The authorization header information is concatenated with the resource access request so that the resource access request carries the access token.

[0089] Through the above process, an access token is generated based on the target information. The access token contains all necessary information (such as user identity, permissions). The client sends the encapsulated target information (access token) to the server so that the server can subsequently extract the access token from the target information and verify it.

[0090] In a possible implementation, the above method further includes the following steps: If the access token is not obtained after parsing the target information; or, if the access token fails the identity verification or permission verification; then an access failure message is returned to the client.

[0091] Specifically, the absence of an access token in the target information may be due to the client not correctly encapsulating the target information.

[0092] In addition, the access token failing the identity verification may be due to the access token being invalid or expired, or may be due to an incorrect user account or user password.

[0093] Furthermore, the access token failing the permission verification may be due to insufficient access permissions of the user.

[0094] All of the above situations can indicate that the user's current access is illegal. Therefore, the corresponding target resource cannot be returned to the client, and an access failure message needs to be returned to the client. Among them, the access failure message can set different error codes according to different situations to prompt the user to handle it, so as to successfully achieve access.

[0095] For example, no access token provided: return 401 Unauthorized, prompt no access token provided: return 401 Unauthorized, prompt insufficient access permissions: return 403 Forbidden, prompt the user to contact the administrator, which is not limited here.

[0096] Through the above process, the security of the system and the user experience can be significantly improved, and at the same time, it is convenient for problem troubleshooting and auditing.

[0097] Step 330, parse the target information in the resource access request.

[0098] Based on this, the server can parse the target information to extract the access token in the target information.

[0099] In a possible implementation, the target information can be parsed using the detection request header. Specifically, the GetUserInfoAsync method is used to obtain the target information. The GetUserInfoAsync method first checks whether TokenHelper.GetToken() returns a null value. If it is a null value, it indicates that there is no access token in the target information, and then an empty UserConfig object is returned. If it is a non-null value, the access token in the target information is extracted and a valid access token is returned.

[0100] In a possible implementation, as Figure 6 shown, step 330 includes the following steps:

[0101] Step 331, perform validity detection on the access token.

[0102] In a possible implementation, if the access token returned by the above TokenHelper.GetToken() is a valid access token, then use HttpContext.Request.Headers["Authorization"] to obtain the authorization header information and parse it into a JwtUserModel object.

[0103] Among them, the JwtUserModel object can include UserId, the unique identifier of the user (corresponding to the sub claim of JWT); Username, the name or display name of the user (corresponding to the name claim of JWT), Role, the role of the user (such as admin, user, corresponding to the role claim of JWT), Issuer, the authorization server identifier (corresponding to the iss claim of JWT), the validity period (corresponding to the exp claim of JWT), etc., which are not specifically limited here.

[0104] Then, based on this, the validity detection can include the following steps: if the authorization server identifier indicated by the access token does not match the server; or, if the validity period indicated by the access token exceeds the valid period; or, if the signature indicated by the access token does not meet the set conditions, then the access token fails the validity detection.

[0105] Specifically, if the authorization server identifier indicated by the access token does not match the server, it can indicate that the issuer (iss) of the access token is inconsistent with the issuer configured on the server; if the validity period indicated by the access token exceeds the valid period, it can indicate that the expiration time (exp) of the token has exceeded the current time and the access token has expired; if the signature indicated by the access token does not meet the set conditions, it can mean that the signature of the access token does not match the signature key of the server, indicating that the access token may have been tampered with; if the user indicated by the access token is not the target user, there may be a problem that the access token is used by an illegal user.

[0106] Of course, the administrator can also configure more custom rules for the validity detection to adapt to different application scenarios.

[0107] Step 333, if the access token passes the validity detection, authenticate and authorize the user.

[0108] It should be noted that in the case where the access token fails to pass the validity detection, authentication and authorization can be skipped, and this access can be stopped to reduce the operation steps.

[0109] Through the above process, the validity of the access token is checked. By verifying the issuer (iss), validity period (exp), and signature of the access token, the legality and authenticity of the token are ensured to ensure the security of the access. Moreover, when the access token fails to pass the validity detection, subsequent operations are stopped, reducing unnecessary resource consumption and avoiding invalid business logic processing.

[0110] Step 350, if an access token is parsed from the target information, authenticate and authorize the user according to the access token to determine whether the user can be authorized to access the target resource.

[0111] In a possible implementation, as Figure 7 shown, step 350 may further include the following steps:

[0112] Step 351, extract the identity information and permission information of the user based on the access token.

[0113] As mentioned before, the access token is obtained by encapsulating the target information, and the target information includes the identity information and permission information of the user. Then, by decrypting the access token, the identity information and permission information can be extracted.

[0114] Step 353, if the identity information indicates that the user's identity is the target user, the user passes the identity authentication.

[0115] Regarding authentication, it may include verifying whether the user account and user password in the user login information are legal. Specifically, it may include whether the user account exists, whether the user password is correct, whether the security code matches, and so on.

[0116] Step 355, if the permission information indicates that the user is granted access to the target resource, the user passes the permission verification.

[0117] In a possible implementation, step 355 includes the following steps: determining the user's access permission according to the permission information; matching the access permission corresponding to the user with the permission corresponding to the target resource. If the match is successful, the user is granted access to the target resource.

[0118] First of all, it should be noted that the server can also configure the user after the user completes user registration, including the configuration of access permissions. For example, setting the resource permission list for different users, which is not limited here.

[0119] Regarding matching, it means that the access permission corresponding to the user meets the permissions required to access the target resource. It can be understood that if the access permission of the user corresponds to all the permissions required by the target resource, the target resource requested by the user can be returned to the client.

[0120] For example, if the access token indicates that the user's user role is a manager, then the manager can have the permission to access all resources, that is, the user's access permission meets the permissions required by the target resource.

[0121] Step 370, if the user passes the verification, return the relevant information of the target resource to the client.

[0122] Among them, the target resource is the resource that the user expects to access. The target resource can be determined based on the resource access request. The target resource can be a picture, a website, data, etc., which is not limited here.

[0123] Through the above process, by using the access token technology, security problems such as malicious attacks and password leakage can be effectively prevented. Further, on the server side, by performing identity verification and permission verification on the access token, the user's identity verification and authorization (authorizing access to the target resource) process can be integrated together through the access token, which not only improves security but also simplifies the verification process. Thus, the development process is simplified.

[0124] Figure 7 It is a specific implementation schematic diagram of a resource access method in an application scenario.

[0125] Through step 801, if the client detects the user's access operation, a corresponding resource access request is generated according to the access operation.

[0126] In step 803, the client obtains UserConfig from the Redis cache based on the user account and user password.

[0127] Specifically, the RcpCache interface defines the operation methods of the Redis cache. The RedisCache class implements the RcpCache interface and uses Redis as the cache to store the UserConfig class.

[0128] In step 805, encapsulation is performed based on UserConfig to obtain the target information, and the target information is sent to the server.

[0129] Specifically, an authorization header information can be generated based on the access token obtained by encapsulating UserConfig. The authorization header information is concatenated with the resource access request so that the resource access request carries the access token.

[0130] In step 807, the server uses the detection request header to parse the target information to obtain the JwtUserModel.

[0131] Specifically, the detection request header uses the GetUserInfoAsync method to obtain the target information. The GetUserInfoAsync method first checks whether TokenHelper.GetToken() returns a null value. If it is a null value, it indicates that there is no access token in the target information, and then an empty UserConfig object is returned. If it is a non-null value, the access token in the target information is extracted and a valid access token is returned. If the TokenHelper.GetToken() returns a valid access token, the authorization header information is obtained using HttpContext.Request.Headers["Authorization"] and parsed into a JwtUserModel object.

[0132] In step 809, the Proving method is used to verify the validity of the JwtUserModel.

[0133] Specifically, a TokenValidationParameters object is first created to define the verification rules and set the verification parameters, such as the authorization server identifier matching the server, the expiration date exceeding the valid period, the signature meeting the set conditions, the user not being the target user, etc. Then, the JwtSecurityTokenHandler class is used to verify the JwtUserModel. If the JwtUserModel is valid, true is returned and step 803 is executed; otherwise, false is returned.

[0134] Through step 811, the identity information and permission information of the user are extracted based on the access token. If the identity information indicates that the user's identity is the target user, the user passes the identity authentication. If the permission information indicates that the user is granted access to the target resource, the user passes the permission authentication.

[0135] In this application scenario, a user authentication and authorization system is implemented. By using JWT technology and Redis cache, security issues such as malicious attacks and password leakage can be effectively prevented; by using Redis cache, UserConfig can be quickly obtained, thus improving the system's response speed and concurrent processing ability; by using JWT technology, the user's identity authentication and authorization processes can be integrated together, thus simplifying the development process.

[0136] In addition, JWT technology does not rely on passwords for authentication. After the user logs in successfully, the client generates a JWT token and returns it to the server. The server uses this token for identity authentication in subsequent requests, without repeatedly transmitting the password, reducing the frequency of password transmission over the network and lowering the risk of password leakage.

[0137] Then, during subsequent access, the server only needs to verify the validity of the JWT token (such as signature, expiration date, etc.), without needing to receive the username and password, avoiding the possibility of brute-forcing the password. Of course, since the JWT token is encrypted and signed, even if an attacker intercepts the JWT token, due to the token being encrypted and signed, the attacker cannot forge or tamper with the token content.

[0138] Furthermore, JWT tokens usually have a relatively short expiration date (such as from a few minutes to a few hours) and can be dynamically updated through a refresh token mechanism. Even if an attacker obtains the JWT token through a phishing attack, the JWT token will soon expire.

[0139] It should be understood that although the steps in the flowchart of the accompanying drawings are shown in sequence according to the arrows, these steps do not necessarily have to be executed in the order indicated by the arrows. Unless there is a clear indication in this article, the execution of these steps has no strict order limit and can be executed in other orders. Moreover, at least some of the steps in the flowchart of the accompanying drawings may include multiple sub-steps or multiple stages. These sub-steps or stages do not necessarily have to be executed at the same time, but can be executed at different times, and their execution order does not necessarily have to be sequential, but can be executed alternately or in turn with at least a part of other steps or sub-steps or stages of other steps.

[0140] The following is an embodiment of the device of the present application, which can be used to execute the resource access method involved in the present application. For details not disclosed in the embodiment of the device of the present application, please refer to the method embodiment of the resource access method involved in the present application.

[0141] Please refer to Figure 9 , in the embodiments of the present application, a resource access device 900 is provided, including but not limited to: an acquisition module 910, a parsing module 930, a verification module 950, and a return module 970.

[0142] Among them, the acquisition module 910 is used to receive a resource access request initiated by a user for obtaining target information during the access to the client; the resource access request is used to indicate the target resource that the user requests to access.

[0143] The parsing module 930 is used to parse the target information in the resource access request.

[0144] The verification module 950 is used to, if an access token is parsed from the target information, perform identity verification and permission verification on the user according to the access token to determine whether the user can be authorized to access the target resource.

[0145] The return module 970 is used to, if the user passes the verification, return the relevant information of the target resource to the client.

[0146] It should be noted that when the above-mentioned resource access device provided by the above embodiments performs resource access, only the division of the above functional modules is used for illustration. In actual applications, the above functions can be allocated to different functional modules according to needs, that is, the internal structure of the resource access device will be divided into different functional modules to complete all or part of the functions described above.

[0147] In addition, the above-mentioned resource access device provided by the above embodiments and the embodiments of the resource access method belong to the same concept. The specific ways in which each module performs operations have been described in detail in the method embodiments and will not be repeated here.

[0148] Please refer to Figure 10 , in the embodiments of the present application, an electronic device 4000 is provided. The electronic device 4000 may include: a desktop computer, a laptop computer, a server, etc.

[0149] In Figure 10 , the electronic device 4000 includes at least one processor 4001 and at least one memory 4003.

[0150] Among them, the data interaction between the processor 4001 and the memory 4003 can be realized through at least one communication bus 4002. The communication bus 4002 may include a path for transmitting data between the processor 4001 and the memory 4003. The communication bus 4002 can be a PCI (Peripheral Component Interconnect) bus, an EISA (Extended Industry Standard Architecture) bus, or the like. The communication bus 4002 can be divided into an address bus, a data bus, a control bus, etc. For the sake of simplicity of representation, only a thick line is used in the figure, but it does not mean that there is only one bus or one type of bus.

[0151] Optionally, the electronic device 4000 may further include a transceiver 4004, and the transceiver 4004 can be used for data interaction between the electronic device and other electronic devices, such as data sending and / or data receiving, etc. It should be noted that in practical applications, the transceiver 4004 is not limited to one, and the structure of the electronic device 4000 does not constitute a limitation on the embodiments of the present application.

[0152] The processor 4001 can be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute various exemplary logic blocks, modules, and circuits described in combination with the disclosure of the present application. The processor 4001 can also be a combination that realizes computing functions, such as a combination including one or more microprocessors, a combination of a DSP and a microprocessor, etc.

[0153] The memory 4003 can be a ROM (Read Only Memory), or other types of static storage devices that can store static information and instructions, a RAM (Random Access Memory), or other types of dynamic storage devices that can store information and instructions. It can also be an EEPROM (Electrically Erasable Programmable Read Only Memory), a CD-ROM (Compact Disc Read Only Memory), or other optical disc storage, optical disc storage (including compact discs, laser discs, optical discs, digital versatile discs, Blu-ray discs, etc.), magnetic disk storage media, or other magnetic storage devices, or any other medium that can be used to carry or store a computer program in the form of instructions or data structures and can be accessed by the electronic device 400, but is not limited thereto.

[0154] A computer program is stored on the memory 4003, and the processor 4001 can read the computer program stored in the memory 4003 through the communication bus 4002.

[0155] The computer program is executed by one or more processors 4001 to implement the resource access method in the above embodiments.

[0156] In addition, an embodiment of the present application provides a storage medium on which a computer program is stored, and the computer program is executed by one or more processors to implement the resource access method as described above.

[0157] An embodiment of the present application provides a computer program product, including a computer program, and the computer program is executed by one or more processors to implement the resource access method as described above.

[0158] Compared with the related art, by using the access token technology, security problems such as malicious attacks and password leakage can be effectively prevented. Further, on the server side, by authenticating and authorizing the access token, the user's authentication and authorization (authorizing access to the target resource) process can be integrated through the access token, which not only improves security but also simplifies the verification process. Thus, the development process is simplified.

[0159] The above are only partial embodiments of the present application. It should be noted that for those of ordinary skill in the art, without departing from the principle of the present application, several improvements and refinements can be made, and these improvements and refinements should also be regarded as the protection scope of the present application.< / token>

Claims

1. A resource access method, characterized in that: Executed by the server, the method includes: Receiving a resource access request initiated by a user in the process of accessing a client in order to obtain target information; the resource access request is used to indicate a target resource that the user requests to access; Parsing the target information in the resource access request; If an access token is obtained by parsing the target information, the user's identity and authority are verified according to the access token to determine whether the user is authorized to access the target resource; If the user passes the verification, the relevant information of the target resource is returned to the client.

2. The method according to claim 1, characterized in that The performing identity authentication and authority verification on the user according to the access token includes: Extracting the identity information and permission information of the user based on the access token; If the identity information indicates that the user is a target user, the user passes the identity authentication; If the permission information indicates that the user is authorized to access the target resource, the user passes the permission verification.

3. The method according to claim 2, characterized in that If the permission information indicates that the user is authorized to access the target resource, the user passes the permission verification, including: Determining the access rights of the user according to the permission information; The access rights corresponding to the user are matched with the rights corresponding to the target resource. If the match succeeds, the user is granted access to the target resource.

4. The method according to claim 1, characterized in that Before performing identity authentication and authority verification on the user according to the access token, the method further includes: Performing validity check on the access token; If the access token passes the validity check, the user's identity and authority are verified.

5. The method according to claim 4, characterized in that The checking the validity of the access token includes: If the authorization server identifier indicated by the access token does not match the server; or, If the validity period indicated by the access token exceeds the validity period; or, If the signature indicated by the access token does not meet the set conditions, the access token fails the validity check.

6. The method according to claim 1, characterized in that The method further comprises: If the target information is parsed and the access token is not obtained; or, If the access token fails to pass identity authentication or authority verification, an access failure message is returned to the client.

7. The method according to any one of claims 1 to 6, characterized in that: The receiving of a resource access request initiated by a user for obtaining target information during access to a client includes: The client stores the identity information and authority information of the user as the target information, and encapsulates the target information based on the acquisition of the target information; The resource access request is sent to the server based on the encapsulation of the target information.

8. A resource access device, characterized in that: Deployed on the server, the device includes: The acquisition module is used to receive a resource access request initiated by a user in the process of accessing a client in order to obtain target information; the resource access request is used to indicate a target resource that the user requests to access; A parsing module, used for parsing the target information in the resource access request; A verification module, for performing identity authentication and authority verification on the user according to the access token if an access token is obtained by parsing the target information, so as to determine whether the user is authorized to access the target resource; The return module is used to return the relevant information of the target resource to the client if the user passes the verification.

9. A resource access system, characterized in that: The system includes a server and a client; The client is used to store the identity information and permission information of the user as the target information, and encapsulate the target information based on the acquisition of the target information; and send the resource access request to the server based on the encapsulation of the target information; The server is used to receive a resource access request initiated by a user in the process of accessing a client in order to obtain target information; the resource access request is used to indicate the target resource that the user requests to access; the target information in the resource access request is parsed; if an access token is obtained from the target information, the user is authenticated and authorized based on the access token to determine whether the user is authorized to access the target resource; if the user passes the verification, the relevant information of the target resource is returned to the client.

10. An electronic device comprising at least one processor and at least one memory, wherein: The memory stores a computer program, wherein the computer program, when executed by the processor, implements the resource access method according to any one of claims 1 to 7.

Images