Inter-service authentication method and device, equipment and storage medium

Abstract

The invention relates to the field of data processing, provides an inter-service authentication method and device, equipment and a storage medium, and is used for reducing the leakage risk of authentication information and calling relations during inter-service authentication. The method comprises the following steps: in response to a service calling request triggered for a target service, determining a target authentication rule for calling the target service in at least one reference authentication rule; the at least one reference authentication rule is an authentication rule associated with the calling party and obtained from an authentication rule set after the calling party obtains the corresponding authentication rule set based on a pre-stored first rule version identifier; sending the target authentication rule and the first rule version identifier to the target service, so that the target service returns an authentication result after verifying the first rule version identifier and the target authentication rule; and when the received authentication result represents that the authentication is passed, calling the target service based on the service calling request.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of data processing, and provides an inter-service authentication method and device, equipment and a storage medium. BACKGROUND

[0002] The essence of inter-service authentication is to determine whether the calling party has the permission to operate part or all resources of the called party. In the related art, assuming that the called party is a target service, the calling party will request a valid calling token from an authentication management end when the calling party needs to call the target service, and then carries the calling token to call the target service. After receiving the calling token, the target service verifies the validity of the calling token with the authentication management end, and then returns the corresponding authentication result to the calling party according to the verification result; wherein, when the authentication result is authentication passed, the target service can allow the calling party to call part or all resources.

[0003] However, when the above authentication method is used, the authentication process is usually completed by relying on the communication between the service and the authentication management end, but each communication will have the possibility of message leakage, and each increase in the authentication process will increase the risk of message leakage. Therefore, in the case where multiple communications are required to implement the authentication process, the use of the above authentication method will greatly increase the probability of leakage of inter-service authentication information and calling relationship; further, once the inter-service authentication information and calling relationship are leaked, it will also pose a great danger to the information security in the authentication system. SUMMARY

[0004] The embodiments of the present application provide an inter-service authentication method, device, equipment and storage medium to solve the problem of greater risk of leakage of authentication information and calling relationship when inter-service authentication is performed in the related art.

[0005] In a first aspect, the embodiments of the present application provide an inter-service authentication method applied to a calling party in a plurality of services, comprising:

[0006] In response to a service calling request triggered for a target service, determining a target authentication rule for calling the target service in at least one reference authentication rule; the at least one reference authentication rule is an authentication rule associated with the calling party obtained from an authentication rule set by the calling party based on a pre-stored first rule version identifier; sending the target authentication rule and the first rule version identifier to the target service, so that the target service returns an authentication result after verifying the first rule version identifier and the target authentication rule; when the received authentication result represents authentication passed, calling the target service based on the service calling request.

[0007] In a possible implementation manner, the at least one reference authentication rule is obtained by: taking a latest received rule version identifier as a first rule version identifier; adding corresponding signature information to the first rule version identifier based on a service identifier of the invoker; and obtaining at least one reference authentication rule associated with the invoker from an authentication rule set corresponding to the first rule version identifier based on the signature information.

[0008] In a possible implementation manner, the authentication rule set is obtained by: obtaining a plurality of authentication information, each of which includes a calling condition between two services and key information of the two services respectively; taking the plurality of authentication information as leaf nodes, and pairing the obtained leaf nodes two by two to obtain at least one node pair; repeatedly performing the following operations until a root node is obtained: creating a corresponding parent node based on the at least one node pair obtained currently; pairing the newly created parent nodes two by two to obtain a new at least one node pair when the newly created parent nodes are not root nodes; and taking the rule tree as the authentication rule set; wherein each authentication rule included in the authentication rule set is a path from a corresponding leaf node to a root node, and a rule version identifier of the authentication rule set is determined based on the root node in the rule tree.

[0009] In a possible implementation manner, the creating a corresponding parent node based on the at least one node pair obtained currently includes: for the at least one node pair obtained currently, performing the following operations respectively: when a node in a node pair is a leaf node, performing hash calculation on the authentication information corresponding to each node pair respectively to determine a hash value of each node; when the node in the node pair is a non-leaf node, obtaining a hash value stored in each node; combining the hash values of each node in the node pair, and performing hash calculation on the combined hash value to determine a parent node hash value; and creating a parent node of the node pair based on the parent node hash value; the parent node is used to store the parent node hash value.

[0010] In a possible implementation manner, the calling condition includes one or more of the following: a service corresponding to each of the invoker and the target service in the plurality of services; one or more interfaces in the target service that allow the invoker to call; different functions of the target service corresponding to different interfaces; and a time interval during which the invoker is allowed to call the target service.

[0011] In a second aspect, a service-to-service authentication method is applied to a target service in a plurality of services, and includes the following steps.

[0012] receive a target authentication rule and a first rule version identifier sent by a calling party; the target authentication rule is an authentication rule used by the calling party when invoking a target service; the first rule version identifier is used to identify a version of a set of authentication rules used by the calling party; determine an authentication result based on a version verification result of the first rule version identifier and a rule verification result of the target authentication rule; send the authentication result to the calling party, so that the calling party invokes the target service based on a service invocation request triggered for the target service when the received authentication result indicates that the authentication is passed.

[0013] In a possible implementation manner, the determining the authentication result based on the version verification result of the first rule version identifier and the rule verification result of the target authentication rule comprises: verifying the first rule version identifier based on at least one second rule version identifier stored in advance, to obtain the version verification result; the second rule version identifier is a version identifier of a set of valid authentication rules; verifying the target authentication rule based on at least one invalid authentication rule stored in advance, to obtain the rule verification result; and determining the authentication result based on the version verification result and the rule verification result.

[0014] In a possible implementation manner, the at least one second rule version identifier is determined according to the following method: receiving update information of a rule version identifier; the update information includes a latest version of a rule version identifier and a currently valid historical rule version identifier; and storing the latest version of the rule version identifier and the currently valid historical rule version identifier as the second rule version identifier.

[0015] In a possible implementation manner, the verifying the first rule version identifier based on the at least one second rule version identifier stored in advance, to obtain the version verification result, comprises: determining that the version verification is passed when there is a same version identifier as the first rule version identifier in the at least one second rule version identifier; and determining that the version verification is not passed when there is no same version identifier as the first rule version identifier in the at least one second rule version identifier.

[0016] In a possible implementation manner, the verifying the target authentication rule based on the at least one invalid authentication rule stored in advance, to obtain the rule verification result, comprises: determining that the rule verification is passed when the target authentication rule is not included in the at least one invalid authentication rule; and determining that the rule verification is not passed when the target authentication rule is included in the at least one invalid authentication rule.

[0017] In one possible implementation, the authentication rule set is a rule tree; the target authentication rule is a path from a leaf node to the root node in the rule tree; before determining the authentication result based on the version verification result and the rule verification result, the method further includes: determining a version verification identifier based on the hash value of each node in the path corresponding to the target authentication rule; when the version verification identifier is equal to the first rule version identifier, determining that the target authentication rule and the first rule version identifier belong to the same authentication rule set; when the version verification identifier is not equal to the first rule version identifier, determining that the target authentication rule and the first rule version identifier belong to different authentication rule sets.

[0018] In one possible implementation, determining the authentication result based on the version verification result and the rule verification result includes: determining authentication as passed when both the version verification result and the rule verification result are passed, and the target authentication rule and the first rule version identifier belong to the same authentication rule set; determining authentication as failed when either the version verification result or the rule verification result is failed, or when the target authentication rule and the first rule version identifier belong to different authentication rule sets.

[0019] Thirdly, embodiments of this application also provide an inter-service authentication device, applied to a caller in multiple services, including:

[0020] The rule determination unit is used to determine, in response to a service call request triggered for a target service, a target authentication rule for calling the target service from at least one reference authentication rule; the at least one reference authentication rule is an authentication rule associated with the caller obtained from the authentication rule set after the caller obtains the corresponding authentication rule set based on a pre-stored first rule version identifier.

[0021] A communication unit is configured to send the target authentication rule and the first rule version identifier to the target service, so that the target service returns an authentication result after verifying the first rule version identifier and the target authentication rule;

[0022] The service invocation unit is used to invoke the target service based on the service invocation request when the received authentication result indicates that the authentication has passed.

[0023] In one possible implementation, the at least one reference authentication rule is obtained by the communication unit in the following manner: taking the latest received rule version identifier as the first rule version identifier; adding corresponding signature information to the first rule version identifier based on the service identifier of the caller; and obtaining at least one reference authentication rule associated with the caller from the authentication rule set corresponding to the first rule version identifier based on the signature information.

[0024] In one possible implementation, the authentication rule set is obtained through the following method: acquiring multiple authentication information; each authentication information includes the calling conditions between two services and the key information of each of the two services; using the multiple authentication information as leaf nodes, and pairing the obtained multiple leaf nodes in pairs to obtain at least one node pair; repeating the following operations until the root node is obtained to obtain a rule tree: based on the currently obtained at least one node pair, creating corresponding parent nodes respectively; when the newly created parent nodes are not root nodes, pairing the newly created parent nodes in pairs to obtain at least one new node pair; using the rule tree as the authentication rule set; wherein, each authentication rule included in the authentication rule set is a path from the corresponding leaf node to the root node, and the rule version identifier of the authentication rule set is determined based on the root node in the rule tree.

[0025] In one possible implementation, the step of creating corresponding parent nodes based on at least one currently obtained node pair includes: performing the following operations on each of the at least one currently obtained node pair: when a node in a node pair is a leaf node, performing hash calculations on the authentication information corresponding to each node to determine the hash value of each node; when a node in a node pair is a non-leaf node, obtaining the hash value stored in each node; combining the hash values ​​of each node in the node pair and performing hash calculations on the combined hash values ​​to determine the hash value of the parent node; creating the parent node of the node pair based on the hash value of the parent node; the parent node is used to store the hash value of the parent node.

[0026] In one possible implementation, the invocation conditions include one or more of the following: the services corresponding to the invoker and the target service, respectively; one or more interfaces in the target service that the invoker is allowed to invoke; different functions of the target service corresponding to different interfaces; and the time interval during which the invoker is allowed to invoke the target service.

[0027] Fourthly, embodiments of this application also provide an inter-service authentication device, applied to a target service among multiple services, including:

[0028] A communication unit is used to receive a target authentication rule and a first rule version identifier sent by the caller; the target authentication rule is the authentication rule used by the caller when calling the target service; the first rule version identifier is used to identify the version of the authentication rule set used by the caller.

[0029] The authentication unit is used to determine the authentication result based on the version verification result of the first rule version identifier and the rule verification result of the target authentication rule;

[0030] The communication unit is further configured to send the authentication result to the caller, so that when the received authentication result indicates that the authentication is successful, the caller can invoke the target service based on the service invocation request triggered for the target service.

[0031] In one possible implementation, the authentication unit determines the authentication result based on the version verification result of the first rule version identifier and the rule verification result of the target authentication rule. Specifically, this involves: verifying the first rule version identifier based on at least one pre-stored second rule version identifier to obtain the version verification result; the second rule version identifier being a version identifier of a valid set of authentication rules; verifying the target authentication rule based on at least one pre-stored invalid authentication rule to obtain the rule verification result; and determining the authentication result based on the version verification result and the rule verification result.

[0032] In one possible implementation, the at least one second rule version identifier is determined according to the following method: the communication unit is configured to receive update information of the rule version identifier; the update information includes the latest version rule version identifier and the currently valid historical rule version identifier; the authentication unit is configured to store the latest version rule version identifier and the currently valid historical rule version identifier as the second rule version identifier.

[0033] In one possible implementation, the authentication unit verifies the first rule version identifier based on at least one pre-stored second rule version identifier to obtain the version verification result. Specifically, it is used to: determine that the version verification is passed when there is a version identifier that is the same as the first rule version identifier among the at least one second rule version identifier; and determine that the version verification is failed when there is no version identifier that is the same as the first rule version identifier among the at least one second rule version identifier.

[0034] In one possible implementation, the authentication unit verifies the target authentication rule based on at least one pre-stored invalid authentication rule to obtain the rule verification result. Specifically, it is used to: determine that the rule verification passes when the target authentication rule is not included in the at least one invalid authentication rule; and determine that the rule verification fails when the target authentication rule is included in the at least one invalid authentication rule.

[0035] In one possible implementation, the authentication rule set is a rule tree; the target authentication rule is a path from a leaf node to the root node in the rule tree; before determining the authentication result based on the version verification result and the rule verification result, the authentication unit is further configured to: determine a version verification identifier based on the hash value of each node in the path corresponding to the target authentication rule; when the version verification identifier is equal to the first rule version identifier, determine that the target authentication rule and the first rule version identifier belong to the same authentication rule set; when the version verification identifier is not equal to the first rule version identifier, determine that the target authentication rule and the first rule version identifier belong to different authentication rule sets.

[0036] In one possible implementation, the authentication unit determines the authentication result based on the version verification result and the rule verification result, specifically by: determining authentication as passed when both the version verification result and the rule verification result are passed, and the target authentication rule and the first rule version identifier belong to the same authentication rule set; determining authentication as failed when either the version verification result or the rule verification result is failed, or when the target authentication rule and the first rule version identifier belong to different authentication rule sets.

[0037] Fifthly, embodiments of this application also provide a computer device, including a processor and a memory, wherein the memory stores program code that, when executed by the processor, causes the processor to perform the steps of any one of the inter-service authentication methods described in the first or second aspect.

[0038] Sixthly, embodiments of this application also provide a computer-readable storage medium including program code, which, when the program product is run on a computer device, is used to cause the computer device to perform the steps of any one of the inter-service authentication methods described in the first or second aspect.

[0039] In a seventh aspect, embodiments of this application also provide a computer program product, including computer instructions, which are executed by a processor using the steps of any one of the inter-service authentication methods described in the first or second aspect.

[0040] The beneficial effects of this application are as follows:

[0041] This application provides a service authentication method, apparatus, device, and storage medium. In this method, the reference authentication rules associated with itself are obtained in advance based on the first rule version identifier, and the corresponding service can be called based on these reference authentication rules. That is, after each update of the authentication rule set, the call to other services can be realized by obtaining the reference authentication rules once. Therefore, it can avoid the need to communicate with the authentication management terminal every time a service is called, thereby minimizing the number of communications with the authentication management terminal and reducing the risk of leakage of authentication information call information.

[0042] Furthermore, since the caller can complete authentication by sending the target authentication rule and the first rule version identifier to the target service, there is no need to request authentication credentials from the authentication management end during the authentication process. Consequently, the target service does not need to verify the validity of the authentication credentials with the authentication management end. Therefore, the status of the authentication management end does not need to be considered when performing inter-service authentication. This enhances the flexibility of using authentication capabilities between services and avoids situations where authentication time is long and service response is slow due to poor communication with the authentication management end.

[0043] Other features and advantages of this application will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the application. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the written description, claims, and drawings. Attached Figure Description

[0044] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0045] Figure 1 A schematic diagram of an inter-service authentication method in the related technology provided in the embodiments of this application;

[0046] Figure 2 This is an optional schematic diagram of an application scenario in the embodiments of this application;

[0047] Figure 3 A flowchart illustrating the inter-service authentication method provided in this application embodiment;

[0048] Figure 4 A flowchart illustrating the method for determining the authentication rule set provided in this application embodiment;

[0049] Figure 5A schematic diagram of a leaf node provided in an embodiment of this application;

[0050] Figure 6 This is a schematic diagram illustrating the parent node creation process provided in an embodiment of this application.

[0051] Figure 7 A schematic diagram of the rule tree construction process provided in the embodiments of this application;

[0052] Figure 8 This is a schematic diagram illustrating another rule tree construction process provided in an embodiment of this application;

[0053] Figure 9 A schematic diagram of invalid authentication rules provided for embodiments of this application;

[0054] Figure 10 An exemplary flowchart of the inter-service authentication method provided in the embodiments of this application;

[0055] Figure 11 This is a schematic diagram of the inter-service authentication process provided in an embodiment of this application;

[0056] Figure 12 A schematic diagram of the structure of an inter-service authentication device provided in an embodiment of this application;

[0057] Figure 13 A schematic diagram of the structure of an inter-service authentication device provided in an embodiment of this application;

[0058] Figure 14 This is a schematic diagram of the hardware structure of a computer device according to an embodiment of this application;

[0059] Figure 15 This is a schematic diagram of the hardware structure of another computer device that applies an embodiment of this application. Detailed Implementation

[0060] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of this application will be clearly and completely described below with reference to the accompanying drawings of the embodiments of this application. Obviously, the described embodiments are only some embodiments of the technical solutions of this application, and not all embodiments. Based on the embodiments recorded in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the technical solutions of this application.

[0061] The design concept of the embodiments of this application is briefly introduced below:

[0062] The essence of inter-service authentication is for the called party to determine whether the calling party has permission to operate on some or all of its own resources. (See also...) Figure 1This diagram illustrates an inter-service authentication method provided in the embodiments of this application. Assuming the called party is the target service, when the caller needs to invoke the target service, it requests a valid invocation token from the authentication management terminal and then uses the token to invoke the target service. Upon receiving the invocation token, the target service verifies its validity with the authentication management terminal. After receiving the verification result from the authentication management terminal, it returns the corresponding authentication result to the caller based on the verification result. Where the authentication result is successful, the target service may allow the caller to invoke some or all of its resources.

[0063] However, when using the above authentication methods, the authentication process usually relies on communication between the service and the authentication management terminal. But each communication carries the possibility of message leakage. Each additional communication during the authentication process increases the risk of message leakage. Therefore, when multiple communications are required to complete the authentication process, using the above authentication methods will greatly increase the probability of leakage of authentication information and call relationships between services. Furthermore, once the authentication information and call relationships between services are leaked, it will also pose a great danger to the information security of the authentication system.

[0064] In view of this, embodiments of this application provide an inter-service authentication method, apparatus, device, and storage medium. In this method, a caller among multiple services can, in response to a service call request triggered for a target service, determine a target authentication rule for calling the target service from at least one pre-acquired reference authentication rule, and send the target authentication rule and a first rule version identifier to the target service. The target service then verifies the first rule version identifier and the target authentication rule and returns an authentication result. Upon receiving the authentication result indicating successful authentication, the target service can be invoked based on the service call request.

[0065] This method allows the caller to complete authentication simply by sending the target authentication rule and the first rule version identifier to the target service during the authentication process, without needing to communicate with the authentication management end. Therefore, compared to related technologies that require multiple interactions with the authentication management end for authentication, this method significantly reduces the number of communications, thereby avoiding the problem of authentication information leakage and maintaining the privacy of authentication data.

[0066] Furthermore, since the caller does not need to communicate with the authentication management system during the authentication process, the status of the authentication management system does not need to be considered during inter-service authentication. This enhances the flexibility of using authentication capabilities between services. It also avoids situations where authentication times are long and service responses are slow due to poor communication with the authentication management system.

[0067] The preferred embodiments of this application are described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are for illustration and explanation only and are not intended to limit this application. Furthermore, the embodiments and features in the embodiments of this application can be combined with each other without conflict.

[0068] Figure 2 One application scenario is illustrated, including a terminal device 210 and an authentication server 220. The terminal device 210 establishes a communication connection with the server 220 via a wired or wireless network. The terminal device 210 may include multiple services: Service 1, Service 2, ..., Service n. The authentication server 220 is the device that hosts the authentication management terminal, through which relevant personnel can manage authentication information. Each service can be a process or an application on the terminal device; for example, Service 1 could be an instant messaging application, Service 2 could be a browser, etc. This application does not limit this.

[0069] Taking a service call request as an example, where service 1 is the caller and service 2 is the target service, service 1 can determine the target authentication rule for calling service 2 from at least one pre-stored reference authentication rule, and then send the target authentication rule and the pre-stored first rule version identifier to service 2.

[0070] After receiving the first rule version identifier of the target authentication rule, Service 2 determines the authentication result based on the version verification result of the first rule version identifier and the rule verification result of the target authentication rule, and sends the authentication result to Service 1.

[0071] Once Service 1 determines that the returned authentication result indicates that the authentication has passed, it can invoke Service 2 according to the service invocation request.

[0072] Among them, at least one reference authentication rule pre-stored by Service 1 is the authentication rule associated with Service 1 that Service 1 requests from the authentication management terminal based on the pre-stored first rule version identifier.

[0073] It should be noted that the terminal device 210 in this application embodiment may be a smartphone, tablet computer, laptop computer, desktop computer, smart speaker, smartwatch, etc., but is not limited to these.

[0074] The authentication server 220 in this application embodiment can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDN), and big data and artificial intelligence platforms. This application does not impose any restrictions on these services.

[0075] It should be noted that, Figure 2 The application scenarios shown are merely illustrative and are not intended to limit the scope of this application.

[0076] See Figure 3 This is an exemplary flowchart of an inter-service authentication method provided in an embodiment of this application. This method can be applied to… Figure 2 The caller of multiple services included in the terminal device 210 shown may include the following steps 301-303:

[0077] Step 301: In response to a service call request triggered for the target service, determine the target authentication rule for calling the target service in at least one reference authentication rule.

[0078] Among them, at least one reference authentication rule can be an authentication rule associated with the caller obtained from the authentication rule set after the caller obtains the corresponding authentication rule set based on the pre-stored first rule version identifier.

[0079] In one possible implementation, see [link to relevant documentation]. Figure 4 This is a flowchart illustrating the method for determining the authentication rule set provided in this application embodiment. This method can be applied to... Figure 2 The authentication server 220 shown carries the authentication management terminal, and this process may include the following steps 401-404:

[0080] Step 401: Obtain multiple authentication information.

[0081] Each authentication message can include the conditions for invocation between the two services and the key information of each service. For example, the authentication message can be in the form of "Service 1 (Public Key X), Service 2 (Public Key Y) can be invoked", where public key A represents the public key of service 1, meaning that messages sent to service 1 can be encrypted using public key A. Similarly, public key B represents the public key of service 2, meaning that messages sent to service 2 can be encrypted using public key B.

[0082] In one possible implementation, the calling condition may include one or more of conditions (1) to conditions (3). For example, the calling condition may include condition (1), or the calling condition may include conditions (1) and conditions (2), or the calling condition may include conditions (1) and conditions (3), or the calling condition may include conditions (1), conditions (2) and conditions (3).

[0083] Conditions (1) to (3) are respectively:

[0084] Condition (1): Among multiple services, the caller and the target service are their respective services.

[0085] For example, the calling condition can be that service 1 can call service 2. In this case, the caller is service 1 and the target service is service 2. Alternatively, the calling condition can also be that service 2 can call service 1. In this case, the caller is service 2 and the target service is service 1.

[0086] Condition (2) is one or more interfaces that the caller is allowed to invoke in the target service.

[0087] Among them, different interfaces correspond to different functions of the target service.

[0088] For example, if service 1 can only call the query function of service 2, then the calling condition can be that service 1 can call the query interface of service 2.

[0089] Condition (3) specifies the time interval during which the caller is allowed to invoke the target service.

[0090] For example, the calling condition could be that service 1 can call service 2 between 8:00 and 18:00.

[0091] It should be noted that the calling conditions can also be set according to actual conditions or experience, and this application does not limit them.

[0092] Based on the above scheme, since different calling conditions can be set for different services, the flexibility of inter-service authentication can be greatly enhanced.

[0093] Optionally, the authentication information can be configured by relevant staff in the authentication management terminal. Alternatively, the authentication information can also be obtained by the authentication management terminal from a data table that includes multiple authentication information entries.

[0094] Step 402: Use multiple authentication information as leaf nodes, and pair the obtained leaf nodes in pairs to obtain at least one node pair.

[0095] Optionally, the order of the leaf nodes can be determined according to the order in which the authentication information is obtained. For example, if the authentication information is obtained in the order A->C->B, then the order of the leaf nodes is also A->C->B. If the authentication information can be configured by relevant personnel in the authentication management terminal, then the order in which the authentication information is obtained can be the configuration order in which the relevant personnel configure the authentication information in the authentication management terminal. If the authentication information is obtained by the authentication management terminal from a data table containing multiple authentication information entries, then the order in which the authentication information is obtained can be the order in which the authentication information is arranged in the data table.

[0096] In some embodiments, when pairing the resulting multiple leaf nodes, adjacent nodes can be paired according to the order of arrangement, and different node pairs may include different leaf nodes.

[0097] See Figure 5 This is a schematic diagram of a leaf node provided in an embodiment of this application. Figure 5 As shown, suppose the authentication management terminal obtains four authentication information pieces: Authentication Information 1: Service 1 (public key X) can call Service 2 (public key Y); Authentication Information 2: Service 1 (public key X) can call Service 3 (public key Z); Authentication Information 3: Service 2 (public key Y) can call Service 3 (public key Z); Authentication Information 4: Service 3 (public key Z) can call Service 1 (public key X). The authentication management terminal can then designate Authentication Information 1 as leaf node A, Authentication Information 2 as leaf node B, Authentication Information 3 as leaf node C, and Authentication Information 4 as leaf node D. By pairing the leaf nodes in order, we can obtain node pair 1 consisting of A and B, and node pair 2 consisting of C and D.

[0098] Based on the above scheme, by treating each authentication information as a leaf node, it can be ensured that each authentication information is independent of other authentication information, thus eliminating dependencies between them. This allows each authentication rule in the authentication rule set to be used independently; even if one authentication rule is invalidated, it will not affect the use of other authentication rules, thereby improving the flexibility of the authentication system.

[0099] Step 403: Repeat steps 4031-4032 until the root node is obtained, thus obtaining the rule tree:

[0100] Step 4031: Based on the at least one node pair obtained so far, create the corresponding parent node respectively.

[0101] In one possible implementation, step 4031 can be performed as follows: For at least one node pair currently obtained, perform the following operations respectively: When a node in a node pair is a leaf node, perform hash calculation on the authentication information corresponding to each node to determine the hash value of each node. When a node in a node pair is a non-leaf node, obtain the hash value stored in each node. Combine the hash values ​​of each node in a node pair, and perform hash calculation on the combined hash value to determine the hash value of the parent node. Based on the hash value of the parent node, create a parent node for the node pair. The parent node is used to store the hash value of the parent node, and non-leaf nodes are nodes in the rule tree other than leaf nodes and the root node.

[0102] See Figure 6 This is a schematic diagram illustrating the parent node creation process provided in an embodiment of this application. Assume the leaf node is as follows: Figure 5 As shown, the nodes include A, B, C, and D. Node pairs 1 consist of A and B, and node pair 2 consists of C and D. In step 4031, parent nodes for A and B, and parent nodes for C and D, can be created. Since A, B, C, and D are leaf nodes, their hash values ​​are calculated by hashing their respective authentication information: H(A), H(B), H(C), and H(D). The hash value of the parent node determined based on the hash values ​​of A and B is H(H(A) + H(B)). Based on this hash value, the parent node E for A and B is created, then H(E) = H(H(A) + H(B)). Similarly, the hash value of the parent node determined based on the hash values ​​of C and D is H(H(C) + H(D)). Based on this hash value, the parent node F for C and D is created, then H(F) = H(H(C) + H(D)).

[0103] It should be noted that the "+" above can also be replaced with "‖" to represent a combination of two hash values.

[0104] Step 4032: When the newly created parent nodes are not root nodes, pair the newly created parent nodes in pairs to obtain at least one new node pair.

[0105] When the number of newly created parent nodes is not unique, it can be determined that none of the newly created parent nodes are root nodes. When the number of newly created parent nodes is unique, it can be determined that the newly created parent node is the root node.

[0106] For example, such as Figure 6 As shown, when the created parent nodes include E and F, since the number is not unique, it can be determined that neither E nor F is a root node. At this time, E and F can be combined into node pair 3, and the process returns to step 4031.

[0107] When at least one node pair obtained is node pair 3 consisting of E and F, step 4031 can be performed as follows: Since E and F are non-leaf nodes, the hash value H(E) stored in E and the hash value H(F) stored in F can be obtained. Then, H(E) and H(F) are combined, and the hash value of the combined hash value H(E) + H(F) is hashed to determine the hash value of the parent node as H(H(E) + H(F)). Then, based on the hash value of the parent node, the parent node G of node pair 3 is created, and H(G) = H(H(E) + H(F)). At this time, since there is only one newly created parent node, it can be determined that G is the root node of the rule tree, and the rule tree is obtained.

[0108] based on Figure 5 The leaf nodes shown are Figure 6 The parent node creation process shown can be found in [reference needed]. Figure 7 This is a schematic diagram of the rule tree construction process provided in this application embodiment. First, leaf nodes corresponding to authentication information 1-authentication information 4 are created: AD, that is, the authentication information corresponding to A is "Service 1 (public key X) can call Service 2 (public key Y)", and the hash value of this authentication information is H(A); the authentication information corresponding to B is "Service 1 (public key X) can call Service 3 (public key Z)", and the hash value of this authentication information is H(B); the authentication information corresponding to C is "Service 2 (public key Y) can call Service 3 (public key Z)", and the hash value of this authentication information is H(C); the authentication information corresponding to D is "Service 3 (public key Z) can call Service 1 (public key X)", and the hash value of this authentication information is H(D). A and B are combined into node pair 1, and C and D are combined into node pair 2. Create parent node E for node pair 1 and parent node F for node pair 2. The hash value stored in E is H(E) = H(H(A) + H(B)), and the hash value stored in F is H(F) = H(H(C) + H(D)). Then, combine the newly created parent nodes E and F to form node pair 3, and create parent node G for node pair 3. The hash value stored in G is H(G) = H(H(E) + H(F)). Since the only newly created parent node is G (i.e., one node), it can be determined that G is the root node. At this point, the rule tree construction is complete, and the rule tree is obtained.

[0109] In one possible implementation, when the number of authentication information obtained in step 401 is odd, that is, when the number of leaf nodes is odd, or when the number of newly created parent nodes in step 4031 is an odd number greater than 1, the last node can be copied when pairing the currently obtained nodes, so that the last node and itself are combined into a node pair, and then the parent node of the node pair is determined.

[0110] For example, suppose the authentication management terminal obtains 5 authentication information pieces.Figure 5 In addition to the authentication information shown, we also obtained: Authentication Information 5: Service 1 (public key X) can call Service 4 (public key W). Therefore, authentication information 5 can be used as a leaf node H. When pairing leaf nodes in order, since the number of leaf nodes is odd, H may not be able to pair with other leaf nodes. Therefore, H can be copied so that H can be combined with H to form a node pair.

[0111] In another possible implementation, when the number of leaf nodes is odd, or the number of newly created parent nodes is an odd number greater than 1, the last node can be kept as a reserved node when pairing the currently obtained nodes. When the number of newly created parent nodes is odd in the next iteration, the last node of the newly created parent nodes can be combined with the reserved node to form a node pair. Then, steps 4031 and 4032 can be repeated to obtain the rule tree.

[0112] It's important to note that in this method, determining whether a newly created parent node is the root node involves not only checking if the number of newly created parent nodes is one, but also determining if there are any unpaired reserved nodes. That is, if the number of newly created parent nodes is one and there are no unpaired reserved nodes, then the newly created parent node is determined to be the root node. Conversely, if the number of newly created parent nodes is not one, or if the number of newly created parent nodes is one but there are unpaired reserved nodes, then the newly created parent node is determined not to be the root node.

[0113] For example, see Figure 8 This is a schematic diagram illustrating another rule tree construction process provided in an embodiment of this application. For example... Figure 8As shown, leaf nodes can include A1-A6, resulting in three node pairs: A1 and A2, A3 and A4, and A5 and A6. Then, following the parent node creation method in step 4031, we obtain the parent node for A1 and A2: B1, where the hash value stored in B1 is H(B1) = H(H(A1) + H(A2)); the parent node for A3 and A4: B2, where the hash value stored in B2 is H(B2) = H(H(A3) + H(A4)); and the parent node for A5 and A6: B3, where the hash value stored in B3 is H(B3) = H(H(A5) + H(A6)). When pairing the newly created parent nodes, B3 can be reserved as a node, and then the parent node for B1 and B2: C1 can be created, where the hash value stored in C1 is H(C1) = H(H(B1) + H(B2)). At this point, C1 and B3 can be combined into a node pair, and the parent node D1 of C1 and B3 can be obtained. The hash value stored in D1 is H(D1) = H(H(C1) + H(B3)). Since the number of newly created parent nodes is 1 and there are no unpaired reserved nodes, D1 can be determined as the root node of the rule tree, thus obtaining the constructed rule tree.

[0114] Step 404: Use the rule tree as a set of authentication rules.

[0115] The authentication rule set includes each authentication rule as a path from the corresponding leaf node to the root node, and each path can carry the hash values ​​of each node included in the path.

[0116] For example, Figure 7 When the rule tree shown is used as a set of authentication rules, it includes four authentication rules, corresponding to authentication information 1 through 4. Specifically, authentication rule 1 corresponds to authentication information 1: A->E->G, and can carry the hash values ​​of A, E, and G; authentication rule 2 corresponds to authentication information 2: B->E->G, and can carry the hash values ​​of B, E, and G; authentication rule 3 corresponds to authentication information 3: C->F->G, and can carry the hash values ​​of C, F, and G; and authentication rule 4 corresponds to authentication information 4: D->F->G, and can carry the hash values ​​of D, F, and G.

[0117] For example, the rule tree mentioned above can be a Merkle tree, the root node of the rule tree can be Merkleroot, and each authentication rule is a Merkle path.

[0118] In one possible implementation, the rule version identifier of the authentication rule set can be determined based on the root node. Specifically, the authentication management terminal can distribute the root node in the rule tree to each service and use the hash value of the root node as the rule version identifier of the current authentication rule set. For example, suppose the current authentication rule set is as follows:Figure 7 As shown, the current rule version is identified as H(G).

[0119] In another possible implementation, the rule version identifier of the authentication rule set can also be a version number. Specifically, the authentication management terminal can set an initial version number for the authentication rule set, and then increment the current version number by a fixed value after each update to obtain a series of consecutive version numbers as the rule version identifier for the authentication rule set. For example, assuming the fixed value is 1, and the current version number of the authentication rule set is 1210, then after the next update, the version number of the authentication rule set will be adjusted to 1211.

[0120] In some embodiments, the rule tree can be maintained using the following methods 1)-3):

[0121] Method 1), add authentication rules.

[0122] When it is necessary to add authentication rules to the authentication rule set, the rule tree can be refreshed according to steps 401-404 to obtain the updated authentication rule set and update the rule version identifier.

[0123] Optionally, a rule tree refresh operation can be performed whenever the number of obtained authentication information reaches a certain threshold. Alternatively, a rule tree refresh operation can be performed every time new authentication information is obtained; this application does not limit this to any particular method.

[0124] Method 2), delete the authentication rules.

[0125] When it is necessary to delete an authentication rule from the current authentication rule set, there is no need to update the rule tree synchronously. Instead, the authentication rule can be added as an invalid authentication rule to the invalid rule list. When an invalid authentication rule is added to the invalid rule list, the newly added invalid authentication rule is distributed to each of the multiple services, or distributed to the service associated with the invalid authentication rule.

[0126] Optionally, when adding an invalid authentication rule to the invalid rule list, you can add the hash value of the leaf node corresponding to the invalid authentication rule to the invalid rule list. See also Figure 9 This is a schematic diagram of invalid authentication rules provided in an embodiment of this application. Suppose that it is necessary to delete authentication rule 2 corresponding to authentication information 2 and authentication rule 3 corresponding to authentication information 3. In this case, the hash value H(B) of the leaf node B corresponding to authentication rule 2 and the hash value H(C) of the leaf node C corresponding to authentication rule 3 can be added to the invalid rule list.

[0127] Method 3), reorganize the rule tree.

[0128] The leaf nodes corresponding to invalid authentication rules in the rule tree can be deleted. Based on the deleted leaf nodes, steps 401-404 are used to refresh the rule tree, resulting in an updated set of authentication rules, and the rule version identifier is updated. By reorganizing the rule tree, tree space can be freed up.

[0129] Optionally, the authentication management terminal can periodically reorganize the rule tree, for example, once a month. Alternatively, the authentication management terminal can also reorganize the rule tree when the number of invalid authentication rules included in the rule tree reaches a certain proportion, for example, when the number of invalid authentication rules reaches 50% of the total number of authentication rules, the rule tree can be reorganized.

[0130] In one possible implementation, at least one reference authentication rule is obtained by: using the latest received rule version identifier as the first rule version identifier; adding corresponding signature information to the first rule version identifier based on the caller's service identifier; and then, based on the signature information, retrieving at least one reference authentication rule associated with the caller from the authentication rule set corresponding to the first rule version identifier.

[0131] Specifically, each service that can act as a caller can use the latest received rule version identifier as the first rule version identifier upon receiving a new rule version identifier. The caller can then construct a signature for the first rule version identifier based on the pre-stored key information from the authentication management terminal and its own service identifier. This signature is then sent to the authentication management terminal, which returns at least one reference authentication rule associated with the caller from the authentication rule set corresponding to the first rule version identifier.

[0132] For example, when the first rule version is identified by the hash value in the Merkle root, the caller can sign the Merkle root to obtain Sign(root) and send Sign(root) to the authentication management terminal. The authentication management terminal verifies the signature using the corresponding key information and, after confirming that the verification is successful, returns all Merkle paths in the Merkle tree corresponding to the Merkle root that are associated with the caller.

[0133] Optionally, the reference authentication rule associated with the caller can be the authentication rule for the caller that is included in the corresponding authentication information. For example, when the caller is service 1, the reference authentication rule can be the authentication rule corresponding to the authentication information of service 1 as the caller, and the authentication rule corresponding to the authentication information of service 1 as the target service.

[0134] Optionally, the reference authentication rules associated with the caller can also be the authentication rules for the service corresponding to the caller in the corresponding authentication information. For example, when the caller is service 1, the reference authentication rules can only include the authentication rules corresponding to the authentication information of service 1 as the caller.

[0135] In some embodiments, when maintaining the rule tree, after updating the rule tree version, historical versions of the rule tree may still be valid. In this case, when issuing update information for rule version identifiers to multiple services each time, the latest version of the authentication rule set and the currently valid historical rule version identifiers can be issued. For example, when the rule version identifier is a version number, the latest version number may be 1230, but the authentication rule set with historical version numbers 1210-1229 may still be valid. In this case, in addition to issuing the root node with version number 1230, the list of currently valid historical version numbers 1210-1229 can also be issued.

[0136] Based on the above scheme, when constructing the authentication rule set through the rule tree, since the leaf nodes are not related to each other, the dependency between authentication information can be reduced as much as possible. This means that even if one authentication information is invalid, other authentication information in the authentication rule set can still be used, so there is no need to frequently reorganize the rule tree, thereby reducing the frequency of information updates and the amount of data.

[0137] In one possible implementation, an authentication system can be shared by multiple tenants, each of which is an independent subdomain and can therefore build its own set of authentication rules. Each tenant can maintain its own set of authentication rules, and updates to the authentication rule set can be distributed to the corresponding services of that tenant.

[0138] For example, an authentication system may include tenant 1 and tenant 2. The authentication system may also include rule tree 1 corresponding to tenant 1 and rule tree 2 corresponding to tenant 2. Rule tree 1 is maintained by tenant 1, and after rule tree 1 is updated, the update information is sent to the service corresponding to tenant 1. Similarly, rule tree 2 is maintained by tenant 2, and after rule tree 2 is updated, the update information is sent to the service corresponding to tenant 2.

[0139] Step 302: Send the target authentication rule and the first rule version identifier to the target service so that the target service can return the authentication result after verifying the first rule version identifier and the target authentication rule.

[0140] When the rule version identifier is the hash value of the root node, the caller can send the target authentication rule and the root node corresponding to the first rule version identifier to the target service.

[0141] When the rule version identifier is a version number, the caller can send the target authentication rule, the first rule version identifier, and the root node corresponding to the first rule version identifier to the target service.

[0142] Step 303: When the received authentication result indicates that the authentication is successful, invoke the target service based on the service invocation request.

[0143] If the authentication result indicates that the authentication is successful, the caller can establish a connection with the target service. Subsequent communication within this connection does not require the aforementioned inter-service authentication; that is, subsequent communication within this connection does not require sending the target authentication rule and the first rule version identifier again. However, once the connection is closed, upon receiving a service call request, it is still necessary to re-verify whether the caller has the permission to call the target service using the aforementioned inter-service authentication method.

[0144] After establishing a connection between the caller and the target service, to ensure the accuracy of business messages in subsequent communications, the caller can send an authentication credential constructed using its own private key to the target service, exchange keys, and construct a temporary symmetric key. In subsequent communications, for each business message, a hash-based message authentication code (HMAC) is generated using this symmetric key, allowing the target service to verify the correctness and integrity of the business message via HMAC. It should be noted that the key exchange method can refer to the Diffie-Hellman (DH) key exchange process in related technologies, and the message verification process can refer to the HMAC-based message verification process in related technologies; this application will not elaborate on these aspects.

[0145] In some embodiments, when invoking a target service based on a service invocation request, the target service can be invoked according to the invocation conditions included in the service invocation request and the target authentication rules. For example, if the invocation conditions include that service 1 can only invoke the query interface of service 2, then if the service invocation request instructs service 1 to invoke the payment interface of service 2, service 2 can return information indicating that the invocation failed.

[0146] See Figure 10 This is an exemplary flowchart of an inter-service authentication method provided in an embodiment of this application. This method can be applied to… Figure 2 The target service among the multiple services included in the terminal device 210 shown may include the following steps 1001-1003:

[0147] Step 1001: Receive the target authentication rule and the first rule version identifier sent by the caller.

[0148] Among them, the target authentication rule is the authentication rule used by the caller when invoking the target service. The first rule version identifier is used to identify the version of the set of authentication rules used by the caller.

[0149] The content received by the target service can be found in the content sent by the caller in step 302, and will not be repeated here.

[0150] Step 1002: Determine the authentication result based on the version verification result of the first rule version identifier and the rule verification result of the target authentication rule.

[0151] In one possible implementation, step 1002 can be performed as follows: The target service verifies the first rule version identifier based on at least one pre-stored second rule version identifier to obtain a version verification result. Then, it verifies the target authentication rule based on at least one pre-stored invalid authentication rule to obtain a rule verification result. Finally, based on the version verification result and the rule verification result, it determines the authentication result.

[0152] The second rule version identifier is the version identifier of the valid authentication rule set.

[0153] Based on the above scheme, since the first rule version identifier and the target authentication rule can be verified separately by using the pre-stored second rule version identifier and invalid authentication rule, there is no need to communicate with the authentication management terminal to identify the process and service of the caller, thereby reducing the number of communications between the target service and the authentication management terminal.

[0154] In some embodiments, at least one second rule version identifier is determined by the target service according to the following method: the target service receives update information of the rule version identifier issued by the authentication management terminal, and then stores the latest version rule version identifier and the currently valid historical rule version identifier included in the update information as the second rule version identifier. For example, if the latest version rule version identifier is 1234 and the currently valid historical rule version identifiers are 1211-1233, then version numbers 1211-1234 can all be used as the second rule version identifier.

[0155] It should be noted that a detailed description of the rule version identifier can be found in [link to relevant documentation]. Figure 4 The relevant descriptions in the method embodiments shown are not repeated here.

[0156] Based on the above scheme, since some services may not receive the latest version rule version identifier of the authentication rule set in actual application, in this case, by using both the latest version rule version identifier and the currently valid historical rule version identifier as the second rule version identifier, the authentication failure caused by not receiving the latest version rule version identifier of the authentication rule set can be avoided, thereby improving the authentication accuracy.

[0157] In one possible implementation, the target service verifies the first rule version identifier based on at least one pre-stored second rule version identifier. When obtaining the version verification result, if there is a version identifier in at least one second rule version identifier that is the same as the first rule version identifier, the version verification is determined to be successful; if there is no version identifier in at least one second rule version identifier that is the same as the first rule version identifier, the version verification is determined to be unsuccessful.

[0158] For example, assuming the second rule version identifier includes 1211-1234, if the first rule version identifier is 1233, then since the second rule version identifier includes 1233, the version verification can be determined to be successful; if the first rule version identifier is 1210, then since the second rule version identifier does not include 1210, the version verification can be determined to be unsuccessful.

[0159] Based on the above scheme, we can first determine whether the authentication rule set used by the caller is valid by verifying the rule version identifier. If it is invalid, we can directly determine that the authentication fails, thereby reducing the authentication workload and improving the authentication efficiency.

[0160] In one possible implementation, the target service verifies the target authentication rule based on at least one pre-stored invalid authentication rule. When the rule verification result is obtained, the rule verification is determined to be successful if the target authentication rule is not included in at least one invalid authentication rule; and it is determined to fail if the target authentication rule is included in at least one invalid authentication rule.

[0161] For example, suppose the currently stored invalid authentication rule is as follows: Figure 9 As shown, including H(B) and H(C), if the hash value of the leaf node in the target authentication rule is H(B) or H(C), it can be determined that the pre-stored invalid authentication rules include the target authentication rule, and the rule verification fails; if the hash value of the leaf node in the target authentication rule is not H(B) or H(C), it can be determined that the pre-stored invalid authentication rules do not include the target authentication rule, and the rule verification passes.

[0162] Based on the above scheme, by adding the verification of invalid authentication rules, it is possible to avoid refreshing the rule tree even when a small portion of the authentication information in the rule tree is invalid, thereby reducing the number of rule tree updates and the amount of computation on the authentication management end.

[0163] In one possible implementation, the target service can verify the correctness of the information included in the authentication request before determining the authentication result. The target service can determine a version verification identifier based on the hash values ​​of each node in the path corresponding to the target authentication rule. When the version verification identifier is equal to the first rule version identifier, it is determined that the target authentication rule and the first rule version identifier belong to the same authentication rule set, meaning the information included in the authentication request has not been tampered with; when the version verification identifier and the first rule version identifier are not equal, it is determined that the target authentication rule and the first rule version identifier belong to different authentication rule sets, meaning the information included in the authentication request may have been tampered with.

[0164] Specifically, the authentication rule set is a Merkle tree. The target service can calculate the Merkle root corresponding to the Merkle path based on the hash values ​​of each node included in the received Merkle path. If the Merkle root corresponding to the Merkle path is equal to the Merkle root corresponding to the first rule version identifier, it means that the authentication request was transmitted correctly. If the Merkle root corresponding to the Merkle path is not equal to the Merkle root corresponding to the first rule version identifier, it means that the authentication request was transmitted incorrectly.

[0165] Based on the above scheme, the authentication information is replaced by a rule version identifier of the authentication rule set. Since the rule version identifier is obtained by continuously hashing the authentication information, the accuracy of the authentication request can be verified by verifying the version verification identifier. This avoids the problem in related technologies that require communication with the authentication management terminal to verify the authentication certificate.

[0166] Based on the above verification process, the target service can determine the authentication result: if both the version verification result and the rule verification result are passed, and the target authentication rule and the first rule version identifier belong to the same authentication rule set, the authentication is determined to be passed; if either the version verification result or the rule verification result is failed, or if the target authentication rule and the first rule version identifier belong to different authentication rule sets, the authentication is determined to be failed.

[0167] Step 1003: Send the authentication result to the caller so that when the received authentication result indicates that the authentication is successful, the caller can invoke the target service based on the service invocation request triggered for the target service.

[0168] The target service can send the authentication result determined in step 1002 to the caller. When the authentication result indicates that the authentication is successful, a connection can be established with the caller, and a connection cache can be formed within the connection. The target authentication rule is stored in the connection cache, so that subsequent communication within this connection does not require the above-mentioned inter-service authentication operation.

[0169] In some embodiments, since the target service receives invalid authentication rules issued by the authentication management terminal in real time during the connection establishment process, once it is determined that the target authentication rule stored in the connection cache is invalid, the connection can be disconnected, ensuring that the caller cannot use the target authentication rule to call the target service again when the target authentication rule is invalid.

[0170] It should be noted that the verification method for business messages during subsequent communication with the caller can be found in [reference needed]. Figure 3 The relevant descriptions in the method embodiments shown will not be repeated here.

[0171] Based on the above scheme, since the rule version identifier and invalid authentication rule issued by the authentication management terminal have been received before the target authentication rule and the first rule version identifier sent by the caller are received, service authentication can be achieved without communicating with the authentication management terminal. This reduces the number of communications between the target service and the authentication management terminal, thereby improving the security of authentication information and call information.

[0172] Based on the same inventive concept as the above-described method embodiments, this application also provides an authentication system, which includes multiple services, an authentication agent, and an authentication management terminal. See also Figure 11 This is a schematic diagram of the inter-service authentication process provided in an embodiment of this application. Figure 11 In this case, Service 1 is the caller and Service 2 is the target service. The following explanation uses a Merkle tree as an example to illustrate the authentication process between services:

[0173] The authentication management terminal may include an authentication database, which may store the latest version of the Merkle tree built based on the obtained authentication information, the historical version number of the currently valid Merkle tree, and a list of invalid rules. The list of invalid rules may include the hash value of the leaf node corresponding to the invalid authentication rule.

[0174] Each time the Merkle tree, the historical version number of the currently valid Merkle tree, or one or more items from the invalid rule list are updated, the authentication management terminal can send the Merkle tree update information to the corresponding authentication agent. The authentication agent can then forward the received Merkle tree update information to the relevant service. The update information may include the version number of the latest version of the Merkle tree, the Merkle root of the latest version of the Merkle tree, the historical version number of the currently valid Merkle tree, and the invalid rule list.

[0175] Since a service may act as both a caller and a target service, both Service 1 and Service 2 can store the update information upon receiving it. Furthermore, each service can construct a Sign(root) signature for the first rule version identifier based on the pre-stored authentication management key information and the caller's own service identifier, thereby obtaining its own associated Merkle path.

[0176] After receiving a service call request, Service 1 can send an authentication request to Service 2. The authentication request includes the version number of the latest version of the Merkle tree stored in Service 1, the Merkle root of the latest version of the Merkle tree, and the Merkle path corresponding to Service 2.

[0177] Upon receiving the authentication request, Service 2 can verify the version number, Merkle root, and Merkle path, and return the authentication result to Service 1. For specific verification methods, please refer to [link to documentation]. Figure 10 The relevant descriptions in the method embodiments shown will not be repeated here.

[0178] When Service 1 receives an authentication result indicating that authentication has passed, it can then invoke Service 2 based on the service invocation request.

[0179] Based on the same inventive concept as the above-described method embodiments, this application also provides an inter-service authentication device applied to the calling party. For example... Figure 12 The service authentication device 1200 shown may include:

[0180] The rule determination unit 1201 is used to determine the target authentication rule for calling the target service from at least one reference authentication rule in response to a service call request triggered for the target service; the at least one reference authentication rule is the authentication rule associated with the caller obtained from the authentication rule set after the caller obtains the corresponding authentication rule set based on the pre-stored first rule version identifier.

[0181] The communication unit 1202 is used to send the target authentication rule and the first rule version identifier to the target service, so that the target service returns the authentication result after verifying the first rule version identifier and the target authentication rule;

[0182] The service invocation unit 1203 is used to invoke the target service based on the service invocation request when the received authentication result indicates that the authentication is successful.

[0183] In one possible implementation, at least one reference authentication rule is obtained by the communication unit in the following way: taking the latest received rule version identifier as the first rule version identifier; adding corresponding signature information to the first rule version identifier based on the service identifier of the caller; and obtaining at least one reference authentication rule associated with the caller from the authentication rule set corresponding to the first rule version identifier based on the signature information.

[0184] In one possible implementation, the authentication rule set is obtained through the following method: acquiring multiple authentication information; each authentication information includes the call conditions between two services and the key information of each service; using the multiple authentication information as leaf nodes, and pairing the obtained leaf nodes in pairs to obtain at least one node pair; repeating the following operations until the root node is obtained to obtain a rule tree: based on the currently obtained at least one node pair, creating corresponding parent nodes respectively; when the newly created parent nodes are not root nodes, pairing the newly created parent nodes in pairs to obtain at least one new node pair; using the rule tree as the authentication rule set; wherein each authentication rule included in the authentication rule set is a path from the corresponding leaf node to the root node, and the rule version identifier of the authentication rule set is determined based on the root node in the rule tree.

[0185] In one possible implementation, based on at least one currently obtained node pair, corresponding parent nodes are created, including: for at least one currently obtained node pair, the following operations are performed respectively: when a node in a node pair is a leaf node, the authentication information corresponding to each node is hashed to determine the hash value of each node; when a node in a node pair is a non-leaf node, the hash value stored in each node is obtained; the hash values ​​of each node in a node pair are combined, and the combined hash value is hashed to determine the hash value of the parent node; based on the hash value of the parent node, a parent node of the node pair is created; the parent node is used to store the hash value of the parent node.

[0186] In one possible implementation, the invocation conditions include one or more of the following: services corresponding to the caller and the target service in multiple services; one or more interfaces in the target service that the caller is allowed to invoke; different functions of the target service corresponding to different interfaces; and time intervals during which the caller is allowed to invoke the target service.

[0187] This application also provides an inter-service authentication device applied to a target service. For example... Figure 13 The service authentication device 1300 shown may include:

[0188] The communication unit 1301 is used to receive the target authentication rule and the first rule version identifier sent by the caller; the target authentication rule is the authentication rule used by the caller when calling the target service; the first rule version identifier is used to identify the version of the authentication rule set used by the caller.

[0189] The authentication unit 1302 is used to determine the authentication result based on the version verification result of the first rule version identifier and the rule verification result of the target authentication rule;

[0190] The communication unit 1301 is also used to send the authentication result to the caller, so that when the received authentication result indicates that the authentication is successful, the caller can call the target service based on the service call request triggered for the target service.

[0191] In one possible implementation, the authentication unit 1302 determines the authentication result based on the version verification result of the first rule version identifier and the rule verification result of the target authentication rule. Specifically, it is used to: verify the first rule version identifier based on at least one pre-stored second rule version identifier to obtain a version verification result; the second rule version identifier is the version identifier of a valid set of authentication rules; verify the target authentication rule based on at least one pre-stored invalid authentication rule to obtain a rule verification result; and determine the authentication result based on the version verification result and the rule verification result.

[0192] In one possible implementation, at least one second rule version identifier is determined according to the following method: a communication unit 1301 is used to receive update information of the rule version identifier; the update information includes the latest version rule version identifier and the currently valid historical rule version identifier; an authentication unit 1302 is used to store the latest version rule version identifier and the currently valid historical rule version identifier as the second rule version identifier.

[0193] In one possible implementation, the authentication unit 1302 verifies the first rule version identifier based on at least one pre-stored second rule version identifier to obtain a version verification result. Specifically, it is used to: determine that the version verification is successful when there is a version identifier in at least one second rule version identifier that is the same as the first rule version identifier; and determine that the version verification is unsuccessful when there is no version identifier in at least one second rule version identifier that is the same as the first rule version identifier.

[0194] In one possible implementation, the authentication unit 1302 verifies the target authentication rule based on at least one pre-stored invalid authentication rule to obtain a rule verification result. Specifically, it is used to: determine that the rule verification is successful when the target authentication rule is not included in at least one invalid authentication rule; and determine that the rule verification is unsuccessful when the target authentication rule is included in at least one invalid authentication rule.

[0195] In one possible implementation, the authentication rule set is a rule tree; the target authentication rule is a path from a leaf node to the root node in the rule tree; before determining the authentication result based on the version verification result and the rule verification result, the authentication unit 1302 is also used to: determine the version verification identifier based on the hash value of each node in the path corresponding to the target authentication rule; when the version verification identifier is equal to the first rule version identifier, determine that the target authentication rule and the first rule version identifier belong to the same authentication rule set; when the version verification identifier is not equal to the first rule version identifier, determine that the target authentication rule and the first rule version identifier belong to different authentication rule sets.

[0196] In one possible implementation, the authentication unit 1302 determines the authentication result based on the version verification result and the rule verification result. Specifically, it is used to: determine that the authentication is successful when both the version verification result and the rule verification result are successful and the target authentication rule and the first rule version identifier belong to the same authentication rule set; and determine that the authentication is unsuccessful when either the version verification result or the rule verification result is unsuccessful, or when the target authentication rule and the first rule version identifier belong to different authentication rule sets.

[0197] For ease of description, the above sections are divided into modules (or units) according to their functions and described separately. In the embodiments of this application, the terms "module" or "unit" refer to a computer program or part of a computer program with a predetermined function, which works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functions of that module or unit.

[0198] Having introduced the inter-service authentication method and apparatus according to exemplary embodiments of this application, we will now introduce a computer device according to another exemplary embodiment of this application.

[0199] Those skilled in the art will understand that various aspects of this application can be implemented as a system, method, or program product. Therefore, various aspects of this application can be specifically implemented in the following forms: a completely hardware implementation, a completely software implementation (including firmware, microcode, etc.), or a combination of hardware and software implementations, collectively referred to herein as a "circuit," "module," or "system."

[0200] Based on the same inventive concept as the above-described method embodiments, this application also provides a computer device 1400. In one embodiment, the computer device may be a server, such as... Figure 2 The server 220 is shown. In this embodiment, the computer device is structured as follows: Figure 14 As shown, it may include at least a memory 1401, a communication module 1403, and at least one processor 1402.

[0201] The memory 1401 is used to store computer programs executed by the processor 1402. The memory 1401 may mainly include a program storage area and a data storage area. The program storage area may store the operating system and programs required to run instant messaging functions, etc.; the data storage area may store various instant messaging information and operation instruction sets, etc.

[0202] Memory 1401 may be volatile memory, such as random-access memory (RAM); memory 1401 may also be non-volatile memory, such as read-only memory, flash memory, hard disk drive (HDD), or solid-state drive (SSD); or memory 1401 may be any other medium capable of carrying or storing a desired computer program having the form of instructions or data structures and accessible by a computer, but is not limited thereto. Memory 1401 may be a combination of the above-described memories.

[0203] Processor 1402 may include one or more central processing units (CPUs) or digital processing units, etc. Processor 1402 is used to implement the above-described inter-service authentication method when calling computer programs stored in memory 1401.

[0204] The communication module 1403 is used to communicate with terminal devices and other servers.

[0205] This application embodiment does not limit the specific connection medium between the memory 1401, communication module 1403, and processor 1402. This application embodiment... Figure 14 The memory 1401 and the processor 1402 are connected via a bus 1404, and the bus 1404 is in Figure 14 The diagram uses thick lines to describe the connections between other components; these are for illustrative purposes only and should not be considered limiting. The 1404 bus can be divided into address bus, data bus, control bus, etc. For ease of description, Figure 14 It is described using only a thick line, but does not indicate that there is only one bus or one type of bus.

[0206] The memory 1401 stores a computer storage medium, which stores computer-executable instructions for implementing the inter-service authentication method of this application embodiment. The processor 1402 is used to execute the above-described inter-service authentication method, such as... Figure 3 As shown.

[0207] In another embodiment, the computer device can also be other computer devices, such as... Figure 2 The terminal device 210 is shown. In this embodiment, the structure of the computer device can be as follows: Figure 15 As shown, it includes components such as: communication component 1510, memory 1520, display unit 1530, camera 1540, sensor 1550, audio circuit 1560, Bluetooth module 1570, processor 1580, etc.

[0208] The communication component 1510 is used to communicate with the server. In some embodiments, it may include a Wireless Fidelity (WiFi) module, which is a short-range wireless transmission technology, and the electronic device can send and receive information through the WiFi module.

[0209] The memory 1520 can be used to store software programs and data. The processor 1580 executes various functions of the terminal device 210 and performs data processing by running the software programs or data stored in the memory 1520. The memory 1520 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device. The memory 1520 stores an operating system that enables the terminal device 210 to run. In this application, the memory 1520 may store the operating system and various application programs, and may also store a computer program that executes the inter-service authentication method of the embodiments of this application.

[0210] The display unit 1530 can also be used to display information input by an object or information provided to an object, as well as a graphical user interface (GUI) for various menus of the terminal device 210. Specifically, the display unit 1530 may include a display screen 1532 disposed on the front of the terminal device 210. The display screen 1532 may be configured as a liquid crystal display, a light-emitting diode, or the like.

[0211] The display unit 1530 can also be used to receive input digital or character information and generate signal inputs related to object settings and function control of the terminal device 210. Specifically, the display unit 1530 may include a touch screen 1531 disposed on the front of the terminal device 210, which can collect touch operations on or near the object, such as clicking a button, dragging a scroll bar, etc.

[0212] The touchscreen 1531 can be placed on top of the display screen 1532, or the touchscreen 1531 and the display screen 1532 can be integrated to realize the input and output functions of the terminal device 210. After integration, it can be referred to as a touch display screen. In this application, the display unit 1530 can display the application and the corresponding operation steps.

[0213] Camera 1540 can be used to capture still images, and objects can publish images captured by camera 1540 through an application. There can be one or multiple cameras 1540. An optical image of an object is generated through a lens and projected onto a photosensitive element. The photosensitive element can be a charge-coupled device (CCD) or a complementary metal-oxide-semiconductor (CMOS) phototransistor. The photosensitive element converts the light signal into an electrical signal, which is then transmitted to processor 1580 to be converted into a digital image signal.

[0214] The terminal device may also include at least one sensor 1550, such as an accelerometer 1551, a proximity sensor 1552, a fingerprint sensor 1553, and a temperature sensor 1554. The terminal device may also be equipped with other sensors such as a gyroscope, barometer, hygrometer, thermometer, infrared sensor, light sensor, and motion sensor.

[0215] Audio circuitry 1560, speaker 1561, and microphone 1562 provide an audio interface between the device and terminal device 210. Audio circuitry 1560 converts received audio data into electrical signals, which are then transmitted to speaker 1561, where they are converted into sound signals for output. Terminal device 210 may also be equipped with volume buttons for adjusting the volume of the sound signal. Conversely, microphone 1562 converts collected sound signals into electrical signals, which are then received by audio circuitry 1560, converted back into audio data, and output to communication component 1510 for transmission to, for example, another terminal device 210, or to memory 1520 for further processing.

[0216] The Bluetooth module 1570 is used to interact with other Bluetooth devices that also have a Bluetooth module via the Bluetooth protocol. For example, a terminal device can establish a Bluetooth connection with a wearable electronic device (such as a smartwatch) that also has a Bluetooth module through the Bluetooth module 1570, thereby exchanging data.

[0217] The processor 1580 is the control center of the terminal device, connecting various parts of the terminal through various interfaces and lines. It executes various functions and processes data by running or executing software programs stored in the memory 1520 and calling data stored in the memory 1520. In some embodiments, the processor 1580 may include one or more processing units; the processor 1580 may also integrate an application processor and a baseband processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the baseband processor mainly handles wireless communication. It is understood that the baseband processor may not be integrated into the processor 1580. In this application, the processor 1580 can run the operating system, applications, user interface display and touch response, and the inter-service authentication method of this application embodiment. Furthermore, the processor 1580 is coupled to the display unit 1530.

[0218] Furthermore, it should be noted that in the specific implementation of this application, object data related to inter-service authentication is involved. When the above embodiments of this application are applied to specific products or technologies, permission or consent from the object is required, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0219] In some possible implementations, various aspects of the inter-service authentication method provided in this application can also be implemented as a program product, which includes a computer program. When the program product is run on a computer device, the computer program causes the computer device to perform the steps of the inter-service authentication method according to the various exemplary embodiments of this application described above. For example, the computer device can perform actions such as... Figure 3 orFigure 10 The steps are shown in the figure.

[0220] The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (a non-exhaustive list) of readable storage media include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0221] The program product of the embodiments of this application may employ a portable compact disc read-only memory (CD-ROM) and include a computer program, and may run on an electronic device. However, the program product of this application is not limited thereto. In this document, the readable storage medium may be any tangible medium that contains or stores a program that may be used by or in conjunction with a command execution system, apparatus, or device.

[0222] A readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying a readable computer program. This propagated data signal may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting a program for use by or in conjunction with a command execution system, apparatus, or device.

[0223] Computer programs contained on readable media may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0224] Computer programs for performing the operations of this application can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The computer program can execute entirely on the user's computer device, partially on the user's computer device, as a standalone software package, partially on the user's computer device and partially on a remote computer device, or entirely on a remote computer device. In cases involving remote computer devices, the remote computer device can be connected to the user's computer device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computer device (e.g., via the Internet using an Internet service provider).

[0225] It should be noted that although several units or sub-units of the device have been mentioned in the detailed description above, this division is merely exemplary and not mandatory. In fact, according to embodiments of this application, the features and functions of two or more units described above can be embodied in one unit. Conversely, the features and functions of one unit described above can be further divided and embodied by multiple units.

[0226] Furthermore, although the operations of the method of this application are described in a specific order in the accompanying drawings, this does not require or imply that these operations must be performed in that specific order, or that all the operations shown must be performed to achieve the desired result. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0227] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing a computer-usable computer program.

[0228] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, produce a machine for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0229] These computer program commands may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the commands stored in the computer-readable storage medium produce an article of manufacture including command means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0230] These computer program commands can also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing the commands executed on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0231] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0232] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. An inter-service authentication method, characterized by, The application is applied to a plurality of services, including: In response to a service call request triggered for a target service, determining a target authentication rule for calling the target service in at least one reference authentication rule; the at least one reference authentication rule is an authentication rule associated with the calling party obtained from the authentication rule set by the calling party based on a pre-stored first rule version identifier. The target authentication rule and the first rule version identifier are sent to the target service, so that the target service returns an authentication result after verifying the first rule version identifier and the target authentication rule; When the received authentication result represents that the authentication is passed, the target service is called based on the service call request.

2. The method of claim 1, wherein, The at least one reference authentication rule is obtained by: The latest received rule version identifier is used as the first rule version identifier; Based on the service identifier of the calling party, add corresponding signature information to the first rule version identifier; Based on the signature information, at least one reference authentication rule associated with the calling party is obtained from the authentication rule set corresponding to the first rule version identifier.

3. The method according to claim 1 or 2, characterized in that, The authentication rule set is obtained by the following method: Obtain a plurality of authentication information; each authentication information includes the calling condition between two services and the key information of the two services respectively; The plurality of authentication information is used as a leaf node, and the plurality of leaf nodes obtained are paired two by two to obtain at least one node pair; Repeat the following operation until the root node is obtained: based on the at least one node pair obtained at present, create corresponding parent nodes respectively; when the newly created parent nodes are not root nodes, pair the newly created parent nodes two by two to obtain new at least one node pair; The rule tree is used as the authentication rule set; wherein each authentication rule included in the authentication rule set is the path from the corresponding leaf node to the root node, and the rule version identifier of the authentication rule set is determined based on the root node in the rule tree.

4. The method of claim 3, wherein, The method comprises the following steps: For the at least one node pair obtained at present, the following operations are performed respectively: When the nodes in a node pair are leaf nodes, the authentication information corresponding to each node pair is respectively hashed to determine the hash value of each node; When the nodes in the one node pair are non-leaf nodes, the hash value stored in each node is obtained; The hash values of each node in the one node pair are combined, and the combined hash value is hashed to determine the parent node hash value; Based on the parent node hash value, create the parent node of the one node pair; the parent node is used to store the parent node hash value.

5. The method of claim 3, wherein, The calling condition includes one or more of the following: The calling party and the target service in the plurality of services correspond to the service respectively; One or more interfaces in the target service that allow the calling party to call; different interfaces correspond to different functions of the target service; A time interval during which the invoker is allowed to invoke the target service.

6. An inter-service authentication method, characterized by, The method is applied to a target service in a plurality of services, and includes: receiving a target authentication rule and a first rule version identifier sent by an invoker; the target authentication rule is an authentication rule used by the invoker when invoking the target service; and the first rule version identifier is used to identify a version of a set of authentication rules used by the invoker; determining an authentication result based on a version verification result of the first rule version identifier and a rule verification result of the target authentication rule; sending the authentication result to the invoker, so that the invoker invokes the target service based on a service invocation request triggered for the target service when the received authentication result indicates that the authentication is passed.

7. The method of claim 6, wherein, The determining of the authentication result based on the version verification result of the first rule version identifier and the rule verification result of the target authentication rule includes: verifying the first rule version identifier based on at least one pre-stored second rule version identifier, to obtain the version verification result; the second rule version identifier is a version identifier of a valid set of authentication rules; verifying the target authentication rule based on at least one pre-stored invalid authentication rule, to obtain the rule verification result; determining the authentication result based on the version verification result and the rule verification result.

8. The method of claim 7, wherein, The at least one second rule version identifier is determined according to the following method: receiving update information of a rule version identifier; the update information includes a latest version of a rule version identifier and a currently valid historical rule version identifier; storing the latest version of the rule version identifier and the currently valid historical rule version identifier as a second rule version identifier.

9. The method of claim 7, wherein, The verifying of the first rule version identifier based on the at least one pre-stored second rule version identifier to obtain the version verification result includes: when there is a same version identifier as the first rule version identifier in the at least one second rule version identifier, determining that the version verification is passed; when there is no same version identifier as the first rule version identifier in the at least one second rule version identifier, determining that the version verification is not passed.

10. The method of claim 7, wherein, The verifying of the target authentication rule based on the at least one pre-stored invalid authentication rule to obtain the rule verification result includes: when the target authentication rule is not included in the at least one invalid authentication rule, determining that the rule verification is passed; when the target authentication rule is included in the at least one invalid authentication rule, determining that the rule verification is not passed.

11. The method according to any one of claims 7-10, characterized in that, The set of authentication rules is a rule tree; and the target authentication rule is a path from a leaf node to a root node in the rule tree. Before the determining of the authentication result based on the version verification result and the rule verification result, the method further includes: determining a version verification identifier based on a hash value of each node in a path corresponding to the target authentication rule; when the version verification identifier is equal to the first rule version identifier, determining that the target authentication rule and the first rule version identifier belong to a same set of authentication rules; and When the version check identifier is not equal to the first rule version identifier, it is determined that the target authentication rule and the first rule version identifier belong to different authentication rule sets.

12. The method of claim 11, wherein, The authentication result is determined based on the version verification result and the rule verification result, including: When the version verification result and the rule verification result are both passed, and the target authentication rule and the first rule version identifier belong to the same authentication rule set, it is determined that the authentication is passed. When either the version verification result or the rule verification result is not passed, or when the target authentication rule and the first rule version identifier belong to different authentication rule sets, it is determined that the authentication is not passed.

13. An inter-service authentication apparatus, characterized by comprising: The application is applied to a plurality of services, including: A rule determination unit is configured to determine a target authentication rule for calling a target service in at least one reference authentication rule in response to a service call request triggered for the target service; the at least one reference authentication rule is an authentication rule associated with the calling party obtained from a corresponding authentication rule set based on a pre-stored first rule version identifier by the calling party; A communication unit is configured to send the target authentication rule and the first rule version identifier to the target service, so that the target service returns an authentication result after verifying the first rule version identifier and the target authentication rule; A service call unit is configured to call the target service based on the service call request when the received authentication result indicates that the authentication is passed.

14. An inter-service authentication apparatus, characterized by comprising: The application is applied to a plurality of services, including: A communication unit is configured to receive a target authentication rule and a first rule version identifier sent by a calling party; the target authentication rule is an authentication rule used by the calling party when calling the target service; the first rule version identifier is used to identify the version of an authentication rule set used by the calling party; An authentication unit is configured to determine an authentication result based on a version verification result of the first rule version identifier and a rule verification result of the target authentication rule; The communication unit is further configured to send the authentication result to the calling party, so that the calling party calls the target service based on a service call request triggered for the target service when the received authentication result indicates that the authentication is passed.

15. A computer device, comprising: It includes a processor and a memory, wherein the memory stores program code, and when the program code is executed by the processor, the processor executes the steps of the method of any one of claims 1-5 or the steps of the method of any one of claims 6-12.

Images