Authentication and authorization method, device and equipment for API caller in API framework interconnection

Abstract

The invention provides an authentication and authorization method, device and equipment for an API caller in API framework interconnection, applied to a second network entity, and comprising: receiving a request message sent by the API caller, the API caller having been loaded to the second network entity; sending an authorization request message to the first network entity; receiving an authorization response message sent by the first network entity; and sending the authorization response message to the API caller. By means of the method, the risk of a centralized authorization server and the conflict of the ID of the API caller are avoided, a distributed authorization process with multiple network entities cooperating is defined, and meanwhile authorization and access of the API caller to the AEF service API in a cross-domain scene are supported.

Description

Technical Field

[0001] The present application relates to the field of network security technology, and in particular to a method, device and equipment for authenticating and authorizing API callers in API framework interconnection. Background Art

[0002] In the process of 5G commercialization, in order to meet the needs of industry customers, operators integrate different capabilities in multiple capability domains such as internal network capabilities, cloud capabilities, and IT capabilities, and cooperate with other capability providers to provide industry customers with richer capabilities. Industry customers can sign contracts on the original registered capability platform and access the capabilities of other capability platforms. This measure simplifies the process of industry customers using the capabilities provided by different companies, expands the industry customer base of each company, and has high economic benefits.

[0003] 3GPP (3rd Generation Partnership Project) has conducted research and standardization on cross-domain open scenarios of operator capabilities. For example, the logical analysis specification stage 2 of technical specification TS23.222 defines the CAPIF (Common API Framework for 3GPP Northbound APIs) interconnection model, which supports the interconnection of network entities with logical functions of different CAPIFs, thereby supporting the API (Application Programming Interface) caller to access the capabilities managed by other network entities through one network entity. However, there is currently no solution in the relevant technology for how API callers can access the open functions released by other network entities through one network entity. Summary of the invention

[0004] The present application proposes an authentication and authorization method, device and equipment for API callers in API framework interconnection, defines a distributed authorization process for collaboration of multiple network entities, and improves the existing process to support collaboration of multiple network entities for authorization issues in CAPIF interconnection.

[0005] In a first aspect, an embodiment of the present application proposes an authentication and authorization method for an API caller in an API framework interconnection, which is applied to a second network entity, including:

[0006] receiving a request message sent by the API caller, where the API caller has been loaded into the second network entity;

[0007] Sending an authorization request message to the first network entity;

[0008] Receiving an authorization response message sent by the first network entity;

[0009] Send the authorization response message to the API caller.

[0010] In some possible embodiments, the request message sent by the API caller is used to request authorization of the AEF service API published by the first network entity.

[0011] In some possible embodiments, the request message sent by the API caller includes at least one of the following:

[0012] API caller ID, identity information of the first network entity, and requested AEF service API information.

[0013] In some possible embodiments, the authorization request message is used to request the AEF service API published by the first network entity to authorize the API caller.

[0014] In some possible embodiments, after receiving the request message sent by the API caller, the method is applied to the second network entity and further includes:

[0015] The request message is forwarded to the first network entity as an authorization request message.

[0016] In some possible embodiments, the authorization request message sent by the second network entity includes at least one of the following:

[0017] The identity information of the second network entity, the API caller ID, and the requested AEF service API information.

[0018] In some possible embodiments, the authorization response message is used to indicate the authorization information of the AEF service API published by the first network entity that the API caller is allowed to access.

[0019] In some possible embodiments, after receiving the authorization response message sent by the first network entity, the method further includes:

[0020] The security information in the configuration file of the API caller is updated according to the authorization information in the authorization response message.

[0021] In some possible embodiments, the method further includes providing the API caller with identity information of the second network entity.

[0022] In some possible embodiments, the providing the identity information of the second network entity to the API caller is performed in at least one of the following ways:

[0023] In the process of loading the API caller, assigning an API caller ID to indicate that the API caller is loaded by the second network entity;

[0024] In the process where the API caller sends a request message to the second network entity to request authorization of the AEF service API issued by the first network entity interconnected with the second network entity, providing the identity information of the second network entity to the API caller;

[0025] During the loading process of the API caller, when the API caller provides AEF service API information published by a first network entity interconnected with a second network entity, identity information of the second network entity is provided to the API caller.

[0026] In some possible embodiments, the API caller ID may be used as a unique identifier in cross-domain access of the API caller, and the API caller ID also indicates that the API caller is maintained by the second network entity.

[0027] In some possible embodiments, after executing the loading program of the API caller, the method further includes:

[0028] When the first network entity has a subscription to the API caller, a first notification message is sent to the first network entity, where the first notification message is used to notify the first network entity that the API caller has been loaded into the second network entity.

[0029] In some possible embodiments, the first notification message includes any one of the following messages:

[0030] The event notification message includes at least one of the following: identity information of the second network entity, an API caller ID, and a loaded status of the API caller;

[0031] The loading notification message includes at least one of the following: identity information of the second network entity and an API caller ID.

[0032] In some possible embodiments, the method further includes:

[0033] receiving a security information request message sent by the first network entity, wherein the security information request message includes at least one of the following: an API caller ID and identity information of the first network entity;

[0034] Send a security information response message to the first network entity, where the security information response message carries the security information of the API caller.

[0035] In some possible embodiments, the security information is used for authentication and authorization between the API caller and the AEF.

[0036] In some possible embodiments, when the authentication method between the API caller and the AEF is certificate-based two-way authentication, the security information further includes the root CA certificate of the API caller.

[0037] In some possible embodiments, the method further includes:

[0038] When the API caller loaded on the second network entity triggers an uninstall process, sending a second notification message to the first network entity, where the second notification message is used to notify the first network entity that the API caller has expired;

[0039] A notification confirmation message is received from the first network entity, where the notification confirmation message is used to indicate that the security information about the API caller in the first network entity has been successfully deleted.

[0040] In some possible embodiments, the second notification message includes any one of the following messages:

[0041] The event notification message includes at least one of the following: identity information of the second network entity, an API caller ID, and an uninstalled state of the API caller;

[0042] The uninstall notification message includes at least one of the following: identity information of the second network entity and an API caller ID.

[0043] In a second aspect, the present application also proposes an authentication and authorization method for an API caller in an API framework interconnection, which is applied to a first network entity, including:

[0044] receiving an authorization request message sent by the second network entity;

[0045] Authorizing the API caller;

[0046] Send an authorization response message to the second network entity.

[0047] In some possible embodiments, the authorization request message is used to request the AEF service API published by the first network entity to authorize the API caller.

[0048] In some possible embodiments, the first network entity is interconnected with the second network entity.

[0049] In some possible embodiments, the authorization request message sent by the second network entity includes at least one of the following:

[0050] The identity information of the second network entity, API caller ID, and requested AEF service API information.

[0051] In some possible embodiments, the authorization response message includes authorization information for indicating that the API caller is allowed to access the AEF service API published by the first network entity.

[0052] In some possible embodiments, the method further includes:

[0053] When the first network entity has a subscription to the API caller, a first notification message sent by the second network entity is received, where the first notification message is used to notify the first network entity that the API caller has been loaded into the second network entity.

[0054] In some possible embodiments, the first notification message includes any one of the following messages:

[0055] The event notification message includes at least one of the following: identity information of the second network entity, an API caller ID, and a loaded status of the API caller;

[0056] The loading notification message includes at least one of the following: identity information of the second network entity and an API caller ID.

[0057] In some possible embodiments, the method further includes:

[0058] receiving a request message sent by the AEF for requesting security information of the API caller, wherein the request message includes at least one of the following: an API caller ID and identity information of the second network entity;

[0059] Retrieving security information of the API caller based on the request message;

[0060] Send a security information response message to the AEF, where the security information response message carries the security information of the API caller.

[0061] In some possible embodiments, the method further includes:

[0062] When the security information of the API caller is not retrieved, sending a security information request message to the second network entity;

[0063] A security information response message sent by the second network entity is received, where the security information response message carries the security information of the API caller.

[0064] In some possible embodiments, the security information request message includes at least one of the following:

[0065] API caller ID, identity information of the first network entity.

[0066] In some possible embodiments, the security information is used for authentication and authorization between the API caller and the AEF.

[0067] In some possible embodiments, when the authentication method between the API caller and the AEF is certificate-based two-way authentication, the security information further includes the root CA certificate of the API caller.

[0068] In some possible embodiments, the method further includes:

[0069] receiving a second notification message sent by the second network entity, where the second notification message is used to notify the first network entity that the API caller has expired;

[0070] A notification confirmation message is sent to the second network entity, where the notification confirmation message is used to indicate that the security information about the API caller in the first network entity has been successfully deleted.

[0071] In some possible embodiments, the second notification message includes any one of the following messages:

[0072] The event notification message includes at least one of the following: identity information of the second network entity, an API caller ID, and an uninstalled state of the API caller;

[0073] The uninstall notification message includes at least one of the following: identity information of the second network entity and an API caller ID.

[0074] In a third aspect, an embodiment of the present application proposes an authentication and authorization device for an API caller in an API framework interconnection, including:

[0075] an authorization request receiving unit, configured to receive a request message sent by the API caller, the API caller having been loaded into the second network entity;

[0076] An authorization request sending unit, configured to send an authorization request message to the first network entity;

[0077] An authorization response receiving unit, configured to receive an authorization response message sent by the first network entity;

[0078] An authorization response sending unit is used to send the authorization response message to the API caller.

[0079] In a fourth aspect, an embodiment of the present application proposes an authentication and authorization device for an API caller in an API framework interconnection, including: a memory and a processor, wherein:

[0080] The memory is used to store programs executable by the processor;

[0081] The processor is used to read the program in the memory and execute the method applied to the second network entity in the authentication and authorization method for the API caller in the API framework interconnection in the first aspect above; or to read the program in the memory and execute the method applied to the first network entity in the authentication and authorization method for the API caller in the API framework interconnection in the second aspect above.

[0082] The present application proposes an authentication and authorization method, device and equipment for API callers in API framework interconnection, which is applied to the second network entity, including: receiving a request message sent by the API caller, the API caller has been loaded into the second network entity; sending an authorization request message to the first network entity; receiving an authorization response message sent by the first network entity; sending the authorization response message to the API caller. Among them, the request message is used to request the authorization of the AEF service API issued by the first network entity interconnected with the second network entity, the authorization request message is used to request the authorization of the AEF service API issued by the first network entity to the API caller, and the authorization response message includes authorization information of the AEF service API issued by the first network entity that indicates that the API caller is allowed to access. Through the authentication and authorization method, device and equipment for API callers in API framework interconnection provided by the present application, the risks of centralized authorization servers and conflicts of API caller IDs can be avoided, a distributed authorization process for multi-network entity collaboration can be defined, and cross-domain authorization and access of API callers to AEF service APIs can also be supported.

[0083] Other features and advantages of the present application will be described in the following description, and partly become apparent from the description, or be understood by practicing the present application. The purpose and other advantages of the present application can be realized and obtained by the structures specifically pointed out in the written description, claims, and drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0084] To further illustrate the technical solution provided by the embodiments of the present application, a detailed description is given below in conjunction with the accompanying drawings and specific implementation methods.

[0085] Figure 1 This is a schematic diagram of CAPIF interconnection in the same domain scenario in an embodiment of the present application;

[0086] Figure 2 This is a schematic diagram of CAPIF interconnection in a cross-domain scenario in an embodiment of the present application;

[0087] Figure 3This is an interaction flow chart of the CCF2 loading API caller in the embodiment of the present application;

[0088] Figure 4 This is an interactive flow chart of the API caller requesting authorization from CCF1 through CCF2 in the embodiment of the present application;

[0089] Figure 5 This is an interactive flow chart of an API caller requesting an AEF service API in an embodiment of the present application;

[0090] Figure 6 An interactive flow chart of an API caller requesting an AEF service API using an OAuth2.0 token authorization method that does not change the token version in an embodiment of the present application;

[0091] Figure 7 This is an interactive flow chart of an API caller requesting an AEF service API using an authorization method of an OAuth2.0 token with a changed token version in an embodiment of the present application;

[0092] Figure 8 This is an interactive flow chart of an API caller using a TLS-PKI method to request an AEF service API in an embodiment of the present application;

[0093] Fig. 9 This is an uninstallation flow chart triggered by the API caller in an embodiment of the present application;

[0094] Fig.10 This is a flow chart of an authentication and authorization method for an API caller in an API framework interconnection applied to a second network entity in an embodiment of the present application;

[0095] Fig.11 This is a flow chart of an authentication and authorization method for an API caller in an API framework interconnection applied to a first network entity in an embodiment of the present application;

[0096] Fig.12 A schematic diagram of an authentication and authorization device for an API caller in an API framework interconnection as a second network entity in an embodiment of the present application;

[0097] Fig.13 A schematic diagram of an authentication and authorization device for an API caller in an API framework interconnection as a first network entity in an embodiment of the present application;

[0098] Fig.14 This is a schematic diagram of an entity device for authenticating and authorizing an API caller in an API framework interconnection in an embodiment of the present application. DETAILED DESCRIPTION

[0099] The technical solutions in the embodiments of the present application will be described clearly and in detail below in conjunction with the accompanying drawings. It should be understood that these embodiments are provided only to enable those skilled in the art to better understand and implement the present invention, and are not intended to limit the scope of the present invention in any way. On the contrary, these embodiments are provided to make the present disclosure more thorough and complete, and to fully convey the scope of the present disclosure to those skilled in the art.

[0100] In view of the fact that no solution has been proposed in the current related technologies for how an API caller can access open functions published by other network entities through a network entity, the present application proposes an authentication and authorization method for API callers in API framework interconnection.

[0101] The existing CAPIF interconnection includes the following two scenarios:

[0102] Scenario 1: Two CCFs (CAPIF core functions) are located in the same CAPIF provider domain, such as Figure 1 As shown, the two CCFs exchange information through the CAPIF-6 reference point;

[0103] Scenario 2: Two CCFs are located in different CAPIF provider domains, such as Figure 2 As shown, the two CCFs exchange information through the CAPIF-6e reference point.

[0104] In view of the fact that there is no solution for how an API caller can access open functions published by other network entities through a network entity in the above two scenarios in the related art, the embodiment of the present application proposes an authentication and authorization system for API callers in API framework interconnection. In the above two scenarios, the system can realize the authentication and authorization of API callers that are not loaded into the first network entity, define a distributed authorization process for multiple network entities to collaborate, and avoid the risks of centralized authorization servers. The system includes a second network entity, a first network entity and an API caller, wherein:

[0105] The second network entity is configured to receive a request message sent by the API caller, the API caller having been loaded into the second network entity; send an authorization request message to the first network entity; receive an authorization response message sent by the first network entity; and send the authorization response message to the API caller;

[0106] The first network entity is configured to receive an authorization request message sent by a second network entity, the second network entity being interconnected with the first network entity; authorize the API caller; and send an authorization response message to the second network entity;

[0107] The API caller is used to send a request message to the second network entity; and receive an authorization response message sent by the second network entity.

[0108] Among them, the request message is used to request authorization of the AEF service API published by the first network entity, the authorization request message is used to request authorization of the AEF service API published by the first network entity to the API caller, and the authorization response message is used to indicate the authorization information of the AEF service API published by the first network entity that the API caller is allowed to access.

[0109] In an embodiment of the present application, the second network entity may be a CAPIF core function (ie, CCF), or an authorization function in the CAPIF core function, or an authorization service authorization server; the first network entity may also be a CAPIF core function, or an authorization function in the CAPIF core function, or an authorization serve.

[0110] For the scenario where the above two network entities are located in the same CAPIF provider domain, an authentication and authorization system for API callers in an API framework interconnection provided in an embodiment of the present application can load the API caller onto one of the network entities, and based on the identity information of the network entity possessed by the API caller, can indicate that the API caller has been loaded onto the network entity, and through the network entity that has loaded the API caller and based on the reference point generated by the interconnection of the two network entities, interact with another network entity in the same domain that has not loaded the API caller for authorization information, thereby enabling the network entity to authenticate and authorize API callers that are not loaded into itself in the same domain.

[0111] For the above two network entities located in different CAPIF provider domains, in the existing authentication and authorization process for API callers, the network entity is only responsible for authorizing requests to access services within the domain. API callers must be loaded into different network entities and use different API caller IDs to access services in different CAPIF domains, and the API caller ID does not specify the network entity information. The process is complicated for API callers, and multiple IDs and authorization information need to be maintained. Another solution is to rely on a centralized authorization server to authorize cross-domain access requests. This requires the authorization server to be highly trusted, but it is difficult to implement a highly trusted authorization server when the CAPIF domains belong to different companies. The authorization server is at risk of being attacked centrally and having a single point of failure. In addition, there is a risk of conflict for API caller IDs that do not specify network entity information.

[0112] For the scenario where the above-mentioned two network entities are located in different CAPIF provider domains, an authentication and authorization system for API callers in an API framework interconnection provided in an embodiment of the present application can assign an API caller ID to the API caller loaded into the network entity to indicate that the API caller is loaded by the second network entity, thereby solving the problem of focused attack risks that may be faced by centralized authorization in the prior art. There is no need to maintain multiple API caller IDs, thereby avoiding the risk of API caller ID conflicts.

[0113] In some possible embodiments, the API caller ID may be used as a unique identifier in cross-domain access of the API caller, and the API caller ID also indicates that the API caller is maintained by the second network entity.

[0114] Afterwards, through the network entity that has loaded the API caller and based on the reference point generated by the interconnection of the two network entities, authorization information is exchanged with another network entity in another domain that has not loaded the API caller, thereby enabling the network entity to authenticate and authorize API callers that are not loaded into itself in different domains.

[0115] In the embodiment of the present application, the above-mentioned second network entity, first network entity and API caller work closely together in the embodiment of the present application to build an authentication and authorization system for API callers in the API framework interconnection. The API caller is loaded into the second network entity, and based on the domain information provided by the second network entity and the message transmission between multiple network entities, multiple network entities are collaboratively authenticated and authorized.

[0116] In some possible embodiments, the identity information of the second network entity may also be an API caller ID, and the second network entity provides the identity information of the second network entity to the API caller in any of the following ways:

[0117] Method 1: During the process of loading the API caller, an API caller ID is assigned to indicate that the API caller is loaded by the second network entity. The API caller ID can be used as a unique identifier in the cross-domain access of the API caller. The API caller ID also indicates that the API caller is maintained by the second network entity.

[0118] The loading process of the API caller is as follows: the API caller sends a loading request message to the second network entity. After receiving the loading request, the second network entity allocates an API caller ID and loads the API caller configuration file; the second network entity sends a loading response message to the API caller, and the loading response message carries the API caller ID.

[0119] Mode 2: The second network entity provides the identity information of the second network entity to the API caller;

[0120] In implementation, the second network entity provides the identity information of the second network entity to the API caller, including at least one of the following situations:

[0121] Case 1: during the loading process of the API caller, when the API caller provides the AEF service API information published by the first network entity interconnected with the second network entity, the identity information of the second network entity is provided to the API caller;

[0122] Specifically, when the API caller provides the AEF service API information published by the first network entity in the loading request message, the second network entity provides the identity information of the second network entity to the API caller in the loading response message.

[0123] Case 2: In the process where the API caller sends a request message to the second network entity to request authorization of the AEF service API issued by the first network entity interconnected with the second network entity, the identity information of the second network entity is provided to the API caller.

[0124] In some possible embodiments, after the second network entity executes the loading program of the API caller, it is also used to: when the first network entity has a subscription to the API caller, send a first notification message to the first network entity, the first notification message is used to notify the first network entity that the API caller has been loaded into the second network entity. When the first network entity has a subscription to the API caller, the first network entity receives the first notification message sent by the second network entity, the first notification message is used to notify the first network entity that the API caller has been loaded into the second network entity. It is not a mandatory step for the second network entity to send the first notification message to the first network entity. Specifically, the first notification message can be conditionally sent to the first network entity based on the subscription of the first network entity. The first notification message includes any of the following messages: an event notification message including at least one of the following: identity information of the second network entity, API caller ID, and loaded status of the API caller; a loading notification message including at least one of the following: identity information of the second network entity and API caller ID.

[0125] The following assumes that the first network entity is CCF1, the second network entity is CCF2, and the identity information of the second network entity is the ID of CCF2, and provides the interaction flow of the CCF2 loading API caller, such as Figure 3 As shown, it mainly includes the following steps:

[0126] Step 1: The API caller establishes a TLS secure connection with CCF2;

[0127] Step 2, the API caller sends a load request message to CC2;

[0128] Step 3, CCF2 receives the loading request message sent by the API caller, executes the loading program of the API caller, generates the configuration file of the API caller and allocates the API caller ID;

[0129] Step 4: After CCF2 completes loading of the API caller, it sends a loading response message to the API caller, where the loading response message includes the API caller ID;

[0130] Optionally, the loading response message also includes the ID of CCF2.

[0131] Step 5: When CCF1 has a subscription to the API caller, CCF2 sends a first notification message to CCF1. The content of the first notification message refers to the above description.

[0132] Based on the above API caller loading process, the API caller sends a request message to the second network entity. In the embodiment of the present application, the request message sent by the API caller includes at least one of the following: API caller ID, identity information of the first network entity, and requested AEF service API information. After receiving the request message sent by the API caller, the second network entity sends an authorization request message to the first network entity. The authorization request message sent by the second network entity includes at least one of the following: identity information of the second network entity, API caller ID, and requested AEF service API information.

[0133] In some possible embodiments, the first network entity is interconnected with the second network entity, the authorization request message is used to request the AEF service API published by the first network entity to authorize the API caller, and the first network entity and the AEF service API published by the first network entity belong to the same domain.

[0134] In some possible embodiments, after receiving the request message sent by the API caller, the second network entity forwards the request message as an authorization request message to the first network entity.

[0135] After receiving the authorization request message sent by the second network entity, the first network entity authorizes the API caller and sends an authorization response message to the second network entity, wherein the authorization response message includes authorization information indicating that the API caller is allowed to access the AEF service API published by the first network entity. After receiving the authorization response message sent by the first network entity, the second network entity sends the authorization response message to the API caller.

[0136] The above authorization request message may be, but is not limited to, an access token. When the API caller requests an access token from the second network entity to request access to the AEF service API published by the first network entity, the second network entity may respond to the API caller's access token and the AEF's root CA certificate in addition to the identity information of the second network entity.

[0137] In some possible embodiments, after receiving the authorization response message sent by the first network entity, the second network entity is further configured to: update security information in the configuration file of the API caller according to the authorization information in the authorization response message.

[0138] By updating the security information in the configuration file of the API caller, it is ensured that when a security information request message requesting the security information of the API caller is received later, a response can be made according to the security information in the updated configuration file.

[0139] The following assumes that the first network entity is CCF1 and the second network entity is CCF2, and provides an interactive process in which the API caller requests authorization from CCF1 through CCF2. Figure 4 As shown, it mainly includes the following steps:

[0140] Step 1, the API caller sends a request message to the CCF2;

[0141] Step 2, the CCF2 receives the request message and sends an authorization request message to CCF1;

[0142] Optionally, when the request message sent by the API caller includes the requested AEF service API information, the authorization request message sent by the CCF2 also includes the requested AEF service API information.

[0143] Step 3, the CCF1 receives the authorization request message sent by the second network entity, authorizes the API caller, and sends an authorization response message to the CCF2, wherein the authorization response message includes authorization information indicating that the API caller is allowed to access the AEF service API published by the CCF1;

[0144] Step 4: The CCF2 receives the authorization response message sent by the CCF1, and sends the authorization response message to the API caller.

[0145] In the embodiment of the present application, the authorization information in the authorization response message may be, but is not limited to, an OAuth2.0 token.

[0146] In some possible embodiments, if the authorization request message in step 1 and step 2 does not include the requested AEF service API information, the "scope" in the OAuth2.0 token is the AEF service API published by the first network entity to the second network entity and allowed to be accessed by the API caller; if the authorization request message in step 1 and step 2 includes the requested AEF service API information, the "scope" in the OAuth2.0 token is the requested AEF service API, and the "scope" format may be "AEF: Service API 1; Service API 2".

[0147] After the API caller has obtained authorization from the first network entity that publishes the AEF service API, the API caller is further used to send a request service message to the AEF published by the first network entity, where the request service message is used to request the AEF service API published by the first network entity, and the request service message includes at least one of the following: API caller ID, identity information of the second network entity, and requested AEF service API information.

[0148] In some possible embodiments, the AEF retrieves security information based on the API caller ID, and when no security information related to the API caller is detected, sends a request message for requesting the security information of the API caller to the first network entity shown, and the request message includes at least one of the following: the API caller ID, and the identity information of the second network entity.

[0149] The first network entity receives the request message sent by the AEF, retrieves the security information of the API caller based on the request message, and sends a security information response message to the AEF, where the security information response message carries the security information of the API caller.

[0150] In some possible embodiments, the first network entity retrieves security information based on the API caller ID in the request message and / or the identity information of the second network entity. When the first network entity also fails to retrieve the security information of the API caller, the first network entity sends a security information request message to the second network entity.

[0151] In some possible embodiments, the security information request message sent by the first network entity includes at least one of the following: an API caller ID and identity information of the first network entity.

[0152] The second network entity receives the security information request message sent by the first network entity, and based on the security information in the API caller profile updated after receiving the authorization response message, sends a security information response message to the first network entity, wherein the security information response message carries the security information of the API caller.

[0153] The first network entity receives the security information response message sent by the second network entity, and forwards the security information response message to the AEF service API, where the security information response message carries the security information of the API caller.

[0154] In the embodiment of the present application, the above security information is used for authentication and authorization between the API caller and the AEF.

[0155] In some possible embodiments, the method for accessing AEF services includes but is not limited to the TLS with OAuth method, and can also be the TLS-PKI method. The authentication method includes but is not limited to TLS server-side authentication or TLS server and client two-way authentication. The authorization method includes but is not limited to the OAuth2.0 token without changing the token version, and can also be the OAuth2.0 token with changed token version.

[0156] When the authorization method is to change the OAuth2.0 token version, the value of "client_id" in the OAuth2.0 token of the authorization response message in the above steps 3 and 4 is the ID of the second network entity and the API caller ID.

[0157] In some possible embodiments, when the authentication method between the API caller and the AEF is certificate-based two-way authentication, the security information further includes the root CA certificate of the API caller.

[0158] The following is a flow of interaction of an API caller requesting an AEF service API, assuming that the first network entity is CCF1, the second network entity is CCF2, and the identity information of the second network entity is the ID of CCF2. Figure 5 As shown, it mainly includes the following steps:

[0159] Step 1, the API caller sends a service request message to the AEF published by CCF1, where the service request message is used to request the AEF service API published by CCF1;

[0160] In the embodiment of the present application, the service request message includes at least one of the following: API caller ID, CCF2 ID, and requested AEF service API.

[0161] Step 2, the AEF performs security information retrieval based on the API caller ID. When no security information related to the API caller is detected, the AEF sends a request message for requesting the security information of the API caller to CCF1;

[0162] In an embodiment of the present application, the request message includes at least one of the following: API caller ID, CCF2 ID.

[0163] Step 3, CCF1 receives the request message sent by AEF, retrieves the security information of the API caller based on the request message, and sends a security information request message to CCF2 when the security information of the API caller is not retrieved;

[0164] In an embodiment of the present application, the security information request message includes at least one of the following: API caller ID, CCF1 ID.

[0165] Step 4: Based on the security information in the configuration file, CCF2 sends the security information response message sent by CCF1, and the security information response message carries the security information of the API caller;

[0166] Step 5, CCF1 receives the security information response message sent by CCF2, and sends the security information response message to the AEF;

[0167] Step 6: AEF authenticates the API caller based on the security information, and the authentication follows the original process.

[0168] Based on the above interaction flow of the API caller requesting the AEF service API, the authorization method can be an OAuth2.0 token that does not change the token version. The following is a flow in which the API caller uses the OAuth2.0 token authorization method that does not change the token version to request the AEF service API, assuming that the first network entity is CCF1, the second network entity is CCF2, and the identity information of the second network entity is the ID of CCF2. Figure 6 As shown, it mainly includes the following steps:

[0169] Step 1, the API caller sends a request message to the CCF2;

[0170] Step 2, the CCF2 receives the request message and sends an authorization request message to CCF1;

[0171] Optionally, if the request message sent by the API caller in step 1 includes the requested AEF service API information, the authorization request message sent by CCF2 also includes the requested AEF service API information.

[0172] Step 3, the CCF1 receives the authorization request message sent by the second network entity, authorizes the API caller, and sends an authorization response message to the CCF2, where the authorization response message includes the ID and token of the CCF1;

[0173] Optionally, if the authorization request message in step 2 does not include the requested AEF service API information, the "scope" in the token is the service published by CCF1 to CCF2 and allowed to be accessed by the API caller; if the authorization request message in step 2 includes the requested AEF service API information, the "scope" in the token is the requested AEF service API, and the "scope" format can be "AEF: Service 1; Service 2".

[0174] Step 4, the CCF2 receives the authorization response message sent by the CCF1, and updates the security information in the configuration file of the API caller according to the "scope" in the token;

[0175] The security information in the configuration file should be able to explain which services of which AEFs the API caller is allowed to access.

[0176] Step 5: The CCF2 sends the authorization response message to the API caller.

[0177] Optionally, the above authorization response message may also include the ID of CCF2 and the root CA certificate of AEF, and the certificate may be provided by CCF1 to CCF2 via the CAPIF-6 / 6e reference point in the AEF service API publishing process.

[0178] Step 6: The API caller sends a service request message to the AEF published by CCF1. The service request message is used to request the AEF service API published by CCF1. The service request message includes authorization information and API caller ID.

[0179] If the API caller ID cannot indicate that it is the API caller loaded by CCF2, the service request message should also include the ID of CCF2. The API caller can obtain the ID of CCF2 from the API provider domain, or obtain the ID of CCF2 from CCF2 during the loading process.

[0180] Step 7, the AEF performs security information retrieval based on the API caller ID. When no security information related to the API caller is detected, the AEF sends a request message for requesting the security information of the API caller to CCF1;

[0181] In an embodiment of the present application, the request message includes at least one of the following: API caller ID, CCF2 ID.

[0182] Optionally, when the service request message includes the ID of CCF2, the security information request message also includes the ID of CCF2.

[0183] Step 8, CCF1 receives the request message sent by AEF, retrieves the security information of the API caller based on the request message, and sends a security information request message to CCF2 when the security information of the API caller is not retrieved;

[0184] In an embodiment of the present application, the security information request message includes at least one of the following: API caller ID, CCF ID.

[0185] Step 9: Based on the security information in the configuration file, CCF2 sends a security information response message to CCF1, where the security information response message carries the security information of the API caller;

[0186] The above security information indicates that the API caller uses the TLS with OAuth method to access the AEF service API, the authentication method is TLS server-side authentication or TLS server and client two-way authentication, and the authorization method is the OAuth2.0 token without changing the token version.

[0187] Optionally, when the TLS server and client are mutually authenticated, the security information also includes the root CA certificate of the API caller.

[0188] Step 10, CCF receives the security information response message sent by CCF2, and forwards the security information response message to the AEF;

[0189] Step 11, based on the security information, the API caller verifies the AEF according to the root CA certificate of the AEF, and the AEF authenticates the API caller according to the authorization information obtained from the CCF1, and the authentication follows the original process.

[0190] Optionally, when the TLS server and client are mutually authenticated, AEF verifies the API caller based on the API caller's root CA certificate, and the API caller verifies AEF based on the AEF's root CA certificate. After the mutual authentication is completed, AEF authenticates the API caller based on the authorization information obtained from CCF1, and the authentication follows the original process.

[0191] Based on the above interaction flow of the API caller requesting the AEF service API, the authorization method can also be an OAuth2.0 token with a changed token version. The following assumes that the first network entity is CCF1, the second network entity is CCF2, and the identity information of the second network entity is the ID of CCF2. The interaction flow of the API caller requesting the AEF service API using the authorization method of the OAuth2.0 token with a changed token version is given, such as Figure 7 As shown, it mainly includes the following steps:

[0192] Step 1, the API caller sends a request message to the CCF2;

[0193] Step 2, the CCF2 receives the request message and sends an authorization request message to CCF1;

[0194] Optionally, if the request message sent by the API caller in step 1 includes the requested AEF service API information, the authorization request message sent by CCF2 also includes the requested AEF service API information.

[0195] Step 3, the CCF1 receives the authorization request message sent by the second network entity, authorizes the API caller, and sends an authorization response message to the CCF2, the authorization response message includes the ID and token of CCF1, and the value of "client_id" of the token is the ID of CCF2 and the API caller ID;

[0196] Optionally, if the authorization request message in step 2 does not include the requested AEF service API information, the "scope" in the token is the service published by CCF1 to CCF2 and allowed to be accessed by the API caller; if the authorization request message in step 2 includes the requested AEF service API information, the "scope" in the token is the requested AEF service API, and the "scope" format can be "AEF: Service 1; Service 2".

[0197] Step 4, the CCF2 receives the authorization response message sent by the CCF1, and updates the security information in the configuration file of the API caller according to the "scope" in the token;

[0198] The security information in the configuration file should be able to explain which services of which AEFs the API caller is allowed to access.

[0199] Step 5: The CCF2 sends the authorization response message to the API caller.

[0200] Optionally, the above authorization response message may also include the root CA certificate of the AEF, and the certificate may be provided by CCF1 to CCF2 via the CAPIF-6 / 6e reference point in the AEF service API publishing process.

[0201] Step 6: The API caller sends a service request message to the AEF published by CCF1, where the service request message is used to request the AEF service API published by CCF1, and the service request message includes authorization information;

[0202] Step 7, the AEF retrieves security information based on the API caller ID. When no security information related to the API caller is detected, the AEF service API sends a request message for requesting the API caller security information to CCF1, and the request message includes the API caller ID and the ID of CCF2.

[0203] The above API caller ID and CCF2 ID are obtained by CCF1 from the value of "client_id" of the token in the authorization information.

[0204] Step 8, CCF1 receives the request message sent by AEF, retrieves the security information of the API caller based on the request message, and sends a security information request message to CCF2 when the security information of the API caller is not retrieved;

[0205] In an embodiment of the present application, the security information request message includes at least one of the following: API caller ID, CCF ID.

[0206] Step 9: Based on the security information in the configuration file, CCF2 sends a security information response message to CCF1, where the security information response message carries the security information of the API caller;

[0207] The above security information indicates that the API caller uses the TLS with OAuth method to access the AEF service API, the authentication method is TLS server-side authentication or TLS server and client two-way authentication, and the authorization method is an OAuth2.0 token with a changed token version.

[0208] Optionally, when the TLS server and client are mutually authenticated, the security information also includes the root CA certificate of the API caller.

[0209] Step 10, CCF receives the security information response message sent by CCF2, and forwards the security information response message to the AEF;

[0210] Step 11, based on the security information, the API caller verifies the AEF according to the root CA certificate of the AEF, and the AEF authenticates the API caller according to the authorization information obtained from the CCF1, and the authentication follows the original process.

[0211] Optionally, when the TLS server and client are mutually authenticated, AEF verifies the API caller based on the API caller's root CA certificate, and the API caller verifies AEF based on the AEF's root CA certificate. After the mutual authentication is completed, AEF authenticates the API caller based on the authorization information obtained from CCF1, and the authentication follows the original process.

[0212] Based on the above interaction process of the API caller requesting the AEF service API, the method for accessing the AEF service can also be a TLS-PKI method. The following is an interaction process of the API caller using the TLS-PKI method to request the AEF service API, assuming that the first network entity is CCF1, the second network entity is CCF2, and the identity information of the second network entity is the ID of CCF2. Figure 8 As shown, it mainly includes the following steps:

[0213] Step 1, the API caller sends a service request message to the AEF published by CCF1, the service request message is used to request the AEF service API published by CCF1, and the service request message includes authorization information and API caller ID;

[0214] If the API caller ID cannot indicate that it is the API caller loaded by CCF2, the service request message should also include the ID of CCF2. The API caller may obtain the ID of CCF2 from the API provider domain, or obtain the ID of CCF2 from CCF2 during the loading process.

[0215] Step 2, the AEF performs security information retrieval based on the API caller ID. When no security information related to the API caller is detected, the AEF sends a request message for requesting the security information of the API caller to CCF1;

[0216] In an embodiment of the present application, the request message includes at least one of the following: API caller ID, CCF2 ID.

[0217] Optionally, when the service request message includes the ID of CCF2, the security information request message also includes the ID of CCF2.

[0218] Step 3, CCF1 receives the request message sent by AEF, retrieves the security information of the API caller based on the request message, and sends a security information request message to CCF2 when the security information of the API caller is not retrieved;

[0219] In an embodiment of the present application, the security information request message includes at least one of the following: API caller ID, CCF1 ID.

[0220] Step 4: Based on the security information in the configuration file, CCF2 sends a security information response message to CCF1, where the security information response message carries the security information of the API caller;

[0221] The above security information indicates that the API caller uses the TLS-PKI method to access AEF, the authentication method is TLS server and client two-way authentication, and the authorization method is authorization based on authorization information. The security information includes the root CA certificate of the API caller.

[0222] Optionally, if in step 2, when the service request message includes the ID of CCF2, and the security information request message also includes the ID of CCF2, CCF1 retrieves the security information related to the API caller based on the API caller ID and the ID of CCF2.

[0223] Step 5, CCF1 receives the security information response message sent by CCF2, and forwards the security information response message to the AEF;

[0224] Step 6: Based on the security information, AEF verifies the API caller according to the API caller's root CA certificate, and the API caller verifies AEF according to AEF's root CA certificate. After the two-way authentication is completed, AEF authenticates the API caller according to the authorization information obtained from CCF1, and the authentication follows the original process.

[0225] In an embodiment of the present application, when the API caller loaded on the second network entity triggers the uninstall process, the second network entity is also used to: send a second notification message to the first network entity, the second notification message is used to notify the first network entity that the API caller has expired; receive a notification confirmation message sent by the first network entity, the notification confirmation message is used to indicate that the security information about the API caller in the first network entity has been successfully deleted. The first network entity is also used to: receive a second notification message sent by the second network entity, the second notification message is used to notify the first network entity that the API caller has expired; send a notification confirmation message to the second network entity, the notification confirmation message is used to indicate that the security information about the API caller in the first network entity has been successfully deleted, thereby achieving the uninstallation of the API caller.

[0226] In some possible embodiments, the second notification message includes any one of the following messages:

[0227] The event notification message includes at least one of the following: identity information of the second network entity, an API caller ID, and an uninstalled state of the API caller;

[0228] The uninstall notification message includes at least one of the following: identity information of the second network entity and an API caller ID.

[0229] The following assumes that the first network entity is CCF1, the second network entity is CCF2, and the identity information of the second network entity is the ID of CCF2, and the uninstallation process of the API caller triggered when the API caller has been loaded into CCF2 is given, such as Fig. 9 As shown, including:

[0230] Step 1: The API caller triggers the uninstall process, and CCF2 executes the uninstall procedure. The specific triggering uninstall process is shown in steps 1 to 6 of chapter 6.8 of 3GPPTS 33.122, which will not be described in detail here.

[0231] Step 2a, CCF2 sends an uninstall notification message to the AEF published by CCF2 to notify the API caller that the API caller has been uninstalled. The uninstall notification message is used to notify the AEF service API to delete the security information of the API caller. The uninstall notification message includes the ID of CCF2 and the API caller ID.

[0232] In step 2b, the AEF issued by CCF2 deletes the security information related to the API caller, as shown in steps 8 to 10 of chapter 6.8 of 3GPP TS33.122.

[0233] Step 3: CCF2 notifies CCF1 that the API caller has been uninstalled.

[0234] Optionally, an event notification message is used, and the event notification message includes at least one of the following: an ID of CCF2, an API caller ID, and an uninstalled state of the API caller;

[0235] Optionally, an uninstall notification message is used, and the uninstall notification message includes at least one of the following: an ID of CCF2 and an API caller ID.

[0236] Step 4, CCF1 and the AEF issued by CCF1 and CCF2 and the AEF issued by CCF2 delete the security information related to the API caller in the same way;

[0237] Step 5: CCF1 sends a notification confirmation message, where the notification confirmation message is used to indicate that the security information about the API caller in CCF1 has been successfully deleted.

[0238] The above-mentioned deletion of security information related to the API caller, for example: when the authentication method is TLS server and client two-way authentication, deleting the root CA certificate of the API caller, and when the authorization method is OAuth2.0 token, deleting the access token related to the API caller, is not specifically explained in the embodiments of the present application.

[0239] An embodiment of the present application provides an authentication and authorization system for API callers in an API framework interconnection. In the system, the three roles of the second network entity, the first network entity and the API caller work closely together in the embodiment of the present application. The system mainly makes little change to the original business system by providing the API caller with the identity information of the second network entity and forwarding authorization request messages and security information between the network entities. The first network entity authenticates and authorizes API callers that are not loaded into itself, defines a distributed authorization process for multiple network entities to collaborate, and avoids the risks of a centralized authorization server.

[0240] Based on the same inventive concept, the present application embodiment proposes an authentication and authorization method for API callers in API framework interconnection, see Fig.10 , applied to a second network entity, comprising:

[0241] Step 1001, receiving a request message sent by the API caller, where the API caller has been loaded into the second network entity;

[0242] Step 1002: Send an authorization request message to the first network entity;

[0243] Step 1003: receiving an authorization response message sent by the first network entity;

[0244] Step 1004: Send the authorization response message to the API caller.

[0245] In some possible embodiments, the request message sent by the API caller is used to request authorization of the AEF service API published by the first network entity.

[0246] In some possible embodiments, after receiving the request message sent by the API caller, the method is applied to the second network entity and further includes:

[0247] The request message is forwarded to the first network entity as an authorization request message.

[0248] In some possible embodiments, the request message sent by the API caller includes at least one of the following:

[0249] API caller ID, identity information of the first network entity, and requested AEF service API information.

[0250] In some possible embodiments, the authorization request message is used to request the AEF service API published by the first network entity to authorize the API caller.

[0251] In some possible embodiments, the authorization request message sent by the second network entity includes at least one of the following:

[0252] The identity information of the second network entity, the API caller ID, and the requested AEF service API information.

[0253] In some possible embodiments, the authorization response message is used to indicate the authorization information of the AEF service API published by the first network entity that the API caller is allowed to access.

[0254] In some possible embodiments, after receiving the authorization response message sent by the first network entity, the method further includes:

[0255] The security information in the configuration file of the API caller is updated according to the authorization information in the authorization response message.

[0256] In some possible embodiments, the method further includes providing the API caller with identity information of the second network entity.

[0257] In some possible embodiments, the providing the identity information of the second network entity to the API caller is performed in at least one of the following ways:

[0258] In the process of loading the API caller, assigning an API caller ID to indicate that the API caller is loaded by the second network entity;

[0259] In the process where the API caller sends a request message to the second network entity to request authorization of the AEF service API issued by the first network entity interconnected with the second network entity, providing the identity information of the second network entity to the API caller;

[0260] During the loading process of the API caller, when the API caller provides AEF service API information published by a first network entity interconnected with a second network entity, identity information of the second network entity is provided to the API caller.

[0261] In some possible embodiments, the API caller ID may be used as a unique identifier in cross-domain access of the API caller, and the API caller ID also indicates that the API caller is maintained by the second network entity.

[0262] In some possible embodiments, after executing the loading program of the API caller, the method further includes:

[0263] When the first network entity has a subscription to the API caller, a first notification message is sent to the first network entity, where the first notification message is used to notify the first network entity that the API caller has been loaded into the second network entity.

[0264] In some possible embodiments, the first notification message includes any one of the following messages:

[0265] The event notification message includes at least one of the following: identity information of the second network entity, an API caller ID, and a loaded status of the API caller;

[0266] The loading notification message includes at least one of the following: identity information of the second network entity and an API caller ID.

[0267] In some possible embodiments, the method further includes:

[0268] receiving a security information request message sent by the first network entity, wherein the security information request message includes at least one of the following: an API caller ID and identity information of the first network entity;

[0269] Send a security information response message to the first network entity, where the security information response message carries the security information of the API caller.

[0270] In some possible embodiments, the security information is used for authentication and authorization between the API caller and the AEF.

[0271] In some possible embodiments, when the authentication method between the API caller and the AEF is certificate-based two-way authentication, the security information further includes the root CA certificate of the API caller.

[0272] In some possible embodiments, the method further includes:

[0273] When the API caller loaded on the second network entity triggers an uninstall process, sending a second notification message to the first network entity, where the second notification message is used to notify the first network entity that the API caller has expired;

[0274] A notification confirmation message is received from the first network entity, where the notification confirmation message is used to indicate that the security information about the API caller in the first network entity has been successfully deleted.

[0275] In some possible embodiments, the second notification message includes any one of the following messages:

[0276] The event notification message includes at least one of the following: identity information of the second network entity, an API caller ID, and an uninstalled state of the API caller;

[0277] The uninstall notification message includes at least one of the following: identity information of the second network entity and an API caller ID.

[0278] An embodiment of the present application proposes an authentication and authorization method for API callers in API framework interconnection, which is applied to the second network entity, avoiding the risks of a centralized authorization server and the conflict of API caller IDs, defining a distributed authorization process for collaboration among multiple network entities, and also supporting the authorization and access of API callers to AEF service APIs in cross-domain scenarios.

[0279] Based on the same inventive concept, the present application embodiment proposes an authentication and authorization method for API callers in API framework interconnection, see Fig.11 , applied to a first network entity, comprising:

[0280] Step 1101, receiving an authorization request message sent by a second network entity;

[0281] Step 1102, authorizing the API caller;

[0282] Step 1103: Send an authorization response message to the second network entity.

[0283] In some possible embodiments, the authorization request message is used to request the AEF service API published by the first network entity to authorize the API caller.

[0284] In some possible embodiments, the first network entity is interconnected with the second network entity.

[0285] In some possible embodiments, the authorization request message sent by the second network entity includes at least one of the following:

[0286] The identity information of the second network entity, API caller ID, and requested AEF service API information.

[0287] In some possible embodiments, the authorization response message includes authorization information for indicating that the API caller is allowed to access the AEF service API published by the first network entity.

[0288] In some possible embodiments, the method further includes:

[0289] When the first network entity has a subscription to the API caller, a first notification message sent by the second network entity is received, where the first notification message is used to notify the first network entity that the API caller has been loaded into the second network entity.

[0290] In some possible embodiments, the first notification message includes any one of the following messages:

[0291] The event notification message includes at least one of the following: identity information of the second network entity, an API caller ID, and a loaded status of the API caller;

[0292] The loading notification message includes at least one of the following: identity information of the second network entity and an API caller ID.

[0293] In some possible embodiments, the method further includes:

[0294] receiving a request message sent by the AEF for requesting security information of the API caller, wherein the request message includes at least one of the following: an API caller ID and identity information of the second network entity;

[0295] Retrieving security information of the API caller based on the request message;

[0296] Send a security information response message to the AEF, where the security information response message carries the security information of the API caller.

[0297] In some possible embodiments, the method further includes:

[0298] When the security information of the API caller is not retrieved, sending a security information request message to the second network entity;

[0299] A security information response message sent by the second network entity is received, where the security information response message carries the security information of the API caller.

[0300] In some possible embodiments, it is characterized in that the security information request message includes at least one of the following:

[0301] API caller ID, identity information of the first network entity.

[0302] In some possible embodiments, the security information is used for authentication and authorization between the API caller and the AEF.

[0303] In some possible embodiments, when the authentication method between the API caller and the AEF is certificate-based two-way authentication, the security information further includes the root CA certificate of the API caller.

[0304] In some possible embodiments, the method further includes:

[0305] receiving a second notification message sent by the second network entity, where the second notification message is used to notify the first network entity that the API caller has expired;

[0306] A notification confirmation message is sent to the second network entity, where the notification confirmation message is used to indicate that the security information about the API caller in the first network entity has been successfully deleted.

[0307] In some possible embodiments, the second notification message includes any one of the following messages:

[0308] The event notification message includes at least one of the following: identity information of the second network entity, an API caller ID, and an uninstalled state of the API caller;

[0309] The uninstall notification message includes at least one of the following: identity information of the second network entity and an API caller ID.

[0310] The authentication and authorization method for API callers in the API framework interconnection proposed in the embodiment of the present application has little change to the original process, is compatible with the original authorization process and method, and the newly added process is not noticeable to the API caller and AEF, only the network entity process is changed, and is compatible with the single-domain authorization process and method. It solves the problem that the distributed authorization process in the prior art disperses the key attack risks that may be faced by centralized authorization, uses the network entity that publishes the AEF service API for authorization, and supports AEF to authenticate the API caller by forwarding the authorization request message, security information, and network entity identity information between multiple network entities.

[0311] Based on the same inventive concept, the embodiment of the present application proposes an authentication and authorization device for an API caller in an API framework interconnection, which serves as a second network entity, see Fig.12 ,include:

[0312] The authorization request receiving unit 1201 is used to receive a request message sent by the API caller, where the API caller has been loaded into the second network entity;

[0313] The authorization request sending unit 1202 is configured to send an authorization request message to the first network entity;

[0314] The authorization response receiving unit 1203 is used to receive the authorization response message sent by the first network entity;

[0315] The authorization response sending unit 1204 is used to send the authorization response message to the API caller.

[0316] Based on the same inventive concept, the embodiment of the present application proposes an authentication and authorization device for an API caller in an API framework interconnection, the device being a first network entity, such as Fig.13 As shown, including:

[0317] The authorization request processing unit 1301 receives an authorization request message sent by a second network entity interconnected with the first network entity;

[0318] Authorization unit 1302, authorizing the API caller;

[0319] The authorization response sending unit 1303 sends an authorization response message to the second network entity.

[0320] Based on the same inventive concept, the embodiment of the present application proposes an authentication and authorization entity device for API callers in API framework interconnection, such as Fig.14 As shown, it includes: a memory and a processor, wherein:

[0321] The memory is used to store programs executable by the processor;

[0322] The processor is used to read the program in the memory and execute the method applied to the second network entity in the authentication and authorization method for the API caller in the API framework interconnection as described in the above specification; or to read the program in the memory and execute the method applied to the first network entity in the authentication and authorization method for the API caller in the API framework interconnection as described in the above specification.

[0323] like Fig.14As shown, the authentication and authorization entity device 140 for the API caller in the API framework interconnection is presented in the form of an electronic device. The components of the authentication and authorization entity device 140 for the API caller in the API framework interconnection may include but are not limited to: the at least one processor 141, the at least one memory 142, and a bus 143 connecting different system components (including the memory 142 and the processor 141).

[0324] Bus 143 represents one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, a processor, or a local bus using any of a variety of bus architectures.

[0325] The memory 142 may include a readable medium in the form of a volatile memory, such as a random access memory (RAM) 1421 and / or a cache memory 1422 , and may further include a read-only memory (ROM) 1423 .

[0326] Memory 142 may also include a program / utility 1425 having a set (at least one) of program modules 1424, such program modules 1424 including but not limited to: an operating system, one or more application programs, other program modules, and program data, each of which or some combination may include an implementation of a network environment.

[0327] The authentication and authorization entity device 140 for the API caller in the API framework interconnection can also communicate with one or more external devices 144 (such as keyboards, pointing devices, etc.), and can also communicate with one or more devices that enable users to interact with the authentication and authorization entity device 140 for the API caller in the API framework interconnection, and / or communicate with any device (such as a router, a modem, etc.) that enables the authentication and authorization entity device 140 for the API caller in the API framework interconnection to communicate with one or more other electronic devices. Such communication can be carried out through an input / output (I / O) interface 145. In addition, the authentication and authorization entity device 140 for the API caller in the API framework interconnection can also communicate with one or more networks (such as a local area network (LAN), a wide area network (WAN) and / or a public network, such as the Internet) through a network adapter 146. As shown in the figure, the network adapter 146 communicates with other modules of the authentication and authorization entity device 140 for the API caller in the API framework interconnection through a bus 143. It should be understood that although not shown in the figure, other hardware and / or software modules can be used in conjunction with the authentication and authorization entity device 140 for the API caller in the API framework interconnection, including but not limited to: microcode, device drivers, redundant processors, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0328] In some possible implementations, various aspects of the authentication and authorization method for API callers in an API framework interconnection provided by the present application can also be implemented in the form of a program product, which includes program code. When the program product is run on a computer device, the program code is used to enable the computer device to execute the steps of the authentication and authorization method for API callers in an API framework interconnection according to various exemplary implementations of the present application described above in this specification.

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

[0330] The program product for monitoring of the embodiment of the present application can adopt a portable compact disk read-only memory (CD-ROM) and include program code, and can be run on an electronic device. However, the program product of the present application is not limited to this. In this document, a readable storage medium can be any tangible medium containing or storing a program, which can be used by an instruction execution system, an apparatus or a device or used in combination with it.

[0331] The readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, wherein the readable program code is carried. Such propagated data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. The readable signal medium may also be any readable medium other than a readable storage medium, which may send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0332] The program code embodied on the readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wired, optical cable, RF, etc., or any suitable combination of the foregoing.

[0333] Obviously, those skilled in the art can make various changes and modifications to the present application without departing from the spirit and scope of the present application. Thus, if these modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is also intended to include these modifications and variations.

Claims

1. A method for authenticating and authorizing an API caller in an API framework interconnection, applied to a second network entity, comprising: receiving a request message sent by the API caller, where the API caller has been loaded into the second network entity; Sending an authorization request message to the first network entity; Receiving an authorization response message sent by the first network entity; Send the authorization response message to the API caller.

2. The method according to claim 1, characterized in that The request message sent by the API caller is used to request authorization of the AEF service API issued by the first network entity.

3. The method according to claim 2, characterized in that The request message includes at least one of the following: API caller ID, identity information of the first network entity, and requested AEF service API information, where the AEF service API indicated by the requested AEF service API information is released by the first network entity.

4. The method according to claim 1, characterized in that The authorization request message is used to request the AEF service API issued by the first network entity to authorize the API caller.

5. The method according to claim 1, characterized in that After receiving the request message sent by the API caller, it also includes: The request message is forwarded to the first network entity as an authorization request message.

6. The method according to claim 1, characterized in that The authorization request message sent by the second network entity includes at least one of the following: The identity information of the second network entity, the API caller ID, and the requested AEF service API information.

7. The method according to claim 1, characterized in that The authorization response message is used to indicate the authorization information of the AEF service API published by the first network entity that the API caller is allowed to access.

8. The method according to claim 1, characterized in that After receiving the authorization response message sent by the first network entity, the method further includes: The security information in the configuration file of the API caller is updated according to the authorization information in the authorization response message.

9. The method according to claim 1, characterized in that: The method also includes providing the identity information of the second network entity to the API caller.

10. The method according to claim 9, wherein the providing the identity information of the second network entity to the API caller is performed in at least one of the following ways: In the process of loading the API caller, assigning an API caller ID to indicate that the API caller is loaded by the second network entity; In the process where the API caller sends a request message to the second network entity to request authorization of the AEF service API issued by the first network entity interconnected with the second network entity, providing the identity information of the second network entity to the API caller; During the loading process of the API caller, when the API caller provides AEF service API information published by a first network entity interconnected with a second network entity, identity information of the second network entity is provided to the API caller.

11. The method according to claim 10, characterized in that After executing the loader of the API caller, it also includes: When the first network entity has a subscription to the API caller, a first notification message is sent to the first network entity, where the first notification message is used to notify the first network entity that the API caller has been loaded into the second network entity.

12. The method according to claim 11, characterized in that The first notification message includes any one of the following messages: The event notification message includes at least one of the following: identity information of the second network entity, an API caller ID, and a loaded status of the API caller; The loading notification message includes at least one of the following: identity information of the second network entity and an API caller ID.

13. The method according to claim 1, characterized in that Also includes: receiving a security information request message sent by the first network entity, wherein the security information request message includes at least one of the following: an API caller ID and identity information of the first network entity; Send a security information response message to the first network entity, where the security information response message carries the security information of the API caller.

14. The method according to claim 13, characterized in that The security information is used for authentication and authorization between the API caller and the AEF.

15. The method according to claim 14, characterized in that When the authentication method between the API caller and the AEF is certificate-based two-way authentication, the security information further includes the root CA certificate of the API caller.

16. The method according to claim 1, characterized in that Also includes: When the API caller loaded on the second network entity triggers an uninstall process, sending a second notification message to the first network entity, where the second notification message is used to notify the first network entity that the API caller has expired; A notification confirmation message is received from the first network entity, where the notification confirmation message is used to indicate that the security information about the API caller in the first network entity has been successfully deleted.

17. The method according to claim 16, characterized in that The second notification message includes any one of the following messages: The event notification message includes at least one of the following: identity information of the second network entity, an API caller ID, and an uninstalled state of the API caller; The uninstall notification message includes at least one of the following: identity information of the second network entity and an API caller ID.

18. A method for authenticating and authorizing an API caller in an API framework interconnection, applied to a first network entity, comprising: receiving an authorization request message sent by the second network entity; Authorizing the API caller; Send an authorization response message to the second network entity.

19. The method according to claim 18, characterized in that The authorization request message is used to request the AEF service API issued by the first network entity to authorize the API caller.

20. The method according to claim 1, characterized in that The authorization request message sent by the second network entity includes at least one of the following: The identity information of the second network entity, the API caller ID, and the requested AEF service API information.

21. The method according to claim 18, characterized in that The authorization response message is used to indicate the authorization information of the AEF service API published by the first network entity that the API caller is allowed to access.

22. The method according to claim 18, characterized in that Also includes: When the first network entity has a subscription to the API caller, a first notification message sent by the second network entity is received, where the first notification message is used to notify the first network entity that the API caller has been loaded into the second network entity.

23. The method according to claim 22, characterized in that The first notification message includes any one of the following messages: The event notification message includes at least one of the following: identity information of the second network entity, an API caller ID, and a loaded status of the API caller; The loading notification message includes at least one of the following: identity information of the second network entity and an API caller ID.

24. The method according to claim 18, characterized in that Also includes: receiving a request message sent by the AEF for requesting security information of the API caller, wherein the request message includes at least one of the following: an API caller ID and identity information of the second network entity; Retrieving security information of the API caller based on the request message; Send a security information response message to the AEF, where the security information response message carries the security information of the API caller.

25. The method according to claim 24, characterized in that Also includes: When the security information of the API caller is not retrieved, sending a security information request message to the second network entity; A security information response message sent by the second network entity is received, where the security information response message carries the security information of the API caller.

26. The method according to any one of claims 24 or 25, characterized in that The security information request message includes at least one of the following: API caller ID, identity information of the first network entity.

27. The method according to any one of claims 24 to 26, characterized in that: The security information is used for authentication and authorization between the API caller and the AEF.

28. The method according to claim 27, characterized in that When the authentication method between the API caller and the AEF is certificate-based two-way authentication, the security information further includes the root CA certificate of the API caller.

29. The method according to claim 18, characterized in that Also includes: receiving a second notification message sent by the second network entity, where the second notification message is used to notify the first network entity that the API caller has expired; A notification confirmation message is sent to the second network entity, where the notification confirmation message is used to indicate that the security information about the API caller in the first network entity has been successfully deleted.

30. The method according to claim 29, characterized in that The second notification message includes any one of the following messages: The event notification message includes at least one of the following: identity information of the second network entity, an API caller ID, and an uninstalled state of the API caller; The uninstall notification message includes at least one of the following: identity information of the second network entity and an API caller ID.

31. An authentication and authorization device for API callers in API framework interconnection, characterized in that: include: an authorization request receiving unit, configured to receive a request message sent by the API caller, the API caller having been loaded into the second network entity; An authorization request sending unit, configured to send an authorization request message to the first network entity; An authorization response receiving unit, configured to receive an authorization response message sent by the first network entity; An authorization response sending unit is used to send the authorization response message to the API caller.

32. An authentication and authorization device for API callers in API framework interconnection, characterized in that: include: A memory and a processor, wherein: The memory is used to store programs executable by the processor; The processor is used to read the program in the memory and execute the authentication and authorization method for the API caller in the API framework interconnection as described in any one of claims 1-16; or to read the program in the memory and execute the authentication and authorization method for the API caller in the API framework interconnection as described in any one of claims 17-29.

Images