CN116318811A

CN116318811A - Network request verification authentication method and device based on trusted node

Info

Publication number: CN116318811A
Application number: CN202211696671.7A
Authority: CN
Inventors: 周煦林
Original assignee: Shanghai Yuanzun Technology Co ltd
Current assignee: Shanghai Yuanzun Technology Co ltd
Priority date: 2022-12-28
Filing date: 2022-12-28
Publication date: 2023-06-23

Abstract

The purpose of the application is to provide a network request verification authentication method and device based on a trusted node, wherein the application initiates a target network request to a service node through a request end in a non-proxy mode or initiates the target network request to the service node through the trusted node trusted by the request end in a proxy mode, wherein the trusted node and the service node both store rights of authenticating target network services, the trusted node provides rights of the initiated target network request, the service node realizes verification and authentication of the request to the requested target network request, and tamper resistance and illegal request execution are realized, so that the security of all network requests is ensured, and the application method and device can be suitable for practical application scenes with higher security.

Description

Network request verification authentication method and device based on trusted node

Technical Field

The present disclosure relates to the field of computer technologies, and in particular, to a method and apparatus for verifying and authenticating a network request based on a trusted node.

Background

In the prior art, the schemes for checking and authenticating network requests include Single Sign On (SSO), identity access management, zero trust security and micro-service authentication. In single sign-on, a traditional single sign-on mode uses a global Session and local Session mode to carry out single sign-on, an SSO authentication center only processes basic authentication (such as a user name/password and the like) of user credentials, a currently commonly used single sign-on scheme comprises OIDC/SAML/CAS/OAuth 2/distributed Session/JWT and the like, the traditional single sign-on mode is greatly dependent on Session and redirection of a browser, is not friendly to other types of request programs, and the verification level is Session level and cannot refine granularity of access control to a request level or a resource level; in identity access management, identity access management mechanisms that control software and hardware resource access are rarely used in terms of interface authentication for network services; in the zero trust security, the current zero trust security system is mainly developed around the aspects of intranet host security and the like, but is rarely used for the interface authentication aspect of network service; in micro service authentication, not only authentication of access users (such as single sign on, authentication service, etc.) is needed, but also access rights of each micro service to other services are needed to be controlled, and currently, the main method is to use a gateway or a service grid SideCar to perform access control of the micro service. Therefore, how to perform universality, fine-granularity configuration, flexible regulation and control and authentication for balancing security and performance on network requests are main subjects of current research in the industry.

Disclosure of Invention

The network request verification and authentication method and device based on the trusted node can carry out strict verification and authentication on the network request, and is tamper-proof and illegal in request execution, so that the safety of all network requests is guaranteed.

According to one aspect of the present application, there is provided a network request verification authentication method based on a trusted node, applied to a service node, wherein the method includes:

receiving a target network request sent by a request end or a trusted node carrying the token and the identifier of the trusted node through an interface address, wherein the token is generated when verifying that the visitor has the authority to execute the target network request in a service node after the trusted node receives a first request of the request end carrying an identity authority credential of the visitor to initiate the target network request, an information parameter of the target network request and the identifier of the requested service node through a token production interface;

the token is carried to send a second request to a token consumption interface corresponding to the identifier of the trusted node, so that the trusted node verifies whether the token is valid or not through the token consumption interface;

Receiving a validity response result of the token returned by the trusted node, information parameters corresponding to the token and an identity authority credential of the visitor;

checking and authenticating the validity response result of the token, the information parameter returned by the trusted node and the identity authority certificate of the visitor,

and if the verification and the authentication are successful, executing the operation corresponding to the target network request, and returning an execution result to the request end or the trusted node so that the trusted node forwards the execution result to the request end.

According to another aspect of the present application, there is also provided a network request verification authentication method based on a trusted node, applied to the trusted node, where the method includes:

receiving a first request of a request end carrying an identity authority credential of a visitor to be initiated with a target network request, an information parameter of the target network request and an identifier of a requested service node through a token production interface;

verifying whether the visitor has the authority of executing the target network request in the service node, if so, generating a token and sending the token to the request end, and correspondingly storing the information parameter and the identity authority certificate of the visitor; the request end initiates a target network request to an interface address of the service node by carrying the token and the identifier of the trusted node after receiving the token, so that the service node carries the token and sends a second request to a token consumption interface corresponding to the identifier of the trusted node;

Receiving a second request initiated by the token carried by the service node through a token consumption interface, verifying whether the token is effective, if so, taking out the stored information parameters corresponding to the token and the identity authority credentials of the visitor and returning the information parameters and the identity authority credentials to the service node;

and the service node performs verification and authentication based on the validity response result of the token, the corresponding information parameter and the identity authority certificate of the visitor, and executes the current operation corresponding to the target network request and sends the execution result to the request terminal when the verification and authentication are successful.

According to another aspect of the present application, there is further provided a network request verification and authentication method based on a trusted node, applied to a request end, where the method includes:

transmitting a first request carrying an identity authority credential of a visitor to be initiated with a target network request, an information parameter of the target network request and an identifier of a requested service node to a token production interface of a trusted node, so that the trusted node verifies whether the visitor has the authority to execute the target network request in the service node, if so, a token is generated and transmitted to the request end, and meanwhile, the information parameter and the identity authority credential of the visitor are correspondingly stored;

Sending a target network request to the service node by carrying the token and the identifier of the trusted node, so that the service node responds to the target network request and carries the token to send a second request to a token consumption interface corresponding to the identifier of the trusted node; the trusted node verifies whether the token is effective or not through the token consumption interface, if yes, the stored information parameters corresponding to the token and the identity authority credentials of the visitor are taken out and returned to the service node;

and receiving an execution result returned by the service node, wherein the execution result is obtained by the service node executing the current operation corresponding to the target network request when the verification and the authentication are successful after the verification and the authentication are performed on the basis of the validity response result of the token, the corresponding information parameter and the identity authority credential of the visitor.

Compared with the prior art, the service node in the embodiment of the application receives a target network request sent by a request end or a trusted node carrying the token and the identifier of the trusted node through an interface address, wherein the token is generated when verifying that the visitor has the authority to execute the target network request in the service node after the trusted node receives a first request of the request end carrying the identity authority credential of the visitor to initiate the target network request, the information parameter of the target network request and the identifier of the requested service node through a token production interface; the token is carried to send a second request to a token consumption interface corresponding to the identifier of the trusted node, so that the trusted node verifies whether the token is valid or not through the token consumption interface; receiving a validity response result of the token returned by the trusted node, information parameters corresponding to the token and an identity authority credential of the visitor; and checking and authenticating the validity response result of the token, the information parameter returned by the trusted node and the identity authority certificate of the visitor, if the checking and the authentication are successful, executing the operation corresponding to the target network request, and returning the execution result to the request end or the trusted node so that the trusted node forwards the execution result to the request end. In the embodiment of the application, the target network request initiated to the service node through the request end in the non-proxy mode or the target network request initiated to the service node is initiated by the trusted node trusted by the requested end in the proxy mode, wherein the trusted node and the service node both store the authority for authenticating the target network service, the trusted node provides the authority for the initiated target network request, and the service node realizes the verification and authentication of the request for the requested target network request, and the tamper-proof and illegal request execution, thereby ensuring the safety of all network requests and being applicable to the practical application scene with higher safety.

Drawings

Other features, objects and advantages of the present application will become more apparent upon reading of the detailed description of non-limiting embodiments, made with reference to the following drawings, in which:

FIG. 1 illustrates a flow interactive schematic diagram of a trusted node-based network request verification authentication method in accordance with an aspect of the present application;

fig. 2 is a flow chart illustrating a network request verification authentication method based on a trusted node according to another aspect of the present application.

The same or similar reference numbers in the drawings refer to the same or similar parts.

Detailed Description

The present application is described in further detail below with reference to the accompanying drawings.

In one typical configuration of the present application, the terminal, the device of the service network, and the trusted party each include one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

The memory may include volatile memory in a computer-readable medium, random Access Memory (RAM) and/or nonvolatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.

Computer readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of storage media for a computer 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 technology, compact disc read only memory (CD-ROM), digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape disk storage or other magnetic storage devices, or any other non-transmission medium, which can be used to store information that can be accessed by a computing device. Computer readable media, as defined herein, does not include non-transitory computer readable media (transmission media), such as modulated data signals and carrier waves.

The existing traditional platform for providing API access (such as an API market of rapidAPI, hundred-degree cloud and ali cloud, and the like) has all request flow passing through the platform, so that the platform performs authentication and application request control (such as secondary limitation, and the like), the load on the platform is huge, corresponding data also needs to pass through the platform, the confidentiality of the data cannot be guaranteed, and the availability of all access calls completely depends on the access platform, and if the platform fails, all requests cannot be called immediately. In view of this, the scheme provided in this application makes the trusted node become a lightweight request control and authentication service, achieve fine-grained rights management by controlling the issuance of tokens, security policy management, etc., the load of the trusted node is greatly reduced (in the non-proxy mode) compared with the load of the conventional access platform, only when a new token needs to be acquired, the trusted node needs to be requested, and the privacy of data is guaranteed, the request information parameter sent to the token production interface of the trusted node can identify the request only for the trusted node, and the service node can check the consistency of the request, so that the sending of complete original data is not required, and MD5 or HASH digest can be directly performed on sensitive data (such as data in the request body), which not only significantly reduces the bandwidth, but also guarantees the privacy of data, and also can check the consistency of the request.

In all embodiments of the network request verification authentication method based on the trusted node, the method is applied to the trusted node, the service node and the request end provided with the request program, wherein the trusted node is another network service trusted by the request end corresponding to the request program and the service node of the network service to be accessed, and trust establishment of authority exists between the service node and the trusted node, so that the trusted node can provide authorization of the network request initiated to the service node; the service node is a node where a target network service to access a resource or perform an operation is located; the request program may be a client program, a network service or a computer program with the capability of sending a network request, such as a request script program, and the request program may be operated by a user to trigger a network request, or may initiate a network request according to program logic, where the request program is installed at the request end.

The network request verification authentication method based on the trusted node is also suitable for the micro service field, in the micro service field, an authentication service or gateway service can be used as the trusted node, identity credentials, authority information and the like of the micro service are stored, when one service calls an interface of another service, a caller service can also be regarded as a visitor, the caller service is used as a request end for installing a request program, verification and authentication are performed by using the network request verification authentication method based on the trusted node provided by the embodiment of the application, and specific calling authorities (such as service level, interface level, resource level and the like) owned by other services can also be managed and synchronized according to the authority system in all embodiments of the application by each micro service.

Since the verification and authentication object is a request program (for example, it may be a user client or service, etc.), in order to authenticate the request, the trusted node and the service node need to store a series of identities and access rights. The access rights are characterized in a plurality of modes, so as to judge whether the visitor has rights to a certain operation or a certain operation, for example, the access rights can be characterized in a mode of an HTTP method, a path list and the like which comprise the access (namely, the rights) of the visitor, and the access rights can be stored in a consistent mode between a trusted node and a service node by defining rights of any complexity in a plurality of modes of a user group, a rights group and the like; the identity is an identity which can uniquely identify a visitor and can query the corresponding access rights of the visitor, such as the ID of a user table, the identification name of a network service, etc., and is common between the trusted node and the service node, i.e. the rights stored in the network service (service node) can be regarded as part of the rights stored in the trusted node (i.e. the part with the rights to access the network service). The method for verifying and authenticating the network request based on the trusted node provided by the application relates to verification and authentication of the network request which are performed under the existing identity and access authority, and generation and change of the identity and the authority are not in the protection scope of the application.

In the network request verification authentication method based on the trusted node, the trusted node at least provides a token (token) production interface and a token (token) consumption interface, wherein the token production interface is used for receiving information parameters of a target network request, storing the information parameters together with information such as an identification mark of a visitor and the like, and generating a token interface; the token consumption interface is used for receiving a token, and extracting information parameters and an identification of a target network request corresponding to the token from storage; meanwhile, all interfaces in the service node, which need to be checked and authenticated by applying the scheme, also need to be opened to the network and provide corresponding interface addresses, so that a network request is sent to the interface addresses when the interfaces corresponding to the requests are involved in the embodiment of the application.

In the network request verification authentication method based on the trusted node provided by the embodiment of the application, in different practical application scenes, two implementation modes, namely a non-proxy mode and a proxy mode, exist. First, whichever implementation is adopted, the trusted node needs to provide a secure access protocol (e.g., HTTPS) to ensure that the requesting program and the service node can securely request it, and the trusted node needs to be able to authenticate the requesting program installed in the requesting end, which may be: if the request program is a user, the user logs in the trusted node, and the request sent to the trusted node carries the credentials of the logged-in user, so that the trusted node can acquire the identity and authority of the requested user; if the request program is a service, the key or the identifier of the service needs to be carried in the request sent to the trusted node, so that the trusted node can acquire the identity and the authority of the requested service, and after the two conditions are met, the information such as the key or the credential carried in the request sent to the trusted node by the request program can be identified by the trusted node as an effective visitor. In the proxy mode, under the condition of partial communication, the request end cannot access the service node or cannot establish a secure connection with the service node, for example, the service node cannot provide secure protocol access, but the trusted node can access the service node; for example, the service node is in a local area network, but has no public network address, the trusted node is also in the local area network, but has public network address, the request end provided with the request program is not connected with the local area network, in both cases, the trusted node can be used as a request proxy of the request end provided with the request program, thereby ensuring the feasibility and the security of the request end, but the proxy mode needs to meet that the trusted node can access the service node. In other cases non-proxy mode requests are used by default, but proxy modes may also be selected (or configured by the administrator) to make the request.

Taking a non-proxy mode as an example, the network request verification authentication method based on a trusted node provided by the present application is further explained, including a service node, a trusted node, and a request end with a request program installed, including steps S11 to S13 executed by the request 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 including the following steps:

step S11 (not shown), the requesting end sends a first request carrying an identity authority credential of a visitor to initiate a target network request, an information parameter of the target network request and an identity of a requested service node to a token production interface of a trusted node. Here, the identity authority credential may include, but is not limited to, an identity identifier of a visitor, an authority credential, or a credential for querying a corresponding user identifier, etc.

It should be noted that, the request end may flexibly construct the information parameter of the request, and the constructed rule is configurable, for example, the parameter to be identified is configured, the original value is reserved, if different security policies are required to be configured according to the URL path, the URL path needs to reserve the original value, for example, the parameter may contain a large amount of data or sensitive data, the summary value may be used, for example, the request body may contain a large amount of data, or the sensitive value may contain the summary processing may be performed by using modes such as MD5, HASH, and the like, for example, the parameter that does not need to verify consistency is not required to be contained, for example, some fixed request header is not required to be contained. The information parameters are used for determining an interface for requesting access, and the use mode of the interface can be identified through the parameters; the service node may synchronize its own interface with the trusted node and may configure permissions and security policies for the interface.

The information parameter of the target network request is used for indicating the representation of the transferred information, and the request needs to be ensured to be changed to other data except the parameter range, so that the execution and the semantics of the operation of the actual representation of the request are not affected, such as for an HTTP request; the information parameters need to include at least, but not limited to, HTTP method, request URL, request body, request header, request method, path, etc. parameters of the target network request, and the rule is used similarly for other protocols, where the content of the information parameters includes request information or unique information abstract (such as abstract obtained by MD5/HASH, etc.) within the scope of the request information, and the information parameters can be represented by any encoding method capable of carrying the above information, such as encoding the request information parameters by JSON/XML, etc. encoding formats.

It should be noted that, the manner of carrying a message (such as token) in the request may be to use a request header, a request body or URL parameters, etc. to transfer the message as a certain field or parameter, and only a commonly agreed manner capable of showing the integrity of the message is required to be used for implementation.

Step S21 (not shown), the trusted node receives, through a token production interface, a first request with the request end carrying an identity authority credential of a visitor to initiate a target network request, an information parameter of the target network request, and an identification of a requested service node.

Step S22 (not shown), the trusted node verifies whether the visitor has the authority to execute the target network request in the service node, if so, generates a token and sends the token to the requesting end, and correspondingly stores the information parameter and the identity authority credential of the visitor.

It should be noted that in step S22, node-level authentication and request-level authentication may be applied to requests with different security levels (or a mode may be uniformly adopted), where node-level authority authentication specifically includes that a trusted node stores identifiers of a service node and a corresponding authority requester in a certain way, and node-level authentication only determines that the authority requester has authority to the service node, and does not specifically verify which authorities. In addition, the operation level authority verification is that, because the trusted node and the service node synchronously store the specific operation authority information owned by each authority requester, the target operation of the request can be determined according to the request information parameters submitted by the requester, and whether the requester has the authority to execute the target operation is verified. Whichever authentication mode is used at the trusted node, the operation level authentication mode is used at the service node to authenticate the specific operation rights.

Step S12 (not shown), after receiving the token, the requesting end sends a target network request to the service node with the token and the identifier of the trusted node.

Step S31 (not shown), the service node receives, through an interface address, a target network request sent by the request end carrying the token and the identifier of the trusted node.

Step S32 (not shown), the service node carries the token and sends a second request to the token consuming interface corresponding to the identifier of the trusted node, so that the trusted node verifies whether the token is valid through the token consuming interface.

The "corresponding" in the full text embodiments may be implemented in any manner, for example, using a data table, where the trusted node identifier and the corresponding interface address are stored in a cache component or a file, and when a specific address is needed by a service node, a query is initiated to the corresponding storage component to obtain the corresponding interface address.

Step S23 (not shown), the trusted node receives, through a token consumption interface, a second request initiated by the token carried by the service node, verifies whether the token is valid, and if yes, takes out the stored information parameter corresponding to the token and the identity authority credential of the visitor, and returns the information parameter and the identity authority credential to the service node.

Step S33 (not shown), the service node receives the validity response result of the token returned by the trusted node, the information parameter corresponding to the token, and the identity authority credential of the visitor; here, the validity response result of the token includes success response information indicating that the token is valid or failure response information indicating that the token is invalid.

Step S34 (not shown), the service node verifies and authenticates the validity response result of the token, the information parameter returned by the trusted node and the identity authority credential of the visitor.

Step S35 (not shown), if the verification and authentication are successful, the service node executes the operation corresponding to the target network request, and returns the execution result to the request end.

Step S13 (not shown), the request end receives an execution result returned by the service node, where 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 parameter and the identity authority credential of the visitor, and then executing the current operation corresponding to the target network request when both verification and authentication are successful.

Through the steps S11 to S13, S21 to S23, and S31 to S35, after the target network request is directly initiated to the service node through the request end in the non-proxy mode, the trusted node provides authorization to the initiated target network request, and since the trusted node and the service node both store the authorization to authenticate the target network service, the service node realizes the verification and authentication of the request to the requested target network request, and when the verification and authentication are successful, the service node executes the operation corresponding to the target network request, and returns the execution result directly to the request end, thereby realizing the execution of tamper-proof and illegal requests, ensuring the security of all network requests, and being applicable to the practical application scenario with higher security.

Taking a proxy mode as an example, the method for verifying and authenticating a network request based on a trusted node provided by the present application is further explained, and includes a service node, a trusted node, and a request end with a request program installed, where the request end includes steps S101 to S102 executed by the request program, steps S201 to S206 executed by the trusted node, and steps S301 to S305 executed by the service node, and specifically includes the following steps:

Step S101 (not shown), the requesting end sends a first request carrying an identity authority credential of a visitor to initiate a target network request, an information parameter of the target network request and an identity of a requesting service node to a token production interface of a trusted node.

Step S201 (not shown) and step S202 (not shown) correspond to the above-described step S21 (not shown) and step S22 (not shown), respectively, and are not described in detail herein.

Step S203 (not shown), the trusted node sends a target network request to the service node carrying the token and the identity of the trusted node.

Step S301 (not shown), step S302 (not shown), step S204 (not shown), step S303 (not shown) and step S304 (not shown) correspond to the above-mentioned step S31 (not shown), step S32 (not shown), step S23 (not shown), step S33 (not shown) and step S34 (not shown), respectively, in order, and are not described here again.

Step S305 (not shown), if the 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.

Step S205 (not shown), the trusted node receives the execution result returned by the service node.

Step S206 (not shown), the trusted node forwards the execution result to the requesting end.

Step S102 (not shown), the request end receives the execution result sent by the trusted node.

Through the steps S101 to S102, S201 to S206 and S301 to S305, a target network request is initiated to a service node through a trusted node in a proxy mode, and initiated by a proxy request end, then the trusted node provides authorization for the initiated target network request, rights for authenticating a target network service are stored in both the trusted node and the service node, verification and authentication of the requested target network request are realized by the service node, and when the verification and authentication are successful, an operation corresponding to the target network request is executed through the service node, an execution result is returned to the trusted node in a response form, and the trusted node returns to the request end, so that anti-tampering and illegal request execution is realized, the security of all network requests is ensured, and the method is applicable to practical application scenes with higher security.

In the method for verifying and authenticating network request based on trusted node provided in the present application, whether in non-proxy mode or proxy mode, the service node performs the steps of verifying and authenticating the validity response result of the token, the information parameter returned by the trusted node and the identity authority credential of the visitor, and specifically includes the following three steps:

Checking whether the response of the trusted node is successful or not according to the validity response result of the token;

checking whether the target network request is matched with information parameters returned by the trusted node;

and authenticating whether the access right corresponding to the identity right certificate of the visitor returned by the trusted node allows the target network request to be executed.

It should be noted that, whether the response is successful or not may be formulated by a specific implementation of the scheme, for example, for an HTTP request, the returned 200 response code indicates success, 400 and above indicates failure, and other is an invalid response (also belongs to failure), or whether the response is successful or not may be indicated by using a field in the returned data, and of course, the judging manner of whether the response is successful or not includes but is not limited to this.

For example, when the validity response result of the token returned by the trusted node includes success response information for indicating that the token is valid or failure response information for indicating that the token is invalid, and when whether the trusted node responds successfully (i.e. whether the token is valid or invalid) is checked through the validity response result of the token, if the trusted node returns success response information, the response of the trusted node is successful (i.e. the token is valid), and if the trusted node returns failure response information, the response of the trusted node is failed (i.e. the token is invalid); when checking whether the target network request is matched with the information parameters returned by the trusted node, if so, the verification is successful, and if not, the verification is failed; and when whether the access right corresponding to the identity right certificate of the visitor returned by the trusted node allows the target network request to be executed or not is authenticated, if so, the authentication is passed, and if not, the authentication is not passed. The method and the device realize verification and authentication of the validity response result of the token returned by the trusted node, the information parameter returned by the trusted node and the identity authority certificate of the visitor by the three verification authentication modes, only when the three verification authentication is successful, the service node can execute the operation corresponding to the target network request, and the execution result is returned to the request end (in a non-proxy mode) or the trusted node (in a proxy mode) so that the trusted node forwards the execution result to the request end, thereby ensuring that the target network request is not tampered and further ensuring the security of the target network request.

In the method for verifying and authenticating a network request based on a trusted node according to the present application, the trusted node performs the steps of retrieving the stored information parameter corresponding to the token and the identity authority credential of the visitor, while performing the steps of: deleting or marking the stored record of invalid token and corresponding information parameter and identity authority certificate of the visitor. In all embodiments of the present application, whether in a non-proxy mode or a proxy mode, in order to prevent a token from being attacked by replay, when a trusted node takes out a stored information parameter corresponding to the token and an identity authority credential of the visitor, the trusted node may delete the token and the corresponding information parameter thereof and a stored record of the identity authority credential of the visitor, that is, the token becomes invalid after being used, so that even if an attacker intercepts the same token returned by the trusted node, replay of a request of initiating a target network cannot be performed, and consumption request failure may be caused, and deletion herein may include, but is not limited to, completely deleting, marking invalid, etc., so that replay attack of the request may be effectively prevented, and security is ensured.

In a preferred embodiment of the present application, in a non-proxy mode, an actual operation flow diagram of a network request verification authentication method based on a trusted node is provided, as shown in fig. 1, where a request program C is installed in a request end, a service node of a network service requested by a target network initiated by the request program C is a service node S, another network service trusted by the request program C and the service node S is a trusted node M, and the following description of steps of the network request verification authentication method based on the trusted node in the non-proxy mode performs an actual application scenario:

1. the request program C carries information parameters of the target network request, identity authority credentials of the visitor and identification of the service node S, and requests a token production interface of the trusted node M;

2. after receiving a request initiated by a request program C, the trusted node M verifies whether the visitor has the authority to execute the target network request in the service node S, if not, directly refuses the request, and returns a failure response for indicating that the target network request does not have the authority to the request program C; if the visitor has the authority to execute the target network request in the service node S, a ticket is generated, which stores information, and at least stores information corresponding to the ticket, including, but not limited to, information parameters of the target network request to be initiated by the requesting program C and an identity of the visitor (i.e., a preferred embodiment of the identity authority credential), and returns the ticket to the requesting program C.

3. The request program C carries the token returned by the trusted node M and the identifier of the trusted node M to directly initiate a target network request to the interface address of the service node S.

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

5. After receiving a request initiated by a token carried by a service node S, a trusted node M verifies whether the token is valid (for example, verifies whether the token and the information stored correspondingly in the token are available in storage, if so, the trusted node M takes out the information parameters corresponding to the token and the identity of a visitor from storage, returns the information parameters corresponding to the token and the identity of the visitor taken out together with successful response information for indicating that the token is valid to the service node S, and deletes the storage record for recording the information parameters corresponding to the token and the identity of the visitor; and if not, returning failure response information for indicating the failure of the token to the service node S.

6. After receiving the success response information returned by the trusted node M, the information parameters corresponding to the token and the identification information of the visitor, or receiving the failure response information returned by the trusted node M, the service node S performs at least the following three verification and authentication:

Whether the response of the trusted node M is successful (i.e. whether the token is valid or invalid), if the response of the trusted node M is successful response information, the response of the trusted node M is successful (i.e. the token is valid), and if the response of the trusted node M is failed response information, the response of the trusted node M is failed (i.e. the token is invalid);

checking whether a target network request initiated by a request program C to a service node S is matched with information parameters returned by a trusted node M, if so, successful verification is achieved, and if not, verification is failed;

and authenticating whether the access right corresponding to the identification mark of the visitor returned by the trusted node M allows the target network request to be executed, if so, passing the authentication, and if not, not passing the authentication.

The service node S can reject the execution of the target network request and return a response of the request failure, if the service node S performs the verification and the authentication, the service node S can execute the operation corresponding to the target network request and return the generated execution result to the request program C, and the purpose that the target network request is directly initiated to the service node S through the request program C in a non-proxy mode and the request is verified and authenticated by the service node is achieved, so that the execution of tamper-proof and illegal requests is achieved, the safety of all network requests is guaranteed, and the service node S can be suitable for practical application scenes with higher safety.

In the non-proxy mode, for example, in the data replacement mode, the information parameter carried by the request sent by the request program C to the trusted node M does not include any summary, the information parameter needs to be able to completely reproduce the entire network request (for example, for an HTTP request, the request uses a complete request method, a request path, a request body, and other data), the request sent by the request program C to the service node S does not need to carry other additional information parameters, and the service node S directly uses the information parameter returned by the trusted node M to process and respond to the request program C, which is a way of completely replacing the request of the service node S instead of checking and matching; in the data substitution operation mode, the original address and request method of the target network request can still be used, the service node can check again, it is ensured that the operation to be executed is the operation required to be executed by the request program C, but specific data (such as information of request volume data) required to execute the operation can be directly obtained from the complete request information stored by the trusted node M, that is, the request information does not need to be repeatedly sent to the service node.

In a preferred embodiment of the present application, in a proxy mode, an actual operation flow diagram of a network request verification authentication method based on a trusted node is provided, as shown in fig. 2, where a request program C is installed in a request end, a service node that requests a network service requested by a target network by the request program C is a service node S, another network service trusted by the request program C and the service node S is a trusted node M, as shown in fig. 2, a specific step of performing an actual application scenario for the network request verification authentication method based on the trusted node in the proxy mode is shown in fig. 2, where in the proxy mode, a forwarding proxy of data between the request program C and the service node S is performed by the trusted node, and other steps are consistent with those in a non-proxy state in fig. 1, which are not repeated herein.

In proxy mode, whichever implementation is employed, the trusted node needs to provide a secure access protocol (e.g., HTTPS, etc.) to determine that the requesting program and the serving node can securely request it, and needs to be able to authenticate the requesting program installed in the requesting end.

In both the proxy mode and the non-proxy mode, the trusted node may be used as a request proxy for the requesting end with the requesting program installed, so that the feasibility and the security of the request of the requesting end are guaranteed, but the proxy mode needs to satisfy that the trusted node can access the service node. In other cases non-proxy mode requests are used by default, but proxy modes may also be selected (or configured by the administrator) to make the request.

In all embodiments of the present application, for a trusted node, the trusted node receives a first request sent by a request end to generate storage data corresponding to a token, queries a corresponding service node by a service node identifier carried in the request, determines whether to adopt a proxy mode access according to a protocol (whether to provide secure access) and configuration of the service node, and if the proxy mode is not used, directly returns the token to the request end, so that the request end carries the token to initiate a second request to the service node; otherwise, the trusted node carries the token to initiate a target request (namely a second request) to the service node, and returns the result to the request end.

For the request program, a first request is initiated to a trusted node with the identification of a target service node and request parameters, after a response is received, whether the second request needs to be sent is judged according to response content (only a token in the response is in a non-proxy mode and needs to be sent, execution is completed if an execution result is in the response, or a field is used for marking the state of the response), and if the second request needs to be sent (in the non-proxy mode), the second request is initiated to the service node with the token.

In the above embodiment of the present application, in a network request verification authentication method based on a trusted node provided in the present application, the trusted node further performs the steps of:

configuring different security levels of the network request to correspond to different verification logic; here, the trusted node may support configuring and enabling different security measures (i.e., authentication logic) for network requests of different security levels according to user requirements or security requirements to ensure the security of the request. The configuration of the security level can be global unified configuration or can be dynamically regulated and controlled according to different service nodes, so that one level can be determined by one request of one service node.

Different authentication logic and security enhancements may be applied to different security levels, such as, but not limited to, storing identity credentials, data substitution operations, setting expiration times, maximum number of fetches, trusted node request control, and multi-factor authentication.

Wherein the trusted node further performs the step of, before performing the step of verifying whether the visitor has the right to perform the target network request in the service node:

determining a security level corresponding to the target network request;

based on the security level corresponding to the target network request, judging whether the target network request needs to be verified,

if yes, determining target verification logic corresponding to the security level of the target network request and executing the target verification logic.

In a preferred embodiment of the present application, in order to further ensure security, for the case that the request program is a user client, before the trusted node M generates a token and stores the corresponding information parameter and the identity of the visitor, multi-factor verification may be performed, which includes but is not limited to verification modes such as mailbox verification code, short message verification code, mobile terminal scan code verification, and two-factor verification. Because the information parameters of the request sent to the trusted node M include key features such as a path and a method of the target network request, the trusted node M may configure corresponding different verification logic (such as different dynamic verification policies) for different security levels of the network request, so as to determine which requests need to be verified and which needs to be verified. Taking the verification logic for sending verification mail or verification short message as an example, the multi-factor verification is performed on the target network request, and the specific verification process comprises the following steps:

After receiving a request sent by the request program C carrying the information parameter of the target network request, the identity of the visitor and the identity of the service node, the trusted node M detects whether the target network request needs to be verified before verifying whether the visitor has the authority to execute the target network request in the service node, and determines whether the target network request needs to be verified according to the security level of the target network request, for example, verification is not required when the initiated target network request is a query request (i.e. the security level is not high), but verification is required when the initiated target network request is a deletion request or a modification request (i.e. the security level is high and there is also a change of data).

For the request which does not need verification, the trusted node M directly enters the step of judging whether the visitor has the authority of executing the target network request in the service node, generates a token when the authority exists, and correspondingly stores the information parameters corresponding to the token and the identity of the visitor.

For the request to be verified, 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 for verifying the target network request, for example, in a preferred embodiment of the present application, multi-factor verification may be performed by sending a verification mail, a verification short message, or a time-based one-time password (TOTP) application, to enhance the security of the embodiment, where the trusted node M may obtain, before generating the token, whether the request needs additional verification according to the information parameter of the request, and if the additional verification is needed, execute the logic (such as sending a short message or a mailbox verification code, etc.) to prepare the verification, and may store the multi-factor verification information (such as the sent short message verification code and the mailbox verification code, etc.) through a session (session), etc. technology, and return the information requiring the multi-factor verification to the request program C. After receiving the response content returned by the trusted node M, the request program C judges whether the target network request is a request requiring multi-factor verification according to the response content, and if not, the request program C enters a request for initiating the token and the identifier of the trusted node M to the service node; if so, a prompt is given to the user according to the returned verification information, such as popup window for inputting verification codes, etc.

After the user inputs and submits the verification information, the request program C carries the user credentials (such as the identification of session) and the verification information input by the user, and sends the information I to the trusted node M. The trusted node M can check whether the verification information sent by the request program C is correct through the pre-stored verification information by session and other technologies, if so, the trusted node M can directly generate the token and store the information parameter of the request and the identity of the visitor correspondingly and return the token, and can store the time stamp of the moment in the session, when the request program C continues to send other operations requiring multi-factor verification to the trusted node M, the trusted node M can detect whether the time stamp passing the operation verification exists, if not, the trusted node M returns to the step requiring multi-factor verification, if the time stamp is in the expiration time (the expiration time can be configurable), the operation passes the multi-factor verification, and can directly generate the token and store the information parameter of the request and the identity of the visitor correspondingly and return the token, so that the request program C can directly initiate the target network request to the service node S with the identity of the token after receiving the token, thereby realizing multi-factor verification on the target network request, and further balancing the performance and the security enhancement of the request, and achieving the aim of security. .

In the network request verification and authentication method based on the trusted node, the service node carries the token to send a second request to a token consumption interface corresponding to the identifier of the trusted node in a non-proxy mode or a proxy mode, and the second request also carries an identity credential of the service node, so that the trusted node verifies whether the identity credential is valid or not;

the trusted node generates a token and correspondingly stores the information parameter and the identity authority certificate of the visitor, and meanwhile, the trusted node further comprises:

storing identity credentials of the service node;

wherein the second request further carries an identity credential of the service node, and wherein the trusted node, after receiving the second request, verifies whether the token is valid, further comprises:

and verifying whether the identity credential is valid or not based on the stored identity credential of the service node and the identity credential of the service node carried by the second request.

It should be noted that, the implementation form of the identity credential of the service node may include, but is not limited to, a service key, an identifier+a service key, and the like, which is used to indicate information that is private and can be authenticated by the trusted node.

In this case, the service node S generates an identity credential during registration, and both the trusted node M and the service node S store the identity credential, so that in an actual application scenario, when the trusted node M generates a token and stores the information parameter and the data such as the identity authority credential of the visitor correspondingly, the key of the service node S can be stored, so that the service node S carries the identity credential of the service node when carrying the token to send a request (corresponding to a second request) to a token consumption interface corresponding to the identifier of the trusted node M; the trusted node M performs validity verification on the token, and performs verification on whether the identity credential of the service node S is valid or not based on the stored identity credential of the service node and the identity credential of the service node carried by the second request, so that security enhancement measures of validity verification are performed through the identity credential, and an attacker cannot forge the token consumption request sent by the service node S even if the attacker intercepts the token in an actual application scene, because the attacker cannot verify the identity credential of the trusted node M, thereby further enhancing the security of the request.

In this embodiment, in the non-proxy mode, the token generated by the trusted node M will first return to the request program C and then request the service node S, there is a risk of leakage or intrusion hijacking in theory, but the identity credential of the service node may be generated during service registration, and will not be transmitted to any third party other than the trusted node M at any time, i.e. essentially because the identity credential cannot be intercepted by an attacker only by using a secure protocol transmission between the service node and the trusted node (because the trusted node must provide a secure access protocol), it is a stable two-party key, and it is safer to perform double verification on the operation together with the token generated by the trusted node M and transmitted in three parties.

In the above embodiment of the present application, in a network request verification authentication method based on a trusted node provided in the present application, whether in a non-proxy mode or a proxy mode, the trusted node generates a token and correspondingly stores the information parameter and the identity authority credential of the visitor, and meanwhile, the method further includes:

a validity period is configured for the stored information parameters corresponding to the token and the identity authority credentials of the visitor;

Wherein the trusted node verifies whether the token is valid, specifically comprising:

verifying whether the token is valid for the validity period.

After storing the corresponding information parameters and the information such as the identity authority credentials of the visitor for the token, the validity period is configured for the stored information, so that when the trusted node verifies whether the token is valid or not, the token can be verified to be valid in the validity period, if the token is not valid any more, the token is invalid, and if the token is valid in the validity period, the token is indicated to be valid. The presentation form of the validity period may include, but is not limited to, an expiration time form and/or a maximum fetch number form, for example, the information corresponding to the storage token may set an expiration time, most cache components (such as dis) support to directly configure an expiration time, or use other modes to store and record the storage time, and use a background task mode to clean up the expired record, where the expiration time may be configurable, or may be regulated and controlled according to factors such as network environment delay; for example, in addition to setting the expiration time, the information corresponding to the token may be set to a maximum number of times of fetching, for example, the information may be read only once (taken out by the service node) in performing verification and authentication, and then the read operation is illegal.

In the network request verification and authentication method based on the trusted node, whether in the non-proxy mode or the proxy mode, the trusted node can perform access control on the target network request according to the received information parameters requested by the request program from the request end, and because the trusted node can synchronously store all authority configurations, whether the visitor has authority to execute the target network request this time can be judged, if the visitor does not have authority to execute the target network request this time, the request can be directly refused, namely, when the request end requests a token production interface, the request end returns to the response of failure of the request end directly, and the subsequent operation can not be executed by the request end, so that the access control of the trusted node is realized.

In the network request verification and authentication method based on the trusted node, the trusted node may log and audit the request program according to the received information parameter requested by the request program from the request end, and monitor and alarm abnormal request conditions (such as illegal request attempting, excessively high request frequency, inconsistent IP or the like) initiated by the request program, so as to perform security audit and abnormal monitoring on the request initiated by the request program from the request end through the trusted node, whether in the non-proxy mode or in the proxy mode.

In a preferred embodiment of the present application, in a non-proxy mode, an actual operation flow diagram of a network request verification authentication method based on a trusted node is provided, as shown in fig. 1, where a request program C is installed in a request end, a service node of a network service requested by a target network initiated by the request program C is a service node S, another network service trusted by the request program C and the service node S is a trusted node M, and a specific embodiment is described below for an actual application scenario of the network request verification authentication method based on the trusted node in the non-proxy mode:

for example, a user at the requesting end needs to request log data with a status code of 500 of the service node S (S1 is set), which may be configured as the following request:

GET https://service.com/api/ops/logstatus＝500

in the non-proxy mode, the information parameter of the first request requiring the requesting program C to send the operation to the trusted node M (identified as M1), for the first request initiated by the requesting program C to the trusted node M, the following manner may be used as the information parameter of the request:

the information parameters carried by the request are sent to the trusted node M in the JSON format and the identification of the service node S, and the specific pseudo code can be as follows:

The trusted node M needs to verify whether the user (i.e. visitor) in the request sent by the request program C has the right to access the service node S and execute the target network request, and the implementation manner may be as follows:

firstly, a user executing a request needs to log in a trusted node M, the trusted node M can authenticate the request sent to the trusted node M by using a session/jwt token and other methods, the user can carry session/jwt token and the like as authority credentials when sending the request to the trusted node M, the trusted node decodes the credentials (such as for jwt token) or takes out corresponding user identification (such as for session) in a storage, so that whether the user corresponding to the request has authority to access the trusted node can be verified, if not, the request is refused, a failure response is returned, and if so, the pseudo code of information such as information parameters of the token generated by the trusted node and the storage request can be expressed as follows:

/>

after the request program C receives the returned token, the request program C sends a target network request to the service node S with the token returned by the trusted node M and the identifier of the trusted node M, and if the token returned by the trusted node M is ABCD, the request header carries the token and the identifier of the trusted node M, and the target network request initiated to the service node may be as follows:

After receiving the target network request, the service node S carries a token to access an interface corresponding to the trusted node M corresponding to the identifier M1 of the trusted node, that is, queries an interface address corresponding to the trusted node M1 from the storage of the service node, and initiates a second request for retrieving data, and may use security enhancement measures to add identity credentials of the service node, for example:

after receiving the second request initiated by the service node S, the trusted node M verifies whether the token is valid, and can perform joint verification with the identity credential of the service node, which is specifically implemented as follows:

assuming that the identity of the requesting user is A1, then an example of retrieving the data stored by the token corresponding to it is:

after receiving the response returned by the trusted node M, the service node S performs at least the following verification and authentication:

whether the response of M was successful (i.e., whether the token was expired/invalid); if the valid period exists, successful response and valid data are returned;

whether the target network request sent by the request program C is matched with the request information returned by the trusted node M or not, namely whether a comparison method (get) is consistent with a path (https:// service. Com/api/log status=500);

whether the access authority corresponding to the identity mark (A1) returned by the trusted node M allows the execution of the current target network request or not, namely, a series of authorities corresponding to the user A1 are queried in the storage of the service node S, and whether the series of authorities corresponding to the user A1 comprise authorities required by the current target network request (query log) or not is judged.

If the checksum authentication of at least three items is successful, the operation is performed (i.e. the eligible log is queried) and the result (i.e. the queried log data) is returned to the requesting program C.

In this embodiment, a target network request is initiated to a service node through a request end in a non-proxy mode, where both the trusted node and the service node store rights for authenticating the target network service, and the trusted node provides authorization for the initiated target network request, and the service node implements verification and authentication of the request for performing request on the requested target network request, so as to prevent tampering and illegal request execution, thereby ensuring security of all network requests, and being applicable to practical application scenarios with higher security.

Through the above embodiments of the present application, the network request verification and authentication method based on the trusted node provided by the embodiments of an aspect of the present application may implement high security, single sign on, micro service authentication, unified fine-grained identity access management, management of network services, and the like.

The high security is mainly reflected in the following aspects: tamper-proof, for the requests in all embodiments of the application, the service node only executes the requests corresponding to the information parameters of the requests authorized and stored by the trusted node, and if the transmitted requests are inconsistent with the information parameters stored by the trusted node, the requests are refused, so that the requests are prevented from being tampered; anti-replay, even if an attacker intercepts a token returned by a trusted node, the token is invalid after being used, and the replay of a request cannot be performed; zero trust authentication applies the idea of zero trust security, and whether the request can be executed depends on whether the visitor has the right to execute the request or not, and is irrelevant to whether the network environment of the visitor is trusted or not; attack surface analysis, for the request about verification and authentication in all embodiments of the application, even if an attacker completely intercepts the request of the request end and initiates operation to the service node by using the token generated by the trusted node, if the operation of the request program in the request end is executed first, the operation of the attacker cannot be executed after the token is deleted, even if the operation of the attacker is executed first, the service node only executes the operation that the request program of the request end needs to be executed originally (because the information parameters and the like of the request are stored in the trusted node and matching verification can be carried out on the service node), other effects cannot be caused, and if security enhancement measures of identity verification of the service node are used, the attacker cannot forge the request from the service node even if the token is intercepted, because the attacker cannot pass the identity verification of the trusted node. Multiple bad condition assumptions are made and countermeasures are taken for the attack surface, and even if the assumptions are satisfied at the same time, the influence or the security problem on the verification and authentication of the application cannot be caused, so that the high security of the verification and authentication of the application on the request is further ensured.

In single sign-on, the network request verification authentication method based on the trusted node provided by the embodiment of the aspect of the application can realize single sign-on, and the trusted node can be used as an identity authentication center of network service. The user only needs to log in the trusted node, and the authorized access can be performed in all the service nodes which trust the trusted node according to the access authority of the user by using the flow of verification and authentication, the fine granularity control of the request level rather than the session level is used, and the user can log out of the trusted node and lose the access authority of other service nodes, so that all the authorized service nodes can be accessed after the trusted node logs in only one point.

In the interface authentication between network services, the network request verification authentication method based on the trusted node provided by the embodiment of the application can also be used for authentication between network services, an authentication service or gateway service is used as the trusted node, identity credentials and authority information of the service are stored, when one service calls an interface of another service, the caller service can also be regarded as a visitor, and can be used as a request end (provided with a request program) under the embodiment of the application, when the verification and authentication are performed by using the flow of the network request verification authentication method based on the trusted node provided by the embodiment of the application, each service can manage and synchronize specific call authorities (such as service level, interface level, resource level and the like) owned by other services according to the authority verification mode in the embodiment of the application, so that the interface authentication between network services can be realized, and can also be used for managing the service in a micro service authority group, and can be used for opening interfaces, integrating applications between interconnection, or data, calculating and learning federal and federal scenes and the like. The trusted node in the application scene can also carry out interface authentication for the call between network services, wherein consumer services realize the corresponding part of the request end in the flow of the method, provider services realize the part of the service node in the flow of the method, fine-granularity authority configuration and security policy configuration can be carried out, the trusted node can become an authentication center of a lightweight interface, and does not bear all the access flow of interface call like a traditional API authentication gateway, but can realize fine-granularity authority configuration, security regulation and request control only by providing the production and consumption of tokens, for example, the maximum request number of a certain caller in a certain period can be controlled, and the method is used for realizing subscription type API service.

The trusted node related in the network request verification authentication method based on the trusted node provided by the embodiment of the application can be used as a management center of unified identity access of a cluster (such as a micro-service cluster formed by a plurality of network services) to intensively store information of all visitors and service nodes, authority of the visitors to different resources of different services and the like, and provide unified authentication and authorization services for the service nodes, so that the security of authentication can be enhanced by various verification modes such as double factor verification, mailbox verification, short message verification, mobile terminal scan code verification and the like, request IP/region verification can be flexibly configured, illegal requests can be intercepted by modes such as request equipment verification and the like, operation records of an administrator can be saved, abnormal requests can be audited and detected, and unified fine-grained identity access management can be realized.

In the management of network services, in the network request verification authentication method based on the trusted node provided by the embodiment of the application, different security policies are configured for an administrator according to security requirements of different management operations, and verification authentication is performed on the management operations of the administrator.

Further, the authentication method based on the network request verification of the trusted node provided by the embodiment of the application can be applied to the embodiment of completely relying on the trusted node to perform authentication and authorization, the service node does not need to maintain the information such as the identification, the key and the authorization of all authorized users, only needs to configure the interface address of the trusted node and the identity credentials (such as the identification and the key) registered in the trusted node, the information stored in the token generated by the trusted node also needs to contain the authorization owned by the user, and after the service node acquires the response through the token consumption interface (or using the cached token response or directly decoding the token), the generation and the configuration of all the user authorization can be completed in the embodiment of the degradation version of the requested interface and the corresponding authorization, the service node does not need to be synchronized with the service node, the service node is easier to maintain, and the service node also needs to trust the authentication result of the trusted node in a 'unconditional' way, which is equivalent to serving the trusted node as the user authentication service of the trusted node.

According to another aspect of the present application, there is also provided a non-volatile storage medium having stored thereon computer readable instructions which, when executed by a processor, cause the processor to implement a trusted node based network request verification authentication method as described above.

According to another aspect of the present application, there is also provided a service node for verifying authentication based on a network request of a trusted node, the service node comprising:

one or more processors;

a computer readable medium for storing one or more computer readable instructions,

the one or more computer-readable instructions, when executed by the one or more processors, cause the one or more processors to implement a method for verifying authentication based on a network request of a trusted node at a service node as described above.

The details of each embodiment in the service node based on the network request verification authentication of the trusted node can be found in the corresponding portion of the embodiment of the service node based on the network request verification authentication method of the trusted node, which is not described herein.

According to another aspect of the present application, there is also provided a trusted node for verifying authentication based on a network request of the trusted node, the trusted node comprising:

one or more processors;

the one or more computer-readable instructions, when executed by the one or more processors, cause the one or more processors to implement a method for verifying authentication based on a network request of a trusted node as described above.

The details of each embodiment of the trusted node based on the network request verification authentication of the trusted node can be found in the corresponding parts of the embodiments of the method for verifying authentication of the trusted node based on the network request of the trusted node, and will not be described herein.

According to another aspect of the present application, there is also provided a request end for verifying authentication based on a network request of a trusted node, the request end including:

one or more processors;

The details of each embodiment in the request end for verifying authentication based on the network request of the trusted node can be found in the corresponding parts of the embodiments of the request end for verifying authentication based on the network request of the trusted node, and are not described herein.

In summary, the service node in this embodiment of the present application receives, through an interface address, a target network request sent by a request end or a trusted node carrying the token and an identifier of the trusted node, where the token is generated when verifying that the visitor has permission to execute the target network request in the service node after the trusted node receives, through a token production interface, a first request that the request end carries an identity permission credential of a visitor to initiate the target network request, an information parameter of the target network request, and an identifier of the requested service node; the token is carried to send a second request to a token consumption interface corresponding to the identifier of the trusted node, so that the trusted node verifies whether the token is valid or not through the token consumption interface; receiving a validity response result of the token returned by the trusted node, information parameters corresponding to the token and an identity authority credential of the visitor; and checking and authenticating the validity response result of the token, the information parameter returned by the trusted node and the identity authority certificate of the visitor, if the checking and the authentication are successful, executing the operation corresponding to the target network request, and returning the execution result to the request end or the trusted node so that the trusted node forwards the execution result to the request end.

In the embodiment of the application, a target network request is initiated to a service node through a request end in a non-proxy mode or initiated to the service node by a trusted node trusted by a requested end in a proxy mode, wherein the trusted node and the service node both store rights of authenticating target network services, the trusted node provides rights of the initiated target network request, and the service node realizes verification and authentication of the request of the target network request, and tamper resistance and illegal request execution, so that the security of all network requests is ensured, and the application method and the application device can be suitable for practical application scenes with higher security.

It should be noted that the present application may be implemented in software and/or a combination of software and hardware, for example, using Application Specific Integrated Circuits (ASIC), a general purpose computer or any other similar hardware device. In one embodiment, the software programs of the present application may be executed by a processor to implement the steps or functions as described above. Likewise, the software programs of the present application (including associated data structures) may be stored on a computer readable recording medium, such as RAM memory, magnetic or optical drive or diskette and the like. In addition, some steps or functions of the present application may be implemented in hardware, for example, as circuitry that cooperates with the processor to perform various steps or functions.

Furthermore, portions of the present application may be implemented as a computer program product, such as computer program instructions, which when executed by a computer, may invoke or provide methods and/or techniques in accordance with the present application by way of operation of the computer. Program instructions for invoking the methods of the present application may be stored in fixed or removable recording media and/or transmitted via a data stream in a broadcast or other signal bearing medium and/or stored within a working memory of a computer device operating according to the program instructions. An embodiment according to the present application comprises an apparatus comprising a memory for storing computer program instructions and a processor for executing the program instructions, wherein the computer program instructions, when executed by the processor, trigger the apparatus to operate a method and/or a solution according to the embodiments of the present application as described above.

It will be evident to those skilled in the art that the present application is not limited to the details of the foregoing illustrative embodiments, and that the present application may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. The present embodiments are, therefore, to be considered in all respects as illustrative and not restrictive, the scope of the application being indicated by the appended claims rather than by the foregoing description, and all changes which come within the meaning and range of equivalency of the claims are therefore intended to be embraced therein. Any reference sign in a claim should not be construed as limiting the claim concerned. Furthermore, it is evident that the word "comprising" does not exclude other elements or steps, and that the singular does not exclude a plurality. A plurality of units or means recited in the apparatus claims can also be implemented by means of one unit or means in software or hardware. The terms first, second, etc. are used to denote a name, but not any particular order.

Claims

1. A network request verification authentication method based on a trusted node, which is applied to a service node, wherein the method comprises the following steps:

2. The method of claim 1, wherein the verifying and authenticating the validity response result of the token, the information parameter returned by the trusted node, and the identity authority credential of the visitor comprises:

3. The method of claim 1, wherein the second request further carries an identity credential of the service node to cause the trusted node to verify whether the identity credential is valid.

4. A network request verification authentication method based on a trusted node, which is applied to the trusted node, wherein the method comprises the following steps:

the service node performs verification and authentication based on the validity response result of the token, the corresponding information parameter and the identity authority certificate of the visitor, and executes the current operation corresponding to the target network request and sends the execution result to the request end when the verification and authentication are successful;

Wherein, the generating a token, while correspondingly storing the information parameter and the identity authority credential of the visitor, further comprises: storing identity credentials of the service node;

wherein the second request further carries an identity credential of the service node, wherein the verifying whether the token is valid further comprises: and verifying whether the identity credential is valid or not based on the stored identity credential of the service node and the identity credential of the service node carried by the second request.

5. The method of claim 4, wherein the generating a token while correspondingly storing the information parameter and the visitor's identity authority credential further comprises:

wherein said verifying whether said token is valid comprises:

verifying whether the token is valid for the validity period.

6. The method of claim 4, wherein the retrieving the stored information parameter corresponding to the token and the visitor's identity authority credential, the method further comprises:

Deleting or marking the stored record of invalid token and corresponding information parameter and identity authority certificate of the visitor.

7. The method of claim 4, wherein the method further comprises:

configuring different security levels of the network request to correspond to different verification logic;

wherein before said verifying whether said visitor has the right to execute said target network request in said service node, said method further comprises:

determining a security level corresponding to the target network request;

8. A network request verification authentication method based on a trusted node, which is applied to a request end, wherein the method comprises the following steps:

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

10. A service node for verifying authentication based on a network request of a trusted node, the service node comprising:

One or more processors;

the one or more computer-readable instructions, when executed by the one or more processors, cause the one or more processors to implement the method of any of claims 1 to 3.

11. A trusted node for verifying authentication based on a network request of the trusted node, the trusted node comprising:

one or more processors;

when executed by the one or more processors, cause the one or more processors to implement the method of any of claims 4 to 7.

12. A request end for verifying authentication based on a network request of a trusted node, the request end comprising:

one or more processors;

the one or more computer-readable instructions, when executed by the one or more processors, cause the one or more processors to implement the method of claim 8.