Authentication and authorization method, apparatus, and device for API invoker in API framework interconnection

Abstract

The present application provides an authentication and authorization method, apparatus, and device for an API invoker in an API framework interconnection. The method is applied to a second network entity and comprises: receiving a request message sent by an API invoker, wherein the API invoker has been loaded onto the second network entity; sending an authorization request message to a first network entity; receiving an authorization response message sent by the first network entity; and sending the authorization response message to the API invoker. Using the method prevents centralized authorization server risks and API invoker ID conflicts, defines a distributed authorization process involving collaboration among a plurality of network entities, while also supporting API invoker authorization and access to AEF service APIs in cross-domain scenarios.

Description

Method, device and equipment for authentication and authorization of API invoker in API framework interconnection

[0001] Cross-reference to related applications

[0002] The present application claims priority to the Chinese patent application No. 202411391220.1, filed on September 30, 2024, and entitled "Method, device and equipment for authentication and authorization of API invoker in API framework interconnection", the whole content of which is incorporated herein by reference. TECHNICAL FIELD

[0003] The present application relates to the field of network security, and in particular to a method, device and equipment for authentication and authorization of API invoker in API framework interconnection. BACKGROUND

[0004] In the process of 5G commercialization, in order to meet the needs of industry customers, operators integrate different capabilities of multiple capability domains such as internal network capabilities, cloud capabilities, IT capabilities, and jointly provide more rich capabilities with other capability providers for industry customers. Industry customers can sign up and access the capabilities of other capability platforms on the original registered capability platform. This initiative simplifies the process of using capabilities provided by different enterprises for industry customers, expands the industry customer groups of each enterprise, and has high economic benefits.

[0005] 3GPP (3rd Generation Partnership Project, Third Generation Partnership Project) has studied and standardized the cross-domain opening scenario of operator capabilities. For example, the logical analysis specification stage2 of technical specification TS23.222 defines a CAPIF (Common API Framework for 3GPP Northbound APIs, Common API Framework for 3GPP Northbound APIs) interconnection model, which supports interconnection of network entities with different logical functions of CAPIF, thereby supporting API (Application Programming Interface, Application Programming Interface) invokers to access the capabilities managed by other network entities through one network entity. However, there is no solution in the related art for how the API invoker accesses the open functions published by other network entities through one network entity. SUMMARY

[0006] The present application proposes a method, device and equipment for authentication and authorization of API invoker in API framework interconnection, defines a distributed authorization process with multiple network entity cooperation, and improves the existing process to support multiple network entity cooperation for authorization in view of the authorization problem of CAPIF interconnection.

[0007] In a first aspect, the application provides an authentication and authorization method for an API invoker in API framework interconnection, applied to a second network entity, comprising:

[0008] receiving a request message sent by the API invoker, the API invoker having been loaded to the second network entity;

[0009] sending an authorization request message to the first network entity;

[0010] receiving an authorization response message sent by the first network entity;

[0011] sending the authorization response message to the API invoker.

[0012] In a second aspect, the application also provides an authentication and authorization method for an API invoker in API framework interconnection, applied to a first network entity, comprising:

[0013] receiving an authorization request message sent by a second network entity;

[0014] authorizing the API invoker;

[0015] sending an authorization response message to the second network entity.

[0016] In a third aspect, the application provides an authentication and authorization device for an API invoker in API framework interconnection, comprising:

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

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

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

[0020] an authorization response sending unit, configured to send the authorization response message to the API invoker.

[0021] In a fourth aspect, the application provides an authentication and authorization device for an API invoker in API framework interconnection, comprising a memory and a processor, wherein:

[0022] the memory is configured to store a program executable by the processor;

[0023] The processor is configured to read a program in the memory and execute a method applied to the second network entity in the authentication and authorization method of the API invoker in the API framework interconnection as in the first aspect above; or read a program in the memory and execute a method applied to the first network entity in the authentication and authorization method of the API invoker in the API framework interconnection as in the second aspect above.

[0024] The API framework interconnection method for authenticating and authorizing an API invoker, the device and the equipment provided by the embodiments of the present application have the following beneficial effects:

[0025] The API framework interconnection method for authenticating and authorizing an API invoker, the device and the equipment provided by the embodiments of the present application can avoid the risk of centralized authorization servers and the conflict of API invoker IDs, define a distributed authorization process of multiple network entities, and support cross-domain authorization and access of API invokers to AEF service APIs.

[0026] Other features and advantages of the present application will be described in the following description, and some will become apparent from the description, or will be learned by practice of the present application. The purpose and other advantages of the present application can be achieved and obtained by the structure specifically pointed out in the written description, claims, and drawings. BRIEF DESCRIPTION OF DRAWINGS

[0027] In order to further illustrate the technical solutions provided by the embodiments of the present application, the following will be described in detail in combination with the drawings and specific embodiments.

[0028] FIG. 1 is a CAPIF interconnection schematic diagram in a same domain scenario according to an embodiment of the present application;

[0029] FIG. 2 is a CAPIF interconnection schematic diagram in a cross-domain scenario according to an embodiment of the present application;

[0030] FIG. 3 is an interaction flow diagram of loading an API invoker by CCF2 according to an embodiment of the present application;

[0031] FIG. 4 is an interaction flow diagram of an API invoker requesting authorization from CCF1 through CCF2 according to an embodiment of the present application;

[0032] FIG. 5 is an interaction flow diagram of an API invoker requesting an AEF service API according to an embodiment of the present application;

[0033] FIG. 6 is an interaction flow diagram of an API invoker requesting an AEF service API by using an OAuth2.0 token without changing the token version according to an embodiment of the present application;

[0034] FIG. 7 is an interaction flow diagram of a method for an API invoker to request an AEF service API using an OAuth2.0 token with a changed token version, according to an embodiment of the present application;

[0035] FIG. 8 is an interaction flow diagram of a method for an API invoker to request an AEF service API using a TLS-PKI method, according to an embodiment of the present application;

[0036] FIG. 9 is an offloading flow diagram triggered by an API invoker, according to an embodiment of the present application;

[0037] FIG. 10 is a flow diagram of a method for authenticating and authorizing an API invoker in an API framework interconnection applied to a second network entity, according to an embodiment of the present application;

[0038] FIG. 11 is a flow diagram of a method for authenticating and authorizing an API invoker in an API framework interconnection applied to a first network entity, according to an embodiment of the present application;

[0039] FIG. 12 is a schematic diagram of an apparatus for authenticating and authorizing an API invoker in an API framework interconnection applied to a second network entity, according to an embodiment of the present application;

[0040] FIG. 13 is a schematic diagram of an apparatus for authenticating and authorizing an API invoker in an API framework interconnection applied to a first network entity, according to an embodiment of the present application;

[0041] FIG. 14 is a schematic diagram of an entity device for authenticating and authorizing an API invoker in an API framework interconnection, according to an embodiment of the present application. DETAILED DESCRIPTION

[0042] The technical solutions in the embodiments of the present application will be described clearly and thoroughly below with reference to the drawings. It should be understood that these embodiments are presented only to enable those skilled in the art to better understand and implement the present application, and do not limit the scope of the present application 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.

[0043] In view of the fact that there is no solution to how an API invoker accesses open functions published by other network entities through a network entity in the prior art, the present application proposes a method for authenticating and authorizing an API invoker in an API framework interconnection.

[0044] In the existing CAPIF interconnection, the following two scenarios are included:

[0045] Scenario 1, two CCFs (CAPIF core functions) are located in the same CAPIF provider domain, as shown in FIG. 1, and information interaction is performed between the two CCFs through a CAPIF-6 reference point;

[0046] Scenario 2, two CCFs are located in different CAPIF provider domains, as shown in FIG. 2, and information interaction is performed between the two CCFs through a CAPIF-6e reference point.

[0047] In view of the fact that there is no solution for how an API invoker accesses an open function published by another network entity in the above two scenarios in the related art, an authentication and authorization system for API invokers in API framework interconnection is proposed in the embodiments of the present application. In the above two scenarios, the system can achieve authentication and authorization of a first network entity for an API invoker that is not loaded into the first network entity, and defines a distributed authorization process in which multiple network entities cooperate, while avoiding the risk of a centralized authorization server. The system includes a second network entity, a first network entity, and an API invoker, wherein:

[0048] The second network entity is configured to receive a request message sent by the API invoker, the API invoker being 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 invoker.

[0049] The first network entity is configured to receive an authorization request message sent by the second network entity, the second network entity being interconnected with the first network entity, authorize the API invoker, and send an authorization response message to the second network entity.

[0050] The API invoker is configured to send a request message to the second network entity and receive an authorization response message sent by the second network entity.

[0051] The request message is used to request authorization of an 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 for the API invoker, and the authorization response message is used to indicate authorization information of the AEF service API published by the first network entity that the API invoker is allowed to access.

[0052] In the embodiments of the present application, the second network entity can be a CAPIF core function (i.e., CCF), or an authorization function in the CAPIF core function, or an authorization server; and the first network entity can also be a CAPIF core function, or an authorization function in the CAPIF core function, or an authorization server.

[0053] For the scenario that the two network entities are located in the same CAPIF provider domain, the authentication and authorization system for API invokers in the API framework interconnection provided by the embodiments of the present application can load the API invoker to one of the network entities, indicate that the API invoker has been loaded to the network entity according to the identity information of the network entity possessed by the API invoker, interact with the other network entity in the same domain which does not load the API invoker based on the reference point generated by the interconnection of the two network entities, and achieve the authentication and authorization of the network entity to the API invoker which is not loaded to itself in the same domain.

[0054] For the scenario that the two network entities are located in different CAPIF provider domains, in the existing authentication and authorization process of the API invoker, the network entity is only responsible for authorizing the request for accessing the services in the domain, the API invoker must be loaded to different network entities, and different API invoker IDs must be used to access the services in different CAPIF domains, and the API invoker ID does not indicate the network entity information. For the API invoker, the process is complex, and multiple IDs and authorization information need to be maintained. Another solution is to rely on a centralized authorization server to authorize the cross-domain access request. This requires the authorization server to be highly trusted, but when the CAPIF domains belong to different companies, it is difficult to achieve a highly trusted authorization server, and the authorization server has the risk of being attacked and single point failure, and in addition, there is a conflict risk for the API invoker ID which does not indicate the network entity information.

[0055] For the scenario that the two network entities are located in different CAPIF provider domains, the authentication and authorization system for API invokers in the API framework interconnection provided in the embodiments of the present application can assign an API invoker ID to the API invoker loaded into the network entity, to indicate that the API invoker is loaded by the second network entity, solve the problem that the centralized authorization in the prior art may face the risk of key attack, and avoid the risk of API invoker ID conflict without the need to maintain multiple API invoker IDs.

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

[0057] Thereafter, the network entity on which the API invoker is loaded interacts with another network entity in another domain on which the API invoker is not loaded, to exchange authorization information, based on a reference point generated by interconnection of the two network entities, to achieve authentication and authorization of the API invoker not loaded into the network entity in different domains.

[0058] In the embodiments of the present application, the second network entity, the first network entity, and the API invoker cooperate closely to build an authentication and authorization system for API invokers in the API framework interconnection, the API invoker is loaded into the second network entity, and based on domain information provided by the second network entity and message transmission between multiple network entities, the multiple network entities cooperatively perform authentication and authorization.

[0059] In some possible embodiments, the identity information of the second network entity can also be an API invoker ID, and the second network entity provides the identity information of the second network entity for the API invoker, which can be in any of the following manners:

[0060] Manner 1. In the process of loading the API invoker, an API invoker ID is assigned to indicate that the API invoker is loaded by the second network entity, and the API invoker ID can be used as a unique identifier in cross-domain access of the API invoker, and the API invoker ID also indicates that the API invoker is maintained by the second network entity.

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

[0062] In a second possible implementation, the second network entity provides the identity information of the second network entity to the API invoker.

[0063] In some possible embodiments, the second network entity provides the identity information of the second network entity to the API invoker in at least one of the following manners:

[0064] In a first manner, the second network entity provides the identity information of the second network entity to the API invoker in a loading process of the API invoker.

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

[0066] In a second manner, the second network entity provides the identity information of the second network entity to the API invoker in an AEF service API authorization process.

[0067] In some possible embodiments, after the second network entity performs the loading procedure of the API invoker, the second network entity is further configured to: when the first network entity has a subscription to the API invoker, send a first notification message to the first network entity, the first notification message being used to notify the first network entity that the API invoker has been loaded to the second network entity. When the first network entity has a subscription to the API invoker, the first network entity receives the first notification message sent by the second network entity, the first notification message being used to notify the first network entity that the API invoker has been loaded to the second network entity. The second network entity sending the first notification message to the first network entity is not a mandatory step, and the second network entity can conditionally send the first notification message to the first network entity based on the subscription of the first network entity. The first notification message includes any one of the following messages: an event notification message including at least one of the following: the identity information of the second network entity, the API invoker ID, and the loaded state of the API invoker; and a loading notification message including at least one of the following: the identity information of the second network entity and the API invoker ID.

[0068] In the following, the first network entity is taken as CCF1, the second network entity is taken as CCF2, and the identity information of the second network entity is taken as the ID of CCF2. An interaction flow of the CCF2 loading the API invoker is shown in FIG. 3, and mainly includes the following steps:

[0069] Step 1, the API invoker establishes a TLS secure connection with the CCF2;

[0070] Step 2, the API invoker sends a load request message to the CCF2;

[0071] Step 3, the CCF2 receives the load request message sent by the API invoker, executes the loading procedure of the API invoker, generates a configuration file of the API invoker and allocates an API invoker ID;

[0072] Step 4, after the CCF2 completes the loading of the API invoker, the CCF2 sends a load response message to the API invoker, and the load response message includes the API invoker ID;

[0073] Optionally, the load response message also includes the ID of the CCF2.

[0074] Step 5, when the CCF1 has a subscription to the API invoker, the CCF2 sends a first notification message to the CCF1, and the content of the first notification message is described above.

[0075] Based on the above API invoker loading procedure, the API invoker sends a request message to the second network entity, and the request message sent by the API invoker in the embodiment of the application includes at least one of the following: an API invoker ID, identity information of the first network entity, and requested AEF service API information. After the second network entity receives the request message sent by the API invoker, 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, an API invoker ID, and requested AEF service API information.

[0076] In some possible embodiments, the first network entity and the second network entity are interconnected, the authorization request message is used to request authorization of the AEF service API published by the first network entity to the API invoker, and the first network entity and the AEF service API published by the first network entity belong to the same domain.

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

[0078] The first network entity receives the authorization request message sent by the second network entity, authorizes the API invoker, and sends an authorization response message to the second network entity, where the authorization response message includes authorization information indicating that the API invoker 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 invoker.

[0079] The authorization request message can be, but is not limited to, an access token. When the API invoker 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 can respond to the identity information of the second network entity in addition to the access token of the API invoker and the root CA certificate of the AEF.

[0080] 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 a configuration file of the API invoker according to the authorization information in the authorization response message.

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

[0082] The following takes the first network entity as CCF1 and the second network entity as CCF2, and gives an interaction process in which the API invoker requests authorization from CCF1 through CCF2, as shown in FIG. 4, mainly including the following steps.

[0083] Step 1: The API invoker sends a request message to the CCF2.

[0084] Step 2: The CCF2 receives the request message and sends an authorization request message to the CCF1.

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

[0086] Step 3: The CCF1 receives the authorization request message sent by the second network entity, authorizes the API invoker, and sends an authorization response message to the CCF2, where the authorization response message includes authorization information indicating that the API invoker is allowed to access the AEF service API published by the CCF1.

[0087] Step 4, the CCF2 receives the authorization response message sent by the CCF1, and sends the authorization response message to the API invoker.

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

[0089] In some possible embodiments, if the authorization request message in steps 1 and 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 invoker; if the authorization request message in steps 1 and 2 includes the requested AEF service API information, the "scope" in the OAuth2.0 token is the AEF service API requested, and the "scope" format can be "AEF: service API 1; service API 2".

[0090] When the API invoker has obtained the authorization of the first network entity publishing the AEF service API, the API invoker is also configured to send a request service message to the AEF published by the first network entity, the request service message being configured to request the AEF service API published by the first network entity, and the request service message including at least one of the following: the API invoker ID, the identity information of the second network entity, and the requested AEF service API information.

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

[0092] The first network entity receives the request message sent by the AEF, performs security information retrieval of the API invoker based on the request message, and sends a security information response message to the AEF, the security information response message carrying the security information of the API invoker.

[0093] In some possible embodiments, the first network entity performs security information retrieval based on the API invoker ID and / or the identity information of the second network entity in the request message, and when the first network entity also fails to retrieve the security information of the API invoker, the first network entity sends a security information request message to the second network entity.

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

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

[0096] 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, wherein the security information response message carries the security information of the API invoker.

[0097] In the embodiments of the present application, the security information is used for authentication and / or authorization between the API invoker and the AEF.

[0098] In some possible embodiments, the method for accessing the AEF service includes, but is not limited to, a TLS with OAuth method, and can also be a TLS-PKI method, the authentication method includes, but is not limited to, TLS server-side authentication or TLS server and client bidirectional authentication, and the authorization method includes, but is not limited to, an OAuth2.0 token without changing the token version, and can also be an OAuth2.0 token with changing the token version.

[0099] When the authorization method is an OAuth2.0 token with changing the token version, the value of "client_id" in the OAuth2.0 token in the authorization response message in steps 3 and 4 is the ID of the second network entity and the API invoker ID.

[0100] In some possible embodiments, when the authentication method between the API invoker and the AEF is a certificate-based bidirectional authentication, the security information further comprises a root CA certificate of the API invoker.

[0101] The following takes the first network entity as CCF1 and the second network entity as CCF2, and the identity information of the second network entity as the ID of the CCF2, and gives an interaction flow of the API invoker requesting an AEF service API, as shown in FIG. 5, which mainly includes the following steps:

[0102] Step 1: The API invoker sends a request service message to the AEF published by the CCF1, and the request service message is used to request the AEF service API published by the CCF1;

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

[0104] Step 2, the AEF performs security information retrieval based on the API caller ID, and when no API caller-related security information is detected, the AEF sends a request message for requesting the API caller security information to CCF1;

[0105] In the embodiment of the present application, the request message comprises at least one of the following: API caller ID and ID of CCF2.

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

[0107] In the embodiment of the present application, the security information request message comprises at least one of the following: API caller ID and ID of CCF1.

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

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

[0110] Step 6, the AEF performs API caller authentication based on the security information, and the authentication follows the original process.

[0111] Based on the above-mentioned interaction process of the API caller requesting the AEF service API, the authorization method can be the OAuth2.0 token without changing the token version. Hereinafter, taking CCF1 as the first network entity, CCF2 as the second network entity, and the identity information of the second network entity as the ID of CCF2, an interaction process of the API caller using the OAuth2.0 token without changing the token version to request the AEF service API is given, as shown in FIG. 6, mainly comprising the following steps:

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

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

[0114] Optionally, if the AEF service API information requested is included in the request message sent by the API invoker in step 1, the AEF service API information requested is also included in the authorization request message sent by the CCF2.

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

[0116] Optionally, if the AEF service API information requested is not included in the authorization request message in step 2, the "scope" in the token is the service published by the CCF1 to the CCF2 and allowed to be accessed by the API invoker; if the AEF service API information requested is included in the authorization request message in step 2, the "scope" in the token is the AEF service API requested, and the format of the "scope" can be "AEF: service 1; service 2".

[0117] 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 invoker according to the "scope" in the token;

[0118] The security information in the configuration file should be able to indicate which services of which AEFs the API invoker is allowed to access.

[0119] Step 5, the CCF2 sends the authorization response message to the API invoker.

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

[0121] Step 6, the API invoker sends a request service message to the AEF published by the CCF1, the request service message being used to request the AEF service API published by the CCF1, the request service message including the authorization information and the API invoker ID;

[0122] If the API invoker ID cannot indicate the API invoker loaded by the CCF2, the request service message should also include the ID of the CCF2, and the API invoker can obtain the ID of the CCF2 from the API provider domain or obtain the ID of the CCF2 from the CCF2 in the loading process.

[0123] Step 7, the AEF performs security information retrieval based on the API caller ID, and 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 the CCF1;

[0124] In the embodiments of the present application, the request message comprises at least one of the following: the API caller ID and the ID of the CCF2.

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

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

[0127] In the embodiments of the present application, the security information request message comprises at least one of the following: the API caller ID and the ID of the CCF.

[0128] Step 9, the CCF2 sends a security information response message to the CCF1 based on the security information in the configuration file, and the security information response message carries the security information of the API caller.

[0129] 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 mutual authentication, and the authorization method is OAuth2.0 token without changing token version.

[0130] Optionally, when it is TLS server and client mutual authentication, the above security information further comprises the root CA certificate of the API caller.

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

[0132] 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.

[0133] Optionally, when the TLS server and client are bidirectionally authenticated, the AEF authenticates the API invoker according to the root CA certificate of the API invoker, the API invoker authenticates the AEF according to the root CA certificate of the AEF, and after the bidirectional authentication, the AEF authenticates the API invoker according to the authorization information obtained from the CCF1, and the authentication follows the original process.

[0134] Based on the above-mentioned interaction process of the API invoker requesting the AEF service API, the authorization method can also be used for the OAuth2.0 token with the changed token version. Here, the first network entity is CCF1, the second network entity is CCF2, the identity information of the second network entity is the ID of CCF2, and the interaction process of the API invoker requesting the AEF service API using the OAuth2.0 token with the changed token version is shown in FIG. 7, which mainly includes the following steps:

[0135] Step 1: The API invoker sends a request message to the CCF2.

[0136] Step 2: The CCF2 receives the request message and sends an authorization request message to the CCF1.

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

[0138] Step 3: The CCF1 receives the authorization request message sent by the second network entity, authorizes the API invoker, and sends an authorization response message to the CCF2, wherein the authorization response message includes the ID of the CCF1 and a token, and the value of “client_id” in the token is the ID of the CCF2 and the API invoker ID.

[0139] 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 the CCF1 to the CCF2 and allowed to be accessed by the API invoker; 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 format of the “scope” can be “AEF: service1; service2”.

[0140] 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 invoker according to the “scope” in the token.

[0141] The security information in the configuration file should indicate which services of which AEFs the API invoker is allowed to access.

[0142] Step 5, the CCF2 sends the authorization response message to the API invoker.

[0143] Optionally, the authorization response message can further include a root CA certificate of the AEF, which can be provided by the CCF1 to the CCF2 through the CAPIF-6 / 6e reference point in the AEF service API publishing process.

[0144] Step 6, the API invoker sends a request service message to the AEF published by the CCF1, the request service message is used to request the AEF service API published by the CCF1, and the request service message includes authorization information.

[0145] Step 7, the AEF performs security information retrieval based on the API invoker ID, and when no security information related to the API invoker is detected, the AEF service API sends a request message for requesting the security information of the API invoker to the CCF1, and the request message includes the API invoker ID and the ID of the CCF2.

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

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

[0148] In the embodiment of the application, the security information request message includes at least one of the following: the API invoker ID, the ID of the CCF.

[0149] Step 9, based on the security information in the configuration file, the CCF2 sends a security information response message to the CCF1, and the security information response message carries the security information of the API invoker.

[0150] The security information indicates that the API invoker 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 mutual authentication, and the authorization method is the OAuth2.0 token with token version change.

[0151] Optionally, when the TLS server and client mutual authentication is used, the security information further includes the root CA certificate of the API invoker.

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

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

[0154] Optionally, when the TLS server and client are bidirectionally authenticated, the AEF verifies the API invoker according to the root CA certificate of the API invoker, the API invoker verifies the AEF according to the root CA certificate of the AEF, after the bidirectional authentication, the AEF authenticates the API invoker according to the authorization information obtained from the CCF1, and the authentication follows the original process.

[0155] Based on the above-mentioned interaction process in which the API invoker requests the AEF service API, the method of accessing the AEF service can also be a TLS-PKI method. Here, the first network entity is the CCF1, the second network entity is the CCF2, the identity information of the second network entity is the ID of the CCF2, and the interaction process in which the API invoker requests the AEF service API by using the TLS-PKI method is shown in FIG. 8, which mainly includes the following steps:

[0156] Step 1, the API invoker sends a request service message to the AEF published by the CCF1, the request service message is used to request the AEF service API published by the CCF1, and the request service message includes authorization information and an API invoker ID.

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

[0158] Step 2, the AEF performs security information retrieval based on the API invoker ID, and when no security information related to the API invoker is detected, the AEF sends a request message for requesting the security information of the API invoker to the CCF1.

[0159] In the embodiment of the present application, the request message includes at least one of the following: the API invoker ID and the ID of the CCF2.

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

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

[0162] In the embodiment of the present application, the security information request message comprises at least one of the following: API invoker ID, ID of CCF1.

[0163] Step 4, CCF2 sends a security information response message to CCF1 based on the security information in the configuration file, and the security information response message carries the security information of the API invoker.

[0164] The above security information indicates that the API invoker uses the TLS-PKI method to access AEF, the authentication method is TLS server and client mutual authentication, and the authorization method is authorization based on authorization information. The security information contains the root CA certificate of the API invoker.

[0165] Optionally, if the request service message includes the ID of CCF2 in the second step, the security information request message also includes the ID of CCF2, and CCF1 retrieves the security information related to the API invoker based on the API invoker ID and the ID of CCF2.

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

[0167] Step 6, based on the security information, the AEF verifies the API invoker according to the root CA certificate of the API invoker, the API invoker verifies the AEF according to the root CA certificate of the AEF, after the mutual authentication is completed, the AEF authenticates the API invoker according to the authorization information obtained from CCF1, and the authentication follows the original process.

[0168] In the embodiments of the present application, when the API invoker loaded on the second network entity triggers the uninstallation process, the second network entity is further configured to: send a second notification message to the first network entity, the second notification message being used to notify the first network entity that the API invoker has been invalidated; and receive a notification confirmation message sent by the first network entity, the notification confirmation message being used to indicate that the security information about the API invoker in the first network entity has been successfully deleted. The first network entity is further configured to: receive the second notification message sent by the second network entity, the second notification message being used to notify the first network entity that the API invoker has been invalidated; and send a notification confirmation message to the second network entity, the notification confirmation message being used to indicate that the security information about the API invoker in the first network entity has been successfully deleted, so as to achieve the uninstallation of the API invoker.

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

[0170] an event notification message, including at least one of the following: identity information of the second network entity, API invoker ID, and an uninstalled state of the API invoker;

[0171] an uninstallation notification message, including at least one of the following: identity information of the second network entity and API invoker ID.

[0172] The following takes the first network entity as CCF1 and the second network entity as CCF2, and takes the identity information of the second network entity as the ID of CCF2, and gives an uninstallation process of the API invoker triggered in the case that the API invoker has been loaded to CCF2, as shown in FIG. 9, including the following steps:

[0173] Step 1: The API invoker triggers the uninstallation process, and the CCF2 executes the uninstallation program. The specific uninstallation process is shown in steps 1-6 in Chapter 6.8 of 3GPP TS 33.122, which will not be described in detail here.

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

[0175] Step 2b: The AEF published by the CCF2 deletes the security information related to the API invoker, as shown in steps 8-10 in Chapter 6.8 of 3GPP TS 33.122.

[0176] Step 3: The CCF2 notifies the CCF1 that the API invoker has been uninstalled.

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

[0178] Optionally, an unload notification message is used, and the unload notification message comprises at least one of the following: an ID of the CCF2 and an API caller ID.

[0179] Step 4: The CCF1 and the AEF published by the CCF1 delete the security information related to the API caller in the same way as the CCF2 and the AEF published by the CCF2.

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

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

[0182] The authentication and authorization system for the API caller in the API framework interconnection provided by the embodiments of the application is closely cooperated by the three roles of the second network entity, the first network entity and the API caller in the system, mainly by providing the identity information of the second network entity for the API caller and forwarding the authorization request message and the security information between the network entities, the original business system is slightly changed, the authentication and authorization of the first network entity to the API caller not loaded to itself are realized, a distributed authorization process of multiple network entities is defined, and the risk of the centralized authorization server is avoided.

[0183] Based on the same inventive concept, the embodiments of the application provide an authentication and authorization method for an API caller in an API framework interconnection, which is applied to a second network entity and comprises the following steps:

[0184] Step 1001: Receiving a request message sent by the API caller, wherein the API caller has been loaded to the second network entity.

[0185] Step 1002: Sending an authorization request message to the first network entity.

[0186] Step 1003: Receiving an authorization response message sent by the first network entity.

[0187] Step 1004: Sending the authorization response message to the API caller.

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

[0189] In some possible embodiments, after receiving the request message sent by the API invoker, the method applied to the second network entity further comprises:

[0190] forwarding the request message to the first network entity as an authorization request message.

[0191] In some possible embodiments, the request message sent by the API invoker comprises at least one of:

[0192] an API invoker ID, identity information of the first network entity, and requested AEF service API information.

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

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

[0195] identity information of the second network entity, an API invoker ID, and requested AEF service API information.

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

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

[0198] updating security information in a profile of the API invoker according to authorization information in the authorization response message.

[0199] In some possible embodiments, the method further comprises providing the API invoker with identity information of the second network entity.

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

[0201] allocating an API invoker ID to indicate that the API invoker is loaded by the second network entity during loading of the API invoker;

[0202] providing the API invoker with identity information of the second network entity in an AEF service API authorization procedure in which the API invoker sends a request message to the second network entity to request an AEF service API published by a first network entity interconnected with the second network entity;

[0203] providing the API invoker with identity information of the second network entity in a loading procedure of the API invoker when the API invoker provides AEF service API information published by a first network entity interconnected with the second network entity.

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

[0205] In some possible embodiments, the loading procedure of the API invoker is further performed, and the loading procedure comprises:

[0206] when the first network entity has a subscription to the API invoker, sending a first notification message to the first network entity, the first notification message being used to notify the first network entity that the API invoker has been loaded to the second network entity.

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

[0208] an event notification message comprising at least one of the following: identity information of the second network entity, the API invoker ID, and a loaded state of the API invoker;

[0209] a loading notification message comprising at least one of the following: identity information of the second network entity and the API invoker ID.

[0210] In some possible embodiments, the method further comprises:

[0211] receiving a security information request message sent by the first network entity, the security information request message comprising at least one of the following: the API invoker ID and identity information of the first network entity;

[0212] sending a security information response message to the first network entity, the security information response message carrying security information of the API invoker.

[0213] In some possible embodiments, the security information is used for authentication and / or authorization between the API invoker and the AEF.

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

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

[0216] When the API invoker loaded on the second network entity triggers an uninstallation process, a second notification message is sent to the first network entity, the second notification message being used to notify the first network entity that the API invoker has been invalidated;

[0217] A notification confirmation message sent by the first network entity is received, the notification confirmation message being used to indicate that the security information about the API invoker in the first network entity has been successfully deleted.

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

[0219] An event notification message, including at least one of the following: identity information of the second network entity, an API invoker ID, and an unloaded state of the API invoker;

[0220] An uninstallation notification message, including at least one of the following: identity information of the second network entity and an API invoker ID.

[0221] Embodiments of the present application propose an authentication and authorization method for an API invoker in API framework interconnection, applied to a second network entity, which avoids the risk of a centralized authorization server and the conflict of an API invoker ID, defines a distributed authorization process in which multiple network entities cooperate, and also supports the authorization and access of an API invoker to an AEF service API in a cross-domain scenario.

[0222] Based on the same inventive concept, embodiments of the present application propose an authentication and authorization method for an API invoker in API framework interconnection, as shown in FIG. 11, applied to a first network entity, including:

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

[0224] Step 1102, authorizing the API invoker;

[0225] Step 1103, sending an authorization response message to the second network entity.

[0226] In some possible embodiments, the authorization request message is used to request the authorization of an AEF service API issued by the first network entity to the API invoker.

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

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

[0229] identity information of the second network entity, API invoker ID, requested AEF service API information.

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

[0231] In some possible embodiments, the method further comprises:

[0232] receiving a first notification message sent by the second network entity, when the first network entity has a subscription to the API invoker, the first notification message being used to notify the first network entity that the API invoker has been loaded to the second network entity.

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

[0234] an event notification message comprising at least one of the following: identity information of the second network entity, API invoker ID, loaded state of the API invoker;

[0235] a loading notification message comprising at least one of the following: identity information of the second network entity, API invoker ID.

[0236] In some possible embodiments, the method further comprises:

[0237] receiving a request message sent by an AEF for requesting the security information of the API invoker, the request message comprising at least one of the following: API invoker ID, identity information of the second network entity;

[0238] retrieving the security information of the API invoker based on the request message;

[0239] sending a security information response message to the AEF, the security information response message carrying the security information of the API invoker.

[0240] In some possible embodiments, the method further comprises:

[0241] when the security information of the API invoker is not retrieved, sending a security information request message to the second network entity;

[0242] receive the security information response message sent by the second network entity, wherein the security information response message carries the security information of the API invoker.

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

[0244] an API invoker ID and identity information of the first network entity.

[0245] In some possible embodiments, the security information is used for authentication and / or authorization between the API invoker and the AEF.

[0246] In some possible embodiments, when the authentication method between the API invoker and the AEF is certificate-based mutual authentication, the security information further comprises a root CA certificate of the API invoker.

[0247] In some possible embodiments, the method further comprises:

[0248] receiving a second notification message sent by the second network entity, wherein the second notification message is used to notify the first network entity that the API invoker has been invalidated;

[0249] sending a notification confirmation message to the second network entity, wherein the notification confirmation message is used to indicate that the security information about the API invoker in the first network entity has been successfully deleted.

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

[0251] an event notification message comprising at least one of the following: identity information of the second network entity, an API invoker ID, and an uninstalled state of the API invoker;

[0252] an uninstallation notification message comprising at least one of the following: identity information of the second network entity and an API invoker ID.

[0253] The authentication and authorization method for API invokers in the API framework interconnection provided in the embodiments of the present application has small changes to the original process, is compatible with the original authorization process and mode, the newly added process is not sensed by the API invoker and the AEF, only the network entity process is changed, and the single-domain authorization process and mode are compatible. The method solves the problem that the distributed authorization process in the prior art disperses the key attack risk that the centralized authorization may face, uses the network entity publishing the AEF service API to perform authorization, and supports the AEF to authenticate and authorize the API invoker by forwarding the authorization request message, the security information and the network entity identity information between multiple network entities.

[0254] Based on the same inventive concept, the embodiment of the present application proposes an authentication and authorization device for API invoker in API framework interconnection, which is a second network entity, as shown in FIG. 12, and comprises:

[0255] An authorization request receiving unit 1201 is configured to receive a request message sent by the API invoker, wherein the API invoker has been loaded to the second network entity;

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

[0257] An authorization response receiving unit 1203 is configured to receive an authorization response message sent by the first network entity;

[0258] An authorization response sending unit 1204 is configured to send the authorization response message to the API invoker.

[0259] Based on the same inventive concept, the embodiment of the present application proposes an authentication and authorization device for API invoker in API framework interconnection, which is a first network entity, as shown in FIG. 13, and comprises:

[0260] An authorization request processing unit 1301 is configured to receive an authorization request message sent by a second network entity interconnected with the first network entity;

[0261] An authorization unit 1302 is configured to authorize the API invoker;

[0262] An authorization response sending unit 1303 is configured to send an authorization response message to the second network entity.

[0263] Based on the same inventive concept, the embodiment of the present application proposes an authentication and authorization entity device for API invoker in API framework interconnection, as shown in FIG. 14, which comprises a memory and a processor, wherein:

[0264] The memory is configured to store programs executable by the processor;

[0265] The processor is configured to read the programs in the memory and execute the method applied to the second network entity in the authentication and authorization method for API invoker in API framework interconnection as described in the above description, or read the programs in the memory and execute the method applied to the first network entity in the authentication and authorization method for API invoker in API framework interconnection as described in the above description.

[0266] As shown in FIG. 14, the authentication and authorization entity device 140 for API invoker in API framework interconnection can be in the form of an electronic device. Components of the authentication and authorization entity device 140 for API invoker in API framework interconnection can include, but are not limited to, the at least one processor 141 described above, the at least one memory 142 described above, and a bus 143 that connects the various system components including the memory 142 and the processor 141.

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

[0268] The memory 142 can include a read-only memory (ROM) 1423 in the form of a non- volatile memory unit, a random access memory (RAM) 1421, and / or a cache memory 1422 that provides volatile storage for storing information and instructions for execution during the operation of the authentication and authorization entity device 140 for API invoker in API framework interconnection.

[0269] The memory 142 can further include the program / utility 1425 having a set of the program module 1424 that include an operating system, one or more application programs, other program modules, and program data, and each of these examples (or some combination thereof) can include implementations of the network environment.

[0270] The authentication and authorization entity device 140 for API invoker in API framework interconnection can also communicate with one or more external devices 144 such as a keyboard, a pointing device, etc.; and a user interface (UI) 147 utilizing tactile feedback for interaction with one or more of the authentication and authorization entity device 140 for API invoker in API framework interconnection. Additionally, the authentication and authorization entity device 140 for API invoker in API framework interconnection can communicate with one or more devices of an electronic system or electronic environment including other electronic devices 148 via an output interface 149 or via an external one or more of the network communication devices 146. As shown, such electronic devices 148 can include a computing device, such as a server, a database, a display, and the like. The communication can occur via the I / O interface 145. Still yet, the authentication and authorization entity device 140 for API invoker in API framework interconnection can communicate with one or more other electronic devices such as a display, a printer, a scanner, etc. via an output interface 149. In some embodiments, the authentication and authorization entity device 140 for API invoker in API framework interconnection can include a user interface 147 utilizing tactile feedback for interaction with one or more of the authentication and authorization entity device 140 for API invoker in API framework interconnection. The authentication and authorization entity device 140 for API invoker in API framework interconnection can also communicate via the network adapter 146 to one or more networks, such as a local area network (LAN), a general wide area network (WAN), and / or a public network such as the Internet. As depicted, the network adapter 146 communicates with the other components of the authentication and authorization entity device 140 for API invoker in API framework interconnection via the bus 143. It should be understood that although not shown, other hardware and / or software modules could be used in conjunction with the authentication and authorization entity device 140 for API invoker in API framework interconnection. Such as, but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archival storage systems, etc.

[0271] In some possible implementation, the various aspects of the method for authentication and authorization of API invoker in API framework interconnection provided by the present application can also be implemented in the form of a program product, which includes program codes for causing a computer device to perform the steps of the method for authentication and authorization of API invoker in API framework interconnection according to various exemplary embodiments of the present application described above in the specification when the program product is run on the computer device.

[0272] The program product can adopt any combination of one or more readable media. The readable medium can be a readable signal medium or a readable storage medium. The readable storage medium may, for example, be but is not limited to an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or apparatus, or any suitable combination of the above. More specific examples (a non-exhaustive list) of the readable storage medium include an electrical connection having one or more wires, a portable disc, 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 disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above.

[0273] The program product for monitoring of the embodiments of the present application can adopt a portable compact disc read-only memory (CD-ROM) and include program codes, and can be run on an electronic device. However, the program product of the present application is not limited thereto, and in the present document, the readable storage medium can be any tangible medium containing or storing a program which can be used by or in conjunction with an instruction execution system, device or apparatus.

[0274] The readable signal medium can include a data signal carried in a baseband or as part of a carrier wave, in which readable program codes are borne. Such a propagated data signal can take on many forms, including but not limited to electro-magnetic, optical, or any suitable combination thereof. The readable signal medium can also be any readable medium that can send, propagate or transport program for use by or in connection with an instruction execution system, device or apparatus.

[0275] The program codes contained in the readable medium can be transmitted by any suitable medium, including but not limited to wireless, wired, optical cable, RF, etc., or any suitable combination thereof.

[0276] Obviously, those skilled in the art can make various modifications and variations 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 authentication and authorization of an API invoker in API framework interconnection, characterized in that, The application is applied to a second network entity, and comprises: receiving a request message sent by an API invoker, wherein the API invoker has been loaded to the second network entity; sending an authorization request message to a first network entity; receiving an authorization response message sent by the first network entity; sending the authorization response message to the API invoker.

2. The method of claim 1, wherein, The request message sent by the API invoker is used to request authorization of an AEF service API published by the first network entity.

3. The method of claim 2, wherein, The request message comprises at least one of the following: an API invoker ID, identity information of the first network entity, and requested AEF service API information, wherein the requested AEF service API information indicates an AEF service API published by the first network entity.

4. The method of claim 1, wherein, The authorization request message is used to request authorization of the AEF service API published by the first network entity to the API invoker.

5. The method of claim 1, wherein, After receiving the request message sent by the API invoker, the method further comprises: forwarding the request message to the first network entity as an authorization request message.

6. The method of claim 1, wherein, The authorization request message sent by the second network entity comprises at least one of the following: identity information of the second network entity, an API invoker ID, and requested AEF service API information.

7. The method of claim 1, wherein, The authorization response message is used to indicate authorization information of an AEF service API published by the first network entity and allowed to be accessed by the API invoker.

8. The method of claim 1, wherein, After receiving the authorization response message sent by the first network entity, the method further comprises: updating security information in a configuration file of the API invoker according to authorization information in the authorization response message.

9. The method of claim 1, wherein, The method further comprises providing identity information of the second network entity for the API invoker.

10. The method of claim 9, wherein, The identity information of the second network entity provided for the API invoker is provided in at least one of the following ways: allocating an API invoker ID to indicate that the API invoker is loaded by the second network entity during loading of the API invoker; providing the identity information of the second network entity to the API invoker during sending of a request message by the API invoker to the second network entity to request authorization of an AEF service API published by a first network entity interconnected with the second network entity; providing the identity information of the second network entity to the API invoker when the API invoker provides AEF service API information published by the first network entity interconnected with the second network entity during loading of the API invoker.

11. The method of claim 10, wherein, After executing the loading procedure of the API invoker, the method further comprises: when the first network entity has a subscription to the API invoker, sending a first notification message to the first network entity, wherein the first notification message is used to notify the first network entity that the API invoker has been loaded to the second network entity.

12. The method of claim 11, wherein, The first notification message comprises any one of the following messages: an event notification message comprising at least one of the following: identity information of the second network entity, an API invoker ID, and a loaded state of the API invoker; a loading notification message comprising at least one of the following: identity information of the second network entity and an API invoker ID.

13. The method of claim 1, wherein, The method further comprises: receiving a security information request message sent by the first network entity, the security information request message comprising at least one of the following: an API invoker ID, identity information of the first network entity; sending a security information response message to the first network entity, the security information response message carrying security information of the API invoker.

14. The method of claim 13, wherein, The security information is used for authentication and / or authorization between the API invoker and the AEF.

15. The method of claim 14, wherein, When the authentication method between the API invoker and the AEF is certificate-based two-way authentication, the security information further comprises a root CA certificate of the API invoker.

16. The method of claim 1, wherein, Further comprising: When the API invoker loaded on the second network entity triggers an uninstallation process, sending a second notification message to the first network entity, the second notification message being used to notify the first network entity that the API invoker has been invalidated; receiving a notification confirmation message sent by the first network entity, the notification confirmation message being used to indicate that the security information about the API invoker in the first network entity has been successfully deleted.

17. The method of claim 16, wherein, The second notification message comprises any one of the following messages: An event notification message comprising at least one of the following: identity information of the second network entity, an API invoker ID, and an unloaded state of the API invoker; An uninstallation notification message comprising at least one of the following: identity information of the second network entity and an API invoker ID.

18. A method for authenticating and authorizing API callers in an API framework interconnection, characterized in that, Applied to a first network entity, comprising: receiving an authorization request message sent by a second network entity; authorizing the API invoker; sending an authorization response message to the second network entity.

19. The method of claim 18, wherein, The authorization request message is used to request authorization of the API invoker by an AEF service API published by the first network entity.

20. The method of claim 18, wherein, The authorization request message sent by the second network entity comprises at least one of the following: identity information of the second network entity, an API invoker ID, and requested AEF service API information.

21. The method of claim 18, wherein, The authorization response message is used to indicate authorization information of the AEF service API published by the first network entity and allowed to be accessed by the API invoker.

22. The method of claim 18, wherein, Further comprising: When the first network entity has a subscription to the API invoker, receiving a first notification message sent by the second network entity, the first notification message being used to notify the first network entity that the API invoker has been loaded to the second network entity.

23. The method of claim 22, wherein, The first notification message comprises any one of the following messages: An event notification message comprising at least one of the following: identity information of the second network entity, an API invoker ID, and a loaded state of the API invoker; A loading notification message comprising at least one of the following: identity information of the second network entity and an API invoker ID.

24. The method of claim 18, wherein, Further comprising: receiving a request message sent by an AEF for requesting security information of the API invoker, the request message comprising at least one of the following: an API invoker ID and identity information of the second network entity; retrieving the security information of the API invoker based on the request message; sending a security information response message to the AEF, the security information response message carrying the security information of the API invoker.

25. The method of claim 24, wherein, Further comprising: sending a security information request message to the second network entity when the security information of the API invoker is not retrieved; receiving a security information response message sent by the second network entity, the security information response message carrying the security information of the API invoker.

26. The method of any one of claims 24 or 25, wherein, The security information request message comprises at least one of: API invoker ID, identity information of the first network entity.

27. The method of claim 26, wherein, The security information is used for authentication and / or authorization between the API invoker and the AEF.

28. The method of claim 27, wherein, When the authentication method between the API invoker and the AEF is certificate-based two-way authentication, the security information further comprises the root CA certificate of the API invoker.

29. The method of claim 18, wherein, Further comprising: receiving a second notification message sent by the second network entity, the second notification message being used to notify the first network entity that the API invoker has been invalidated; sending a notification confirmation message to the second network entity, the notification confirmation message being used to indicate that the security information about the API invoker in the first network entity has been successfully deleted.

30. The method of claim 29, wherein, The second notification message comprises any one of the following messages: an event notification message comprising at least one of the following: identity information of the second network entity, API invoker ID, and unloaded state of the API invoker; an uninstall notification message comprising at least one of the following: identity information of the second network entity and API invoker ID.

31. An authentication and authorization device for API callers in an API framework interconnection, characterized in that, Comprising: an authorization request receiving unit configured to receive a request message sent by the API invoker, the API invoker having been loaded to 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 configured to send the authorization response message to the API invoker.

32. An authentication and authorization device for API invoker in API framework interconnection, characterized in that, Comprising: a memory and a processor, wherein: the memory is configured to store programs executable by the processor; the processor is configured to read the programs in the memory and execute the authentication and authorization method for the API invoker in the API framework interconnection as claimed in any one of claims 1-16, or to read the programs in the memory and execute the authentication and authorization method for the API invoker in the API framework interconnection as claimed in any one of claims 17-29.

Images