A network request verification and authentication method and device based on a trusted node

Abstract

The application aims to provide a network request verification and authentication method and device based on a trusted node. In a non-proxy mode, the target network request is initiated by a request end to a service node, or in a proxy mode, the target network request is initiated by a trusted node trusted by a requested end to a service node. The trusted node and the service node both store the authority for authenticating the target network service, and the trusted node provides authorization for the initiated target network request. The service node verifies and authenticates the requested target network request, prevents tampering and illegal request execution, thereby ensuring the security of all network requests, and can be applied to actual application scenarios with high security.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a network request verification and authentication method and device based on a trusted node. Background Technology

[0002] In existing technologies, solutions for verifying and authenticating network requests include Single Sign-On (SSO), identity access management, zero-trust security, and microservice authentication. In single sign-on (SSO), traditional SSO methods use global and local sessions for authentication. The SSO authentication center only handles basic user credential authentication (e.g., username / password). Commonly used SSO solutions include OIDC / SAML / CAS / OAuth2 / Distributed Session / JWT. Traditional SSO methods often rely on browser sessions and redirects, making them unsuitable for other types of requests. Furthermore, the verification level is session-level, failing to refine access control granularity to the request or resource level. In identity access management, mechanisms control access to software and hardware resources, but are rarely used for authenticating network service interfaces. In zero-trust security, current zero-trust security systems primarily focus on internal network host security, but are rarely used for authenticating network service interfaces. In microservice authentication, not only is user authentication (e.g., using SSO, authentication services) required, but access permissions for each microservice to other services also need to be controlled. Currently, the main approach is to use gateways or service meshes (SideCars) for microservice access control. Therefore, how to perform general, fine-grained configuration, flexible control, and balance security and performance authentication for network requests has become a major research topic in the industry. Summary of the Invention

[0003] One objective of this application is to provide a network request verification and authentication method and device based on a trusted node, which can perform rigorous verification and authentication of network requests, prevent tampering and illegal request execution, thereby ensuring the security of all network requests.

[0004] According to one aspect of this application, a network request verification and authentication method based on a trusted node is provided, applied to a service node, wherein the method includes:

[0005] The target network request is received by the requesting end or the trusted node through the interface address, carrying the token and the identifier of the trusted node. The token is generated by the trusted node after receiving the first request from the requesting end carrying the identity and permission credentials of the visitor who is to initiate the target network request, the information parameters of the target network request, and the identifier of the requested service node through the token production interface, and after verifying that the visitor has the permission to execute the target network request in the service node.

[0006] The token is carried to the token consumption interface corresponding to the identifier of the trusted node, and a second request is sent to the trusted node so that the trusted node can verify whether the token is valid through the token consumption interface.

[0007] Receive the validity response result of the token returned by the trusted node, the information parameters corresponding to the token, and the accessor's identity and permission credentials;

[0008] The validity response of the token, the information parameters returned by the trusted node, and the accessor's identity and authorization credentials are verified and authenticated.

[0009] If both verification and authentication are successful, the operation corresponding to the target network request is executed, and the execution result is returned to the requesting end or the trusted node so that the trusted node forwards the execution result to the requesting end.

[0010] According to another aspect of this application, a network request verification and authentication method based on a trusted node is also provided, applied to a trusted node, wherein the method includes:

[0011] The token production interface receives a first request from the requesting end, which carries the identity and authorization credentials of the visitor who is to initiate the target network request, the information parameters of the target network request, and the identifier of the requested service node.

[0012] Verify whether the visitor has the permission to execute the target network request on the service node. If so, generate a token and send it to the requesting end, and store the information parameters and the visitor's identity and permission credentials accordingly. After receiving the token, the requesting end sends the token and the identifier of the trusted node to the interface address of the service node to initiate a target network request, so that the service node sends a second request to the token consumption interface corresponding to the identifier of the trusted node.

[0013] The system receives a second request from the service node carrying the token through the token consumption interface, verifies whether the token is valid, and if so, retrieves the stored information parameters corresponding to the token and the visitor's identity and permission credentials and returns them to the service node.

[0014] The service node verifies and authenticates the token based on its validity response, the corresponding information parameters, and the visitor's identity and authorization credentials. When both verification and authentication are successful, the service node executes the operation corresponding to the target network request and sends the execution result to the requesting end.

[0015] According to another aspect of this application, a network request verification and authentication method based on a trusted node is also provided, applied to the requesting end, wherein the method includes:

[0016] A first request is sent to the token production interface of the trusted node, carrying the identity and authorization credentials of the visitor who is to initiate the target network request, the information parameters of the target network request, and the identifier of the service node to be requested, so that the trusted node can verify whether the visitor has the permission to execute the target network request in the service node. If so, a token is generated and sent to the requesting party, and the information parameters and the visitor's identity and authorization credentials are stored accordingly.

[0017] The system sends a target network request to the service node, carrying the token and the identifier of the trusted node. In response to the target network request, the service node sends a second request to the token consumption interface corresponding to the identifier of the trusted node, carrying the token. The trusted node verifies the validity of the token through the token consumption interface. If the token is valid, the node retrieves the stored information parameters corresponding to the token and the visitor's identity and permission credentials and returns them to the service node.

[0018] The service node receives the execution result returned by the service node, wherein the execution result is obtained by the service node performing verification and authentication based on the validity response result of the token, the corresponding information parameters and the identity and authorization credentials of the visitor, and executing the operation corresponding to the target network request when both verification and authentication are successful.

[0019] Compared with the prior art, in this embodiment, the service node receives a target network request sent by a requesting end or a trusted node carrying the token and the identifier of the trusted node through an interface address. The token is generated by the trusted node after receiving a first request from the requesting end carrying the identity and authorization credentials of the visitor who intends to initiate the target network request, the information parameters of the target network request, and the identifier of the requesting service node, through a token production interface, and verifying that the visitor has the permission to execute the target network request on the service node. The trusted node then sends a second request carrying the token to the token consumption interface corresponding to the identifier of the trusted node, so that the trusted node can verify the validity of the token through the token consumption interface. The trusted node receives a validity response result for the token, the information parameters corresponding to the token, and the visitor's identity and authorization credentials returned by the trusted node. The trusted node verifies and authenticates the validity response result, the information parameters returned by the trusted node, and the visitor's identity and authorization credentials. If both verification and authentication are successful, the trusted node executes the operation corresponding to the target network request and returns the execution result to the requesting end or the trusted node so that the trusted node forwards the execution result to the requesting end. In the embodiments of this application, a target network request is initiated from the requesting end to the service node in non-proxy mode, or from a trusted node of the requested end to the service node in proxy mode. Both the trusted node and the service node store the authority to authenticate the target network service. The trusted node provides authorization for the initiated target network request, and the service node performs verification and authentication of the target network request to prevent tampering and illegal request execution, thereby ensuring the security of all network requests. This approach is applicable to practical application scenarios with high security requirements. Attached Figure Description

[0020] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0021] Figure 1 This diagram illustrates the flow interaction of a network request verification and authentication method based on a trusted node according to one aspect of this application.

[0022] Figure 2 This diagram illustrates the flow interaction of a network request verification and authentication method based on a trusted node, according to another aspect of this application.

[0023] The same or similar reference numerals in the accompanying drawings represent the same or similar parts. Detailed Implementation

[0024] The present application will now be described in further detail with reference to the accompanying drawings.

[0025] In a typical configuration of this application, the terminal, the device of the service network, and the trusted party all include one or more processors (CPUs), input / output interfaces, network interfaces, and memory.

[0026] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0027] Computer-readable media include both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include non-transitory computer-readable media, such as modulated data signals and carrier waves.

[0028] Existing traditional API access platforms (such as RapidAPI, Baidu Cloud, and Alibaba Cloud's API marketplaces) require all request traffic to pass through the platform for authentication and application request control (such as call limits). This not only places a huge load on the platform, but also means that all data must pass through the platform, compromising data privacy. Furthermore, the availability of all access calls depends entirely on the access platform; if the platform fails, all requests will immediately become unavailable. In view of this, the solution provided in this application enables the trusted node to become a lightweight request control and authentication service. By controlling the issuance of tokens, it achieves fine-grained permission management and security policy management. (In non-proxy mode) the load on the trusted node is significantly reduced compared to the load on traditional access platforms. The trusted node is only requested when a new token is needed, and the privacy of the data is guaranteed. The request information parameters sent to the token production interface of the trusted node are only for the trusted node to recognize the request and for the service node to verify the consistency of the request. Therefore, there is no need to send the complete original data. For sensitive data (such as data in the request body), MD5 or HASH digests can be directly performed, which not only significantly reduces bandwidth but also ensures the privacy of the data and can also verify the consistency of the request.

[0029] In all embodiments of the network request verification and authentication method based on a trusted node provided in this application, the method is applied to a trusted node, a service node, and a requesting end with a request program installed. The trusted node is another network service trusted by the requesting end corresponding to the request program and the service node of the network service to be accessed. A trust relationship is established between the service node and the trusted node, enabling the trusted node to authorize network requests initiated to the service node. The service node is the node where the target network service to be accessed or the operation to be performed resides. The request program can be a client program, a network service, or a request script program—a computer program capable of sending network requests. The request program can be triggered by a user operation to initiate a network request, or it can initiate a network request according to program logic. The request program is installed on the requesting end.

[0030] The network request verification and authentication method based on trusted nodes provided in this application is also applicable to the microservice domain. In the microservice domain, an authentication service or gateway service can act as a trusted node to store the identity credentials and permission information of the microservice. When one service calls the interface of another service, the calling service can also be regarded as an accessor, acting as a requesting end with the request program installed, and using the network request verification and authentication method based on trusted nodes provided in the embodiments of this application for verification and authentication. The specific calling permissions (such as service level, interface level, resource level, etc.) that each microservice has for other services can also be managed and synchronized according to the permission system in all embodiments of this application.

[0031] Since the object of verification and authentication is the requesting program (such as a user client or service), in order to authenticate the request, the trusted node and the service node need to store a series of identity identifiers and access permissions. Access permissions are represented in various ways to determine whether a visitor has permission for a certain type of operation. For example, they can be represented by a list of HTTP methods and paths that the visitor can access (i.e., has permission for). Alternatively, permissions of arbitrary complexity can be defined using user groups, permission groups, etc. Access permissions are stored consistently across the trusted node and the service node. Identity identifiers are identifiers that uniquely identify a visitor and allow querying the visitor's corresponding access permissions, such as user IDs or network service identifiers. Identity identifiers are universal between the trusted node and the service node; that is, the permissions stored in the network service (service node) can be considered a part of the permissions stored in the trusted node (i.e., the part that grants access to the network service). In this context, the common meaning of identity identifier in both service nodes and trusted nodes is that the same identity identifier should represent the same visitor and the same access permissions in both trusted nodes and service nodes. The network request verification and authentication method based on trusted nodes provided in this application involves how to verify and authenticate network requests under existing identity identifiers and access permissions. The generation and modification of these identity identifiers and permissions are not within the scope of protection of this application.

[0032] In the network request verification and authentication method based on a trusted node provided in this application, the trusted node provides at least a token production interface and a token consumption interface. The token production interface is used to receive the information parameters of the target network request, store them together with the visitor's identity information, and generate a token. The token consumption interface is used to receive a token, retrieve the information parameters of the target network request and the identity information corresponding to the token from storage. At the same time, all interfaces in the service node that need to apply this scheme for verification and authentication also need to be exposed to the network and provide corresponding interface addresses so that when a request is made to the interface in this embodiment, a network request is sent to that interface address.

[0033] This application provides a network request verification and authentication method based on a trusted node. In different practical application scenarios, there are two implementation methods: non-proxy mode and proxy mode. First, regardless of the implementation method, the trusted node needs to provide a secure access protocol (such as HTTPS) to ensure that the requesting program and service node can securely request it. Furthermore, the trusted node needs to be able to authenticate the requesting program installed on the requesting end. This can be achieved as follows: if the requesting program is a user who is already logged into the trusted node, the request sent to the trusted node will carry the logged-in user's credentials, allowing the trusted node to obtain the user's identity and permissions. If the requesting program is a service, the request sent to the trusted node needs to carry the service's key or identifier, allowing the trusted node to obtain the service's identity and permissions. After these two conditions are met, the key or credentials carried in the request sent by the requesting program to the trusted node will be recognized by the trusted node as a valid visitor. In proxy mode, in certain communication scenarios, the requesting client may be unable to access the service node or establish a secure connection with it. For example, the service node may not provide secure protocol access, but the trusted node can access it; or the service node may be on a local area network (LAN) without a public IP address, while the trusted node is also on the same LAN but has a public IP address, and the requesting client with the request program installed is not connected to that LAN. In these two cases, the trusted node can be used as a request proxy for the requesting client with the request program installed, thus ensuring the feasibility and security of the request. However, proxy mode requires that the trusted node can access the service node. In other cases, non-proxy mode is used by default, but proxy mode can also be selected (or configured by the administrator).

[0034] The following example, using a non-proxy mode, further explains the network request verification and authentication method based on a trusted node provided in this application. It includes a service node, a trusted node, and a requesting end with a request program installed. The method comprises steps S11 to S13 executed by the requesting end through the request program, steps S21 to S23 executed by the trusted node, and steps S31 to S35 executed by the service node. Specifically, it includes the following steps:

[0035] In step S11 (not shown), the requesting end sends a first request to the token production interface of the trusted node, carrying the access credentials of the visitor who is to initiate the target network request, the information parameters of the target network request, and the identifier of the requested service node. Here, the access credentials may include, but are not limited to, the visitor's identity identifier, authorization credentials, or credentials used to query the corresponding user identifier.

[0036] It's important to note that the requesting end can flexibly construct request information parameters, and the construction rules are configurable. For example, parameters that need to be identified can retain their original values. If different security policies are configured based on the URL path, the URL path should retain its original value. Parameters that may contain large amounts of data or sensitive data can use digest values. If the request body contains a large amount of data or sensitive values, MD5, HASH, or other methods can be used for digest processing. Parameters that do not require consistency verification, such as certain fixed request headers, do not need to be included. Information parameters are used to determine the interface accessed by the request and to identify how the interface is used. Service nodes can synchronize their own interfaces with trusted nodes and can configure permissions and security policies for the interfaces.

[0037] The information parameters of the target network request are used to indicate the representation of the information being transmitted. It is necessary to ensure that changing other data of this request outside the range of these parameters will not affect the execution and semantics of the actual operation represented by this request. For example, for an HTTP request, the information parameters need to include, but are not limited to, the HTTP method, request URL, request body, request header, request method, and path of the target network request. The same rule applies to other protocols. The content of the information parameters includes the request information within the range or a unique information digest of the request information (such as a digest obtained using methods such as MD5 / HASH). It can be represented by any encoding method that can carry the above information, such as using JSON / XML encoding formats to encode the request information parameters.

[0038] It should be noted that information (such as a token) can be carried in a request by using request headers, request body, or URL parameters, and the information can be transmitted as a field or parameter. In practice, it is only necessary to use a commonly agreed-upon method that can reflect the integrity of the information during transmission.

[0039] Step S21 (not shown): The trusted node receives a first request from the requesting end through the token production interface, which carries the identity and authorization credentials of the visitor who is to initiate the target network request, the information parameters of the target network request, and the identifier of the requested service node.

[0040] Step S22 (not shown): The trusted node verifies whether the visitor has the permission to execute the target network request in the service node. If so, it generates a token and sends it to the requesting end, and stores the information parameters and the visitor's identity and permission credentials accordingly.

[0041] It should be noted that step S22 can include node-level verification and request-level verification, applied to requests of different security levels (or a single method can be used uniformly). Node-level permission verification specifically involves the trusted node storing the identifiers of the service node and the corresponding authorized requester in a certain way. Node-level verification only determines whether the authorized requester has permissions for that service node, without verifying which permissions specifically. Operation-level permission verification, on the other hand, involves the trusted node and service node synchronously storing the specific operation permission information of each authorized requester. It can determine the target operation of the request based on the request information parameters submitted by the requester and verify whether the requester has the permission to execute the target operation. Regardless of the permission verification method used at the trusted node, the service node will use operation-level permission verification to authenticate the specific operation permissions.

[0042] In step S12 (not shown), after receiving the token, the requesting end sends a target network request to the service node, carrying the token and the identifier of the trusted node.

[0043] Step S31 (not shown): The service node receives the target network request sent by the requesting end, carrying the token and the identifier of the trusted node, through the interface address.

[0044] In step S32 (not shown), the service node sends a second request to the token consumption interface corresponding to the identifier of the trusted node, carrying the token, so that the trusted node can verify whether the token is valid through the token consumption interface.

[0045] In this context, "corresponding" in the embodiments of the entire text can refer to implementation in any way, such as using a data table, cache component, or file to store the trusted node identifier and the corresponding interface address, and when the service node needs a specific address, it initiates a query to the corresponding storage component to obtain the corresponding interface address.

[0046] Step S23 (not shown): The trusted node receives the second request initiated by the service node carrying the token through the token consumption interface, verifies whether the token is valid, and if so, retrieves the stored information parameters corresponding to the token and the visitor's identity and permission credentials and returns them to the service node.

[0047] In step S33 (not shown), the service node receives the validity response result of the token, the information parameters corresponding to the token, and the accessor's identity and authorization credentials returned by the trusted node; here, the validity response result of the token includes a success response message indicating that the token is valid or a failure response message indicating that the token is invalid.

[0048] In step S34 (not shown), the service node verifies and authenticates the validity response of the token, the information parameters returned by the trusted node, and the accessor's identity and authorization credentials.

[0049] Step S35 (not shown): If both verification and authentication are successful, the service node executes the operation corresponding to the target network request and returns the execution result to the requesting end.

[0050] Step S13 (not shown): The requesting end receives the execution result returned by the service node. The execution result is obtained by the service node after verifying and authenticating the token based on the validity response result, the corresponding information parameters, and the visitor's identity and authorization credentials. The service node executes the current operation corresponding to the target network request when both verification and authentication are successful.

[0051] Through steps S11 to S13, S21 to S23, and S31 to S35, in non-proxy mode, after the requesting end directly initiates a target network request to the service node, the trusted node provides authorization for the initiated target network request. Since both the trusted node and the service node store the permission to authenticate the target network service, the service node verifies and authenticates the requested target network request. When both verification and authentication are successful, the service node executes the operation corresponding to the target network request and directly returns the execution result to the requesting end. This achieves anti-tampering and anti-illegal request execution, thereby ensuring the security of all network requests and is applicable to practical application scenarios with high security requirements.

[0052] The following uses a proxy model as an example to further explain the network request verification and authentication method based on a trusted node provided in this application. It includes a service node, a trusted node, and a requesting end with a request program installed. The method includes steps S101 to S102 executed by the requesting end through the request program, steps S201 to S206 executed by the trusted node, and steps S301 to S305 executed by the service node. Specifically, it includes the following steps:

[0053] Step S101 (not shown): The requesting end sends a first request to the token production interface of the trusted node, carrying the identity and authorization credentials of the visitor who is to initiate the target network request, the information parameters of the target network request, and the identifier of the service node of the request.

[0054] Steps S201 (not shown) and S202 (not shown) correspond to steps S21 (not shown) and S22 (not shown) as described above, respectively, and will not be repeated here.

[0055] In step S203 (not shown), the trusted node sends a target network request to the service node, carrying the token and the identifier of the trusted node.

[0056] Steps S301 (not shown), S302 (not shown), S204 (not shown), S303 (not shown), and S304 (not shown) correspond to steps S31 (not shown), S32 (not shown), S23 (not shown), S33 (not shown), and S34 (not shown) above, respectively, and will not be described again here.

[0057] Step S305 (not shown): If both verification and authentication are successful, the service node executes the operation corresponding to the target network request and returns the execution result to the trusted node.

[0058] Step S205 (not shown): The trusted node receives the execution result returned by the service node.

[0059] In step S206 (not shown), the trusted node forwards the execution result to the requesting end.

[0060] In step S102 (not shown), the requesting end receives the execution result sent by the trusted node.

[0061] Through the aforementioned steps S101 to S102, S201 to S206, and S301 to S305, in proxy mode, a target network request is initiated from the trusted node to the service node. The request is initiated by the proxy requesting end, and then the trusted node provides authorization for the initiated target network request. Both the trusted node and the service node store the authorization permissions for the target network service. The service node verifies and authenticates the target network request. When both verification and authentication are successful, the service node executes the operation corresponding to the target network request and returns the execution result to the trusted node in the form of a response. The trusted node then returns the response to the requesting end. This achieves anti-tampering and anti-illegal request execution, thereby ensuring the security of all network requests and making it suitable for practical application scenarios with high security requirements.

[0062] Following the above embodiments of this application, in the network request verification and authentication method based on a trusted node provided in this application, whether in non-proxy mode or proxy mode, when the service node performs the steps of verifying and authenticating the validity response result of the token, the information parameters returned by the trusted node, and the identity and authorization credentials of the visitor, it specifically includes the following three items:

[0063] The validity response result of the token is used to verify whether the trusted node has responded successfully;

[0064] Verify whether the target network request matches the information parameters returned by the trusted node;

[0065] The authentication verifies whether the access permissions corresponding to the visitor's identity and authorization credentials returned by the trusted node allow the execution of the target network request.

[0066] It should be noted that the determination of whether a response is successful can be determined by the specific implementation of the solution. For example, for an HTTP request, a 200 response code indicates success, 400 and above indicate failure, and others are invalid responses (also considered failures). Alternatively, a field can be used in the returned data to indicate whether the response is successful. Of course, the methods for determining whether a response is successful include, but are not limited to, these.

[0067] For example, the token validity response result returned by the trusted node includes a successful response indicating that the token is valid or a failure response indicating that the token is invalid. When verifying whether the trusted node responded successfully (i.e., whether the token is valid or invalid) through the token validity response result, if the trusted node returns a successful response, the trusted node's response is successful (i.e., the token is valid); if the trusted node returns a failure response, the trusted node's response fails (i.e., the token is invalid). When verifying whether the target network request matches the information parameters returned by the trusted node, if they match, the verification is successful; if they do not match, the verification fails. When authenticating whether the access permissions corresponding to the visitor's identity and permission credentials returned by the trusted node allow the execution of the target network request, if they allow, the authentication passes; if they do not allow, the authentication fails. This system implements three verification and authentication methods to verify and authenticate the validity of the token returned by the trusted node, the information parameters returned by the trusted node, and the visitor's identity and authorization credentials. Only when all three verifications and authentications are successful will the service node execute the operation corresponding to the target network request and return the execution result to the requesting party (in non-proxy mode) or the trusted node (in proxy mode) so that the trusted node can forward the execution result to the requesting party. This ensures that the target network request has not been tampered with and thus guarantees the security of the target network request.

[0068] Following the above embodiments of this application, in the network request verification and authentication method based on a trusted node provided in this application, regardless of whether it is in non-proxy mode or proxy mode, while performing the step of retrieving the stored information parameters corresponding to the token and the visitor's identity and authorization credentials, the trusted node also performs the step of deleting or marking the storage record of the token, its corresponding information parameters, and the visitor's identity and authorization credentials as invalid. In all embodiments of this application, regardless of whether it is in non-proxy mode or proxy mode, in order to prevent the token from being replayed, while performing the step of retrieving the stored information parameters corresponding to the token and the visitor's identity and authorization credentials, the trusted node also deletes the storage record of the token, its corresponding information parameters, and the visitor's identity and authorization credentials. That is, the token becomes invalid after being used, so that even if an attacker intercepts the same token returned by the trusted node, they will not be able to replay the target network request, and the consumption request will fail. The deletion here can include, but is not limited to, complete deletion, marking invalid, etc., thereby effectively preventing request replay attacks and ensuring security.

[0069] In a preferred embodiment of this application, under non-proxy mode, the following is a schematic diagram of the actual operation flow of a network request verification and authentication method based on a trusted node provided in this application, as follows: Figure 1 As shown, the requesting end has a request program C installed. The service node of the network service that the request program C initiates the target network request is the service node S. Another network service trusted by the request program C and the service node S is the trusted node M. The following describes the steps of the network request verification and authentication method based on the trusted node in the non-proxy mode in a practical application scenario:

[0070] 1. The requesting program C carries the target network request information parameters, the visitor's identity and authorization credentials, and the identifier of the service node S, and requests the token generation interface of the trusted node M;

[0071] 2. After receiving the request initiated by the requesting program C, the trusted node M verifies whether the visitor has the permission to execute the target network request in the service node S. If not, the request is rejected directly, and a failure response indicating that the permission for the target network request does not exist is returned to the requesting program C. If the visitor has the permission to execute the target network request in the service node S, a credential token is generated to store information, and the token stores at least the information parameters of the target network request to be initiated by the requesting program C and the visitor's identity identifier (i.e., a preferred embodiment of identity and permission credentials), and the token is returned to the requesting program C.

[0072] 3. The requesting program C, carrying the token returned by the trusted node M and the identifier of the trusted node M, directly initiates a target network request to the interface address of the service node S.

[0073] 4. After receiving the target network request initiated by the requesting program C, the service node S carries the token request to the token consumption interface corresponding to the identifier of the trusted node M, so that the trusted node M can verify the validity of the token through the token consumption interface.

[0074] 5. After receiving a request from the service node S carrying a token, the trusted node M verifies the validity of the token (e.g., verifies whether the token and its corresponding stored information exist in the storage). If valid, it retrieves the information parameters corresponding to the token and the visitor's identity from the storage, and returns the retrieved information parameters corresponding to the token and the visitor's identity, along with a success response message indicating the token's validity, to the service node S, and deletes the storage record that records the information parameters corresponding to the token and the visitor's identity. If invalid, it returns a failure response message indicating the token's expiration to the service node S.

[0075] 6. After receiving a success response, the information parameters corresponding to the token, and the visitor's identity information from the trusted node M, or after receiving a failure response from the trusted node M, service node S will perform at least the following three verifications and authentications:

[0076] Whether the response of the trusted node M is successful (i.e. whether the token is valid or invalid). If the trusted node M returns a successful response, then the response of the trusted node M is successful (i.e. the token is valid). If the trusted node M returns a failed response, then the response of the trusted node M is failed (i.e. the token is invalid).

[0077] Verify whether the target network request initiated by the requesting program C to the service node S matches the information parameters returned by the trusted node M. If they match, the verification is successful; otherwise, the verification fails.

[0078] The authentication and trusted node M returns the access permissions corresponding to the visitor's identity identifier. If the access permissions are allowed, the authentication is successful; otherwise, the authentication fails.

[0079] If any one of the three verification and authentication steps performed by service node S fails, service node S will refuse to execute the target network request and return a request failure response. If all three verification and authentication steps performed by service node S are successful, service node S will execute the operation corresponding to the target network request and return the generated execution result to the requesting program C. This enables the requesting program C to directly initiate a target network request to service node S in non-proxy mode, and the service node will perform verification and authentication of the target network request. This achieves anti-tampering and anti-illegal request execution, thereby ensuring the security of all network requests and is applicable to practical application scenarios with high security requirements.

[0080] In the non-proxy mode, data substitution can also be used. For example, in data substitution, the information parameters carried by the request program C to the trusted node M do not include any digest. The information parameters need to completely reproduce the entire network request (e.g., for an HTTP request, using the complete request method, request path, and request body). The request program C to the service node S does not need to carry any additional information parameters. The service node S directly uses the information parameters returned by the trusted node M for processing and as a response to the request program C. In short, the request to the service node S uses a complete substitution rather than a validation match. In the data substitution mode, the original target network request address and request method can still be used. The service node can perform another validation to ensure that the operation to be executed is the operation that the request program C needs to execute. However, the specific data required to execute the operation (such as request body data) can be directly obtained from the complete request information stored by the trusted node M, that is, there is no need to send it to the service node again.

[0081] In a preferred embodiment of this application, under proxy mode, the following is a schematic diagram of the actual operation flow of a network request verification and authentication method based on a trusted node provided in this application: Figure 2 As shown, the requesting end has a request program C installed. The service node of the network service that initiates the target network request from the request program C is the service node S. Another network service trusted by the request program C and the service node S is the trusted node M. Figure 2 The diagram illustrates the specific steps of a network request verification and authentication method based on a trusted node in a practical application scenario under proxy mode. In proxy mode, the trusted node acts as a proxy for data transfer between the requesting program C and the service node S. Other steps are the same as described above. Figure 1 The steps are the same as those for non-agent scenarios, and will not be repeated here.

[0082] In the proxy mode, regardless of the implementation method, the trusted node needs to provide a secure access protocol (such as HTTPS) to ensure that the requesting program and the service node can make requests to it securely, and the trusted node needs to be able to authenticate the requesting program installed on the requesting end.

[0083] In both proxy mode and non-proxy mode, a trusted node can be used as a request proxy for the requesting client with the request program installed, thus ensuring the feasibility and security of the request. However, proxy mode requires that the trusted node can access the service node. In other cases, non-proxy mode is used by default, but proxy mode can also be selected (or configured by the administrator).

[0084] In all embodiments of this application, for a trusted node, the trusted node receives the first request sent by the requesting end, generates token corresponding storage data, and queries the corresponding service node using the service node identifier carried in the request. Based on its protocol (whether to provide secure access) and configuration, it determines whether to adopt proxy mode access. If proxy mode is not used, the token is directly returned to the requesting end so that the requesting end can carry the token to initiate a second request to the service node; otherwise, the trusted node carries the token to initiate a target request (i.e., the second request) to the service node and returns the result to the requesting end.

[0085] For the requesting program, it sends a first request to the trusted node carrying the identifier of the target service node and request parameters. After receiving the response, it determines whether to send a second request based on the response content (if the response only contains a token, it is in non-proxy mode and a second request needs to be sent; if the response contains an execution result, the execution has been completed; or a field is used to mark the status of the response). If so, it sends a second request to the service node carrying the token.

[0086] Following the above embodiments of this application, in the network request verification and authentication method based on a trusted node provided in this application, regardless of whether it is in non-proxy mode or proxy mode, the trusted node further performs the following steps:

[0087] Different security levels for network requests correspond to different verification logic. Here, the trusted node can configure and enable different security measures (i.e., verification logic) for network requests of different security levels based on user or security requirements to ensure request security. Security level configuration can be globally unified or dynamically adjusted based on different service nodes, with the aim of determining a specific security level for a single request from a particular service node.

[0088] Here, different verification logic and security enhancement measures can be applied to different security levels. For example, these may include, but are not limited to, storing identity credentials, data substitution operations, setting expiration time, maximum number of retrievals, trusted node request control, and multi-factor authentication.

[0089] Before performing the step of verifying whether the visitor has the permission to execute the target network request in the service node, the trusted node also performs the following steps:

[0090] Determine the security level corresponding to the target network request;

[0091] Based on the security level corresponding to the target network request, determine whether the target network request needs to be verified.

[0092] If so, then determine the target verification logic corresponding to the security level of the target network request and execute the target verification logic.

[0093] In a preferred embodiment of this application, to further ensure security, when the requesting program is a user client, multi-factor authentication can be performed before the trusted node M generates a token and stores the corresponding information parameters and the visitor's identity identifier. This multi-factor authentication includes, but is not limited to, email verification codes, SMS verification codes, mobile QR code verification, and two-factor authentication. Since the information parameters of the request sent to the trusted node M include key features such as the path and method of the target network request, the trusted node M can configure different verification logic (such as different dynamic verification strategies) for different security levels of the network request to determine which requests need verification and which verifications are required. The following example uses the verification logic of sending a verification email or SMS to perform multi-factor authentication on the target network request. The specific verification process is as follows:

[0094] After receiving a request from the requesting program C, which carries the information parameters of the target network request, the visitor's identity, and the service node's identity, the trusted node M will check whether the target network request needs to be verified before verifying whether the visitor has the permission to execute the target network request on the service node. The security level of the target network request determines whether verification is required. For example, if the target network request is a query request (i.e., the security level requirement is not high), verification is not required. However, if the target network request is a delete request or a modify request (i.e., the security level requirement is high and there is data change), verification is required.

[0095] For requests that do not require verification, the trusted node M directly proceeds to the step of checking whether the visitor has the permission to execute the target network request on the service node. If the permission exists, a token is generated, and the information parameters corresponding to the token and the visitor's identity are stored accordingly.

[0096] For requests requiring verification, the trusted node M first determines the target verification logic corresponding to the security level of the target network request, and executes the target verification logic required to verify the target network request. For example, in a preferred embodiment of this application, multi-factor authentication can be performed by sending verification emails, verification SMS messages, or time-based one-time password (TOTP) applications to enhance the security of the embodiment. Before generating the token, the trusted node M determines whether the request requires additional verification based on the information parameters of the request. If additional verification is required, it executes the logic to prepare for verification (such as sending SMS or email verification codes). Multi-factor authentication information (such as SMS verification codes and email verification codes) can be stored using technologies such as sessions, and the information requiring multi-factor authentication is returned to the requesting program C. After receiving the response content returned by the trusted node M, the requesting program C determines whether the target network request requires multi-factor authentication based on the response content. If not, it initiates a request to the service node carrying the token and the identifier of the trusted node M; if so, it provides a prompt to the user according to the returned verification information, such as a pop-up window for entering a verification code.

[0097] After the user inputs and submits the verification information, the requesting program C sends the user's credentials (such as a session identifier) ​​and the user's input verification information to the trusted node M. The trusted node M can use session-based technologies to verify the accuracy of the verification information sent by the requesting program C using pre-stored verification information. If the verification passes, a token can be directly generated, and the corresponding request information parameters and visitor's identity identifier can be stored. The token is then returned, and the timestamp at that moment can be stored in the session. When the requesting program C continues to send other operations requiring multi-factor authentication to the trusted node M, the trusted node M can check if there is a timestamp indicating that the operation has passed verification. If not, it returns to the step requiring multi-factor authentication. If the timestamp is within the expiration period (which can be configurable), the operation has passed multi-factor authentication. The trusted node M can then directly generate a token, and the corresponding request information parameters and visitor's identity identifier can be stored. This allows the requesting program C to receive the token and then directly initiate a target network request to the service node S, carrying the token and the trusted node M's identifier. This achieves multi-factor authentication of the target network request, further balancing request performance and security, thereby enhancing security. .

[0098] Following the above embodiments of this application, in the network request verification and authentication method based on a trusted node provided in this application, whether in non-proxy mode or proxy mode, when the service node sends a second request to the token consumption interface corresponding to the identifier of the trusted node, the second request also carries the identity credentials of the service node, so that the trusted node can verify whether the identity credentials are valid.

[0099] The trusted node, while generating a token and simultaneously storing the information parameters and the visitor's identity and authorization credentials, also includes:

[0100] Store the identity credentials of the service node;

[0101] The second request also carries the identity credentials of the service node, wherein, upon receiving the second request, the trusted node, while verifying the validity of the token, also includes:

[0102] Based on the identity credentials of the stored service node and the identity credentials of the service node carried in the second request, verify whether the identity credentials are valid.

[0103] It should be noted that the identity credentials of the service node may be implemented in forms including but not limited to service keys, identifiers plus service keys, and other information used to indicate private information that can be authenticated by trusted nodes.

[0104] Here, service node S generates an identity credential during registration, and this identity credential is stored in both trusted node M and service node S. In practical applications, when trusted node M generates a token and simultaneously stores the information parameters and the visitor's identity and authorization credentials, it can store the service node S's key. This allows service node S to carry the service node's identity credential when sending a request (corresponding to the second request) to the token consumption interface corresponding to the identifier of trusted node M. While verifying the token's validity, trusted node M also verifies the validity of service node S's identity credential based on the stored service node's identity credential and the identity credential carried in the second request. This enhanced security measure of identity credential verification ensures that even if an attacker intercepts the token, they cannot forge the token consumption request sent by service node S, as the attacker cannot pass the identity credential verification by trusted node M, thus further enhancing request security.

[0105] In this embodiment, in the non-proxy mode, the token generated by the trusted node M is first returned to the requesting program C and then to the service node S. Theoretically, there is a risk of leakage or hijacking. However, the identity credentials of the service node can be generated during service registration and will not be transmitted to any third party other than the trusted node M at any time. In essence, because the identity credentials are only transmitted between the service node and the trusted node using a secure protocol (because the trusted node must provide a secure access protocol), they cannot be intercepted by attackers. It is a stable second-party key, and together with the token generated by the trusted node M and transmitted in a third-party manner, it will be more secure to perform double verification of the operation.

[0106] Following the above embodiments of this application, in the network request verification and authentication method based on a trusted node provided in this application, regardless of whether it is in non-proxy mode or proxy mode, the trusted node, while generating a token and simultaneously storing the information parameters and the visitor's identity and authorization credentials, also includes:

[0107] Configure an expiration period for the information parameters corresponding to the stored token and the accessor's identity and permission credentials;

[0108] Specifically, the trusted node verifies the validity of the token by:

[0109] Verify whether the token is valid within the validity period.

[0110] Here, after storing the corresponding information parameters and the visitor's identity and permission credentials for the token, an expiration period is configured for the stored information. This allows the trusted node to verify whether the token is valid within the specified expiration period. If the token is no longer within the expiration period, it becomes invalid; otherwise, it indicates that the token is valid. The validity period can be expressed in various forms, including but not limited to expiration time and / or maximum retrieval count. For example, the information corresponding to the storage token can have an expiration time set. Most caching components (such as Redis) support directly configuring an expiration time, or using other methods to store and record the storage time, and using background tasks to clean up expired records. The expiration time can be configurable or adjusted based on factors such as network latency. Alternatively, in addition to setting an expiration time, the information corresponding to the storage token can also have a maximum retrieval count set. For instance, during verification and authentication, it can only be read once (retrieved by the service node), and subsequent read operations are invalid. In implementation, a remaining retrieval count can be set in the storage, initially set to the maximum retrieval count for that record during the initial write, and decremented by 1 each time a read occurs. Furthermore, in the verification and authentication process of this application, the initiator of each token retrieval request is essentially determined, and the initiator of the retrieval operation can be verified based on the remaining retrieval count. For example, network services can be verified based on identity credentials, and the corresponding stored record can be deleted when the remaining retrieval count is 0.

[0111] Following the above embodiments of this application, in the network request verification and authentication method based on a trusted node provided in this application, regardless of whether it is in non-proxy mode or proxy mode, the trusted node can perform access control on the target network request based on the information parameters of the request program received from the requesting end. Since the trusted node can synchronously store all permission configurations, it can determine whether the visitor has permission to execute the target network request. If the visitor does not have permission to execute the target network request, it can be directly rejected. That is, when the requesting end requests the token production interface, it directly returns a failure response to the requesting end, and the requesting end will not perform subsequent operations, thereby realizing the access control of the trusted node.

[0112] Following the above embodiments of this application, in the network request verification and authentication method based on a trusted node provided in this application, regardless of whether it is in non-proxy mode or proxy mode, the trusted node can log and audit the requesting program based on the information parameters of the requesting program received from the requesting end, and monitor and alarm for abnormal request situations initiated by the requesting program (such as attempting to execute illegal requests, excessive request frequency, inconsistency between adjacent requesting devices or IPs, etc.), so as to realize security auditing and abnormal monitoring of the requests initiated by the requesting program of the requesting end through the trusted node.

[0113] In a preferred embodiment of this application, under non-proxy mode, the following is a schematic diagram of the actual operation flow of a network request verification and authentication method based on a trusted node provided in this application, as follows: Figure 1 As shown, the requesting end has a request program C installed. The service node of the network service in which the request program C initiates the target network request is the service node S. Another network service trusted by the request program C and the service node S is the trusted node M. The following is a specific example of the practical application scenario of the network request verification and authentication method based on the trusted node in the non-proxy mode:

[0114] For example, if a user on the requesting end needs to request log data with a status code of 500 from service node S (let's call it S1), the request can be constructed as follows:

[0115] GET https: / / service.com / api / ops / log? status=500

[0116] In non-proxy mode, the requesting program C needs to send the information parameters of the first request to the trusted node M (let's call it M1). For the first request initiated by the requesting program C to the trusted node M, the following method can be used as the request information parameters:

[0117]

[0118] The request parameters, along with the identifier of the service node S, are sent to the trusted node M in JSON format. The specific pseudocode is as follows:

[0119]

[0120] The trusted node M needs to verify whether the user (i.e., the visitor) in the request sent by the requesting program C has the permission to access the service node S and execute the target network request. This can be achieved as follows:

[0121] First, all users making requests must log in to the trusted node M. The trusted node M can authenticate user requests using methods such as session / JWT tokens. When a user sends a request to the trusted node M, they include a session ID / JWT token as authentication credentials. The trusted node decodes these credentials (e.g., for JWT tokens) or retrieves the corresponding user identifier (i.e., for sessions) from storage to verify whether the user has permission to access the trusted node. If not, the request is rejected, and a failure response is returned. If permission is granted, the trusted node generates a token and stores the request information parameters. The pseudocode for this can be represented as follows:

[0122]

[0123]

[0124] After receiving the returned token, the requesting program C sends a target network request to the service node S, carrying the token returned by the trusted node M and the identifier of the trusted node M. If the token returned by the trusted node M is ABCD, the target network request initiated to the service node can be as follows, using the request header to carry the token and the identifier of the trusted node M:

[0125]

[0126] After receiving the target network request, service node S, carrying the token, accesses the interface corresponding to the trusted node M (identified by the trusted node M1). Specifically, it queries the service node's storage for the interface address corresponding to trusted node M1 and initiates a second request to retrieve the data. Security enhancements can be used to add service node identity credentials, such as:

[0127]

[0128]

[0129] After receiving the second request from the service node S, the trusted node M verifies the validity of the token. This can be done by combining the token with the service node's identity credentials. A specific implementation example is as follows:

[0130]

[0131] Assuming the requesting user's identity is A1, an example of retrieving the data stored corresponding to the token would be:

[0132]

[0133] After receiving the response from the trusted node M, the service node S will perform at least the following verifications and authentications:

[0134] Whether M's response was successful (i.e., whether the token has expired / becomes invalid); if it is valid, a successful response and valid data are returned.

[0135] The system checks whether the target network request sent by the requesting program C matches the request information returned by the trusted node M, specifically whether the method (GET) and path (https: / / service.com / api / log?status=500) are consistent.

[0136] The trusted node M returns an identity identifier (A1) and determines whether the access permissions corresponding to that identifier (A1) allow the execution of the current target network request. Specifically, the service node S queries the storage of a series of permissions corresponding to user A1 and determines whether the series of permissions corresponding to user A1 includes the permissions required for the current target network request (querying logs).

[0137] If at least three verifications and authentications are successful, then execute the operation (i.e., query the logs that meet the conditions) and return the result (i.e., the queried log data) to the requesting program C.

[0138] In this specific embodiment, in non-proxy mode, the requesting party initiates a target network request to the service node. Both the trusted node and the service node store the authorization to authenticate the target network service. The trusted node provides authorization for the initiated target network request, and the service node performs verification and authentication of the target network request to prevent tampering and illegal request execution, thereby ensuring the security of all network requests. This approach is suitable for practical application scenarios with high security requirements.

[0139] Through the above embodiments of this application, one aspect of this application provides a network request verification and authentication method based on a trusted node, which can achieve high security, single sign-on, microservice authentication, unified fine-grained identity access management, and network service management.

[0140] The high security is mainly reflected in the following aspects: Anti-tampering: For requests using all embodiments of this application, the service node will only execute requests corresponding to the information parameters authorized and stored by the trusted node. If the sent request is inconsistent with the information parameters stored by the trusted node, it will be rejected, preventing the request from being tampered with; Anti-replay: Even if an attacker intercepts the token returned by the trusted node, the token becomes invalid after being used, preventing request replay; Zero-trust authentication: Applying the concept of zero-trust security, whether a request can be executed depends only on whether the visitor has the permission to execute the request, regardless of whether the visitor's network environment is trusted; Attack surface analysis: For requests using the verification and authentication methods in all embodiments of this application... Even if an attacker completely intercepts the request from the requesting end and uses a token generated by a trusted node to initiate operations on the service node, if the requesting program's operation is executed first, the attacker's operation will not be executed after the token is deleted. Even if the attacker's operation is executed first, the service node will only execute the operation that the requesting program from the requesting end originally needed to execute (because the request information parameters are stored on the trusted node and will be matched and verified on the service node), without causing other impacts. If security enhancement measures for service node identity verification are used, even if an attacker intercepts the token, they cannot forge a request from the service node because the attacker cannot pass the trusted node's identity verification. Multiple bad-case assumptions are made for the attack surface and countermeasures are taken. Even if these assumptions are met simultaneously, it will not affect the verification and authentication of this application or cause security problems, thereby further ensuring the high security of the application's request verification and authentication.

[0141] In single sign-on (SSO), one embodiment of this application provides a network request verification and authentication method based on a trusted node, which can achieve SSO. The trusted node can act as an identity authentication center for network services. Users only need to log in to the trusted node and use the verification and authentication process to authorize access to all service nodes trusted by the trusted node according to the user's access permissions. This uses request-level rather than session-level fine-grained control. When a user logs out of the trusted node, they also lose access to other service nodes. In other words, after logging in to the trusted node, users can access all authorized service nodes.

[0142] In the interface authentication between network services, one embodiment of this application provides a network request verification and authentication method based on a trusted node. This method can also be used for authentication between network services. An authentication service or gateway service acts as a trusted node, storing the identity credentials and permission information of the storage service. When one service calls the interface of another service, the calling service can also be regarded as an accessor, acting as the requesting end (with a request program installed) in the embodiment of this application. When using the process of the network request verification and authentication method based on a trusted node provided in one embodiment of this application for verification and authentication, the specific calling permissions (such as service level, interface level, resource level, etc.) that each service has for other services can also be managed and synchronized according to the permission verification method in the embodiment of this application, thereby realizing interface authentication between network services. This method can be used for inter-service permission management in microservice clusters, as well as for open interface interconnection, integration of enterprise applications or data, privacy computing, federated learning, and other scenarios. In this application scenario, the trusted node can also perform interface authentication for calls between network services. The consumer service implements the corresponding part of the requesting end in the method flow of this application, and the provider service implements the part of the service node in the process of this application. This allows for fine-grained permission configuration and security policy configuration. The trusted node can become a lightweight interface authentication center. Unlike traditional API authentication gateways that carry all inbound and outbound traffic of interface calls, it only provides token production and consumption to achieve fine-grained permission configuration, security control, and request control. For example, it can control the maximum number of requests a caller can make within a certain period to implement subscription-based API services.

[0143] This application provides a unified, fine-grained identity access management method. The trusted node involved in this method, based on a trusted node for network request verification and authentication, can serve as a unified identity access management center for a cluster (such as a microservice cluster composed of multiple network services). It centrally stores information about all visitors and service nodes, as well as the permissions of visitors to different resources of different services. It also provides unified authentication and authorization services to service nodes. The method can be flexibly configured to enhance authentication security through various verification methods such as two-factor authentication, email verification, SMS verification, and mobile QR code verification. It can also flexibly configure request IP / region verification, request device verification, and other methods to intercept illegal requests. Furthermore, it can save administrator operation records, audit and detect abnormal requests, thus achieving unified, fine-grained identity access management.

[0144] In the management of network services, one embodiment of this application provides a network request verification and authentication method based on a trusted node, which configures different security policies for the administrator according to the security requirements of different management operations, and verifies and authenticates the administrator's management operations.

[0145] Furthermore, an embodiment of this application provides a network request verification and authentication method based on a trusted node, which can also be applied to scenarios where authentication and authorization rely entirely on the trusted node. In this embodiment, the service node does not need to maintain the identifiers, keys, and permissions of all authorized users. It only needs to configure the interface address of the trusted node and its own identity credentials (such as identifiers and keys) registered with the trusted node. In this case, the information stored in the token generated by the trusted node also needs to include the permissions possessed by the user. After the service node obtains the response through the token consumption interface (or uses the cached token response, or directly decodes the token), it can configure the requested interface and corresponding permissions. In this degenerate embodiment, all user permission generation and configuration are completed entirely on the trusted node without synchronization with the service node, making the maintenance of the service node simpler. Of course, the service node also needs to "unconditionally" trust the authentication results of the trusted node, which is equivalent to using the trusted node as its own user authentication service.

[0146] According to another aspect of this application, a non-volatile storage medium is also provided, on which computer-readable instructions are stored, which, when executed by a processor, cause the processor to implement the network request verification and authentication method based on the trusted node described above.

[0147] According to another aspect of this application, a service node for network request verification and authentication based on a trusted node is also provided, the service node comprising:

[0148] One or more processors;

[0149] Computer-readable medium for storing one or more computer-readable instructions.

[0150] When the one or more computer-readable instructions are executed by the one or more processors, the one or more processors implement the network request verification and authentication method based on the trusted node as described above for the service node.

[0151] For details of the various embodiments of the service node based on the network request verification and authentication of the trusted node, please refer to the corresponding part of the above-described embodiment of the service node based on the network request verification and authentication method of the trusted node. It will not be repeated here.

[0152] According to another aspect of this application, a trusted node for network request verification and authentication based on a trusted node is also provided, the trusted node comprising:

[0153] One or more processors;

[0154] Computer-readable medium for storing one or more computer-readable instructions.

[0155] When the one or more computer-readable instructions are executed by the one or more processors, the one or more processors implement the network request verification and authentication method based on the trusted node as described above.

[0156] For details of the various embodiments of the trusted node in the network request verification and authentication based on the trusted node, please refer to the corresponding part of the above-described embodiments of the network request verification and authentication method based on the trusted node. They will not be repeated here.

[0157] According to another aspect of this application, a request client for network request verification and authentication based on a trusted node is also provided, the request client comprising:

[0158] One or more processors;

[0159] Computer-readable medium for storing one or more computer-readable instructions.

[0160] When the one or more computer-readable instructions are executed by the one or more processors, the one or more processors implement the network request verification and authentication method based on the trusted node described above.

[0161] For details of the various embodiments of the network request verification and authentication method based on trusted nodes, please refer to the corresponding parts of the above embodiments of the network request verification and authentication method based on trusted nodes. They will not be repeated here.

[0162] In summary, in this embodiment, the service node receives a target network request sent by a requesting end or a trusted node via an interface address, carrying the token and the identifier of the trusted node. The token is generated by the trusted node after receiving a first request from the requesting end, carrying the identity and authorization credentials of the visitor initiating the target network request, the information parameters of the target network request, and the identifier of the requesting service node, through a token production interface. The trusted node then verifies that the visitor has the permission to execute the target network request on the service node. A second request is sent to the token consumption interface corresponding to the identifier of the trusted node, carrying the token, so that the trusted node verifies the validity of the token through the token consumption interface. The trusted node receives a validity response result for the token, the information parameters corresponding to the token, and the visitor's identity and authorization credentials returned by the trusted node. The validity response result, the information parameters returned by the trusted node, and the visitor's identity and authorization credentials are verified and authenticated. If both verification and authentication are successful, the operation corresponding to the target network request is executed, and the execution result is returned to the requesting end or the trusted node so that the trusted node forwards the execution result to the requesting end.

[0163] In the embodiments of this application, in non-proxy mode, the requesting party initiates a target network request to the service node, or in proxy mode, a trusted node on the requested party initiates a target network request to the service node. Both the trusted node and the service node store the authority to authenticate the target network service. The trusted node provides authorization for the initiated target network request, and the service node performs verification and authentication of the target network request to prevent tampering and illegal request execution, thereby ensuring the security of all network requests. This approach is applicable to practical application scenarios with high security requirements.

[0164] It should be noted that this application can be implemented in software and / or a combination of software and hardware, for example, using an application-specific integrated circuit (ASIC), a general-purpose computer, or any other similar hardware device. In one embodiment, the software program of this application can be executed by a processor to implement the steps or functions described above. Similarly, the software program of this application (including related data structures) can be stored in a computer-readable recording medium, such as RAM memory, magnetic or optical drives, floppy disks, and similar devices. Furthermore, some steps or functions of this application can be implemented in hardware, for example, as circuitry that cooperates with a processor to perform the various steps or functions.

[0165] Furthermore, a portion of this application can be applied as a computer program product, such as computer program instructions, which, when executed by a computer, can invoke or provide the methods and / or technical solutions according to this application through the operation of the computer. The program instructions invoking the methods of this application may be stored in a fixed or removable recording medium, and / or transmitted via data streams in broadcast or other signal carrying media, and / or stored in the working memory of a computer device operating according to the program instructions. Here, one embodiment of this application includes an apparatus comprising a memory for storing computer program instructions and a processor for executing the program instructions, wherein, when the computer program instructions are executed by the processor, the apparatus is triggered to operate the methods and / or technical solutions based on the foregoing embodiments of this application.

[0166] It will be apparent to those skilled in the art that this application is not limited to the details of the exemplary embodiments described above, and that this application can be implemented in other specific forms without departing from the spirit or essential characteristics of this application. Therefore, the embodiments should be considered exemplary and non-limiting in all respects, and the scope of this application is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be embraced within this application. No reference numerals in the claims should be construed as limiting the scope of the claims. Furthermore, it is clear that the word "comprising" does not exclude other units or steps, and the singular does not exclude the plural. Multiple units or devices recited in the apparatus claims may also be implemented by a single unit or device in software or hardware. The terms "first," "second," etc., are used to indicate names and do not indicate any particular order.

Claims

1. A method for authenticating a network request based on a trusted node, applied to a service node, wherein, The method includes: The system receives a target network request sent by a requesting end or a trusted node, carrying a token and the identifier of the trusted node, through an interface address. The token is generated by the trusted node after receiving a first request from the requesting end, carrying the identity and permission credentials of the visitor who is to initiate the target network request, the information parameters of the target network request, and the identifier of the service node being requested, through a token production interface, and after verifying that the visitor has the permission to execute the target network request in the service node. The token is carried to the token consumption interface corresponding to the identifier of the trusted node, and a second request is sent to the trusted node so that the trusted node can verify whether the token is valid through the token consumption interface. Receive the validity response result of the token returned by the trusted node, the information parameters corresponding to the token, and the accessor's identity and permission credentials; The validity response of the token, the information parameters returned by the trusted node, and the visitor's identity and authorization credentials are verified and authenticated. If both verification and authentication are successful, the operation corresponding to the target network request is executed, and the execution result is returned to the requesting end or the trusted node, so that the trusted node forwards the execution result to the requesting end. The method of receiving a target network request sent by a requesting end or a trusted node carrying the token and the identifier of the trusted node through an interface address includes: in non-proxy mode, the service node receiving a target network request sent by the requesting end carrying the token and the identifier of the trusted node through an interface address; and in proxy mode, the service node receiving a target network request sent by the trusted node carrying the token and the identifier of the trusted node through an interface address.

2. The method of claim 1, wherein, The verification and authentication of the token's validity response, the information parameters returned by the trusted node, and the visitor's identity and authorization credentials includes: The validity response result of the token is used to verify whether the trusted node has responded successfully; Verify whether the target network request matches the information parameters returned by the trusted node; The authentication verifies whether the access permissions corresponding to the visitor's identity and authorization credentials returned by the trusted node allow the execution of the target network request.

3. The method according to claim 1, wherein, The second request also carries the identity credentials of the service node, so that the trusted node can verify whether the identity credentials are valid.

4. A network request verification and authentication method based on a trusted node, applied to a trusted node, wherein, The method includes: The token production interface receives a first request from the requesting end, which carries the identity and authorization credentials of the visitor who is to initiate the target network request, the information parameters of the target network request, and the identifier of the requested service node. Verify whether the visitor has the permission to execute the target network request on the service node. If so, generate a token and send it to the requesting end, and store the information parameters and the visitor's identity and permission credentials accordingly. After receiving the token, the requesting end sends the token and the identifier of the trusted node to the interface address of the service node to initiate a target network request, so that the service node sends a second request to the token consumption interface corresponding to the identifier of the trusted node. The system receives a second request from the service node carrying the token through the token consumption interface, verifies whether the token is valid, and if so, retrieves the stored information parameters corresponding to the token and the visitor's identity and permission credentials and returns them to the service node. The service node verifies and authenticates the token based on its validity response, the corresponding information parameters, and the visitor's identity and authorization credentials. When both verification and authentication are successful, the service node executes the current operation corresponding to the target network request and sends the execution result to the requesting end. The process of generating a token, which simultaneously stores the information parameters and the visitor's identity and permission credentials, also includes storing the service node's identity credentials. The second request also carries the identity credentials of the service node. The verification of the validity of the token also includes: verifying the validity of the identity credentials based on the stored identity credentials of the service node and the identity credentials of the service node carried in the second request.

5. The method according to claim 4, wherein, The process of generating a token, while simultaneously storing the information parameters and the visitor's identity and access credentials, also includes: Configure an expiration period for the information parameters corresponding to the stored token and the accessor's identity and permission credentials; The verification of the validity of the token includes: Verify that the token is valid within the validity period.

6. The method according to claim 4, wherein, While retrieving the stored information parameters corresponding to the token and the visitor's identity and authorization credentials, the method further includes: Delete or mark the stored records of the invalid token, its corresponding information parameters, and the visitor's identity and permission credentials.

7. The method according to claim 4, wherein, The method further includes: Different security levels for network requests correspond to different authentication logic; Before verifying whether the visitor has permission to execute the target network request in the service node, the method further includes: Determine the security level corresponding to the target network request; Based on the security level corresponding to the target network request, determine whether the target network request needs to be verified. If so, then determine the target verification logic corresponding to the security level of the target network request and execute the target verification logic.

8. A network request verification and authentication method based on a trusted node, applied to the requesting end, wherein, The method includes: A first request is sent to the token production interface of the trusted node, carrying the identity and authorization credentials of the visitor who is to initiate the target network request, the information parameters of the target network request, and the identifier of the service node to be requested, so that the trusted node can verify whether the visitor has the permission to execute the target network request in the service node. If so, a token is generated and sent to the requesting party, and the information parameters and the visitor's identity and authorization credentials are stored accordingly. The system sends a target network request to the service node, carrying the token and the identifier of the trusted node. In response, the service node sends a second request to the token consumption interface corresponding to the identifier of the trusted node, carrying the token. The trusted node receives the second request from the service node carrying the token through the token consumption interface, verifies the validity of the token, and if valid, retrieves the stored information parameters corresponding to the token and the visitor's identity and authorization credentials, and returns them to the service node. The service node receives the execution result returned by the service node, wherein the execution result is obtained by the service node performing verification and authentication based on the validity response result of the token, the corresponding information parameters and the identity and authorization credentials of the visitor, and executing the operation corresponding to the target network request when both verification and authentication are successful.

9. A non-volatile storage medium having stored computer-readable instructions thereon, which, when executed by a processor, cause the processor to perform the method as described in any one of claims 1 to 8.

10. A service node for network request verification and authentication based on a trusted node, the service node comprising: One or more processors; Computer-readable medium for storing one or more computer-readable instructions. When the one or more computer-readable instructions are executed by the one or more processors, the one or more processors perform the method as described in any one of claims 1 to 3.

11. A trusted node for network request verification and authentication based on a trusted node, the trusted node comprising: One or more processors; Computer-readable medium for storing one or more computer-readable instructions. When the one or more computer-readable instructions are executed by the one or more processors, the one or more processors perform the method as described in any one of claims 4 to 7.

12. A request client for network request verification and authentication based on a trusted node, the request client comprising: One or more processors; Computer-readable medium for storing one or more computer-readable instructions. When the one or more computer-readable instructions are executed by the one or more processors, the one or more processors perform the method of claim 8.

Images