Service API calling method and apparatus

Abstract

Provided in the present application are a service API calling method and apparatus, which are applied to a common application programming interface (API) framework to realize calling for service APIs of different authorization types. The method comprises: an API information functional entity receiving an identifier and an authorization type of a service API from an API publishing functional entity, and the API information functional entity sending the identifier and the authorization type of the service API to an API caller. In this way, when an API caller calls the service API, a calling method for the service API can be determined on the basis of an authorization type corresponding to the service API, thereby improving the security performance.

Description

Method and device for calling service API

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office on August 1, 2023, with application number 202310966577.7 and application name “Method and Apparatus for Service API Calling”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of communication technology, and in particular to a method and device for calling a service API. Background Art

[0003] The 3rd Generation Partnership Project (3GPP) defines various application programming interface (API) specifications. To avoid duplication and inconsistencies between API specifications, 3GPP has defined a common API framework (CAPIF), which contains common features applicable to APIs. 3GPP networks can use this CAPIF to provide external services.

[0004] Under CAPIF, API callers can request 3GPP information from the 3GPP network. For example, an API caller can request a user's location information from the 3GPP network, which is considered private information. If an API caller obtains 3GPP information without the user's authorization, there is a risk of exposing the user's private information.

[0005] Therefore, how to implement service API calls with different authorization methods under the existing CAPIF architecture to improve security performance is a technical problem that needs to be solved urgently.

[0006] Summary of the Invention

[0007] The embodiments of the present application provide a method and apparatus for calling a service API, which can implement the calling of service APIs of different authorization types under CAPIF, thereby improving security performance.

[0008] To achieve the above objectives, this application adopts the following technical solutions:

[0009] In a first aspect, a method for calling a service API is provided, applied within a general API framework. An API information function entity provides an API caller with an interface for calling the service API published by an API publishing function entity. The method comprises: receiving an identifier and first information about the service API from the API publishing function entity. The first information includes an authorization type, which indicates the authorization method for the service API. Method information associated with the authorization type is sent to the API caller; the method information is used to determine the method for calling the service API.

[0010] It is understood that in this application, the API caller can be an application function entity (AF), a client, a third-party application, or a terminal device (such as a mobile phone), or a chip (system) that can be set in the terminal device. The API information function entity can be a CAPIF core function entity, or a component of the CAPIF core function entity (such as a chip or circuit), without limitation.

[0011] Based on the method provided in the first aspect, the API information functional entity obtains the identifier of the service API and the corresponding authorization type from the API publishing functional entity. Subsequently, the API information functional entity sends the method information associated with the authorization type to the API caller. In this way, when the API caller calls the service API, the calling method of the service API can be determined based on the method information. For example, for a service API that can access user privacy, the method information is authorization code authorization or PKCE, so that the API caller needs the user to participate in the authorization when calling the service API, thereby improving security performance.

[0012] In one possible implementation, a single service API may have multiple authorization types, but an API caller may use only one authorization type when calling the service API. The API information function entity may determine one of the multiple authorization types, namely, method information. Prior to sending the method information associated with the authorization type to the API caller, the method further includes obtaining the method information based on the authorization type.

[0013] In one possible implementation, before sending the method information associated with the authorization type to the API caller, the method further includes: receiving capability information from the API caller; wherein the capability information is used to indicate the authorization type supported by the API caller. According to the authorization type, the method information is obtained, including: selecting the method information according to the capability information and the authorization type. By obtaining the capability information of the API caller, the API caller and the network can negotiate different authorization types for the service API, and determine the method information in combination with the authorization type supported by the API caller and one or more authorization types of the service API, thereby ensuring that the determined method information is the authorization type supported by the API caller, thereby avoiding the API caller using an authorization type that it does not support to call the service API, resulting in a call failure.

[0014] In one possible implementation, the first information also includes an identifier of an API open function (AEF). Receiving capability information from the API caller includes: receiving the capability information from the API caller and the identifier of the AEF. The method further includes: determining the authorization type based on the identifier of the AEF; the authorization type indicates the authorization type corresponding to the AEF. It should be noted that the authorization type here is at the AEF granularity level, and the API information function entity obtains the AEF identifier and the corresponding authorization type from the API publishing function entity. Subsequently, when the API caller requests a secure method, the API information function entity obtains the capability information of the API caller and the identifier of the AEF. The API information function entity can then determine the authorization type corresponding to the AEF based on the identifier of the AEF. Furthermore, the API information function entity can determine method information based on the authorization types supported by the API caller and the authorization type corresponding to the AEF, ensuring that the determined method information is an authorization type supported by the API caller. The API information function entity sends the identifier of the AEF and the corresponding authorization type to the API caller. Thus, when the API caller calls the service API through the AEF, the service API calling method can be determined based on the authorization type of the AEF.

[0015] In one possible implementation, the API information functional entity stores the identifier and first information of the service API. By storing a correspondence between the service API and the authorization type, when an API caller subsequently requests to discover the service API, the API information functional entity can determine the authorization type based on the stored correspondence and the identifier of the service API.

[0016] In one possible implementation, the first information further includes an AEF identifier. By storing the correspondence between the AEF identifier and the authorization type, when the API caller subsequently reports the AEF identifier via a request security method message, the API information function entity can determine its authorization type based on the stored correspondence and the AEF identifier.

[0017] In one possible implementation, after receiving the identifier and first information of the service API from the application programming interface API publishing functional entity, the method further includes: receiving the identifier and second information of the service API from the API publishing functional entity; wherein the second information is different from the first information. The first information is updated to the second information. It is understandable that when the API information functional entity receives the first information and the second information for the identifier of the same service API respectively, the first information of the service API is updated to the second information, wherein the first information is the old service API information and the second information is the new service API information. This ensures that the information of the published service API is the latest, and avoids the API caller using the old service API information to call the service API, resulting in call failure.

[0018] In a possible implementation, a reason value is received from the API publishing functional entity; the reason value is used to indicate that the information corresponding to the service API is updated.

[0019] In one possible implementation, the second information is sent to the API caller. Alternatively, the API caller subscribes to service API information change events. When service API information changes, the second information is sent to the API caller. This allows the API caller to obtain the latest service API information in a timely manner.

[0020] In one possible implementation, the first information also includes one or more of the identifier, scope, and PKCE security method of the authorization function AuF; wherein the identifier of the AuF is used to indicate the address of the AuF; the scope is used to indicate the scope of authorization allowed by the service API; the PKCE security method is used to indicate the method of generating a challenge value, and the challenge value is used to verify the identity of the API caller.

[0021] In one possible implementation, one or more of the AuF identifier, the range, and the determined PKCE security method are sent to the API caller; wherein the determined PKCE security method is determined based on the PKCE security method.

[0022] In one possible implementation, the authorization type of the service API includes one or more of client credential authorization, authorization code authorization, and proof key PKCE for authorization code exchange. Among them, the authorization code authorization and the PKCE are both applicable to scenarios where users participate in authorization. Since users need to participate in the authorization process, the risk of API callers directly obtaining access tokens can be avoided. At the same time, the authorization code can only be used once and has a short validity period, which can effectively prevent the risk of authorization code leakage. The client credential authorization is applicable to scenarios where API callers need to access their own resources. At the same time, since users do not need to participate in the authorization process, the user experience can be improved.

[0023] In one possible implementation, the authorization type also includes implicit authorization and resource owner password authorization. Implicit authorization is applicable to applications that do not require backend server support, while resource owner password authorization is applicable to backend applications. That is, the authorization type of the service API includes one or more of client credential authorization, authorization code authorization, proof key for authorization code exchange (PKCE), implicit authorization, and resource owner password authorization.

[0024] In one possible implementation, sending the method information associated with the authorization type to the API caller includes: receiving a service discovery request message from the API caller, the service discovery request message being used to request discovery of the service API; and sending the method information associated with the authorization type to the API caller in response to the service discovery request message.

[0025] In one possible implementation, sending the method information associated with the authorization type to the API caller includes: receiving a security method request message from the API caller, the security method request message being used to negotiate a security method; and sending the method information associated with the authorization type to the API caller in response to the security method request message.

[0026] In a second aspect, a method for calling a service API is provided, which is applied to a general API framework, wherein an API caller calls the service API published by an API publishing function entity through an API information function entity. The method comprises: receiving method information from the API information function entity; wherein the method information includes one or more of client credential authorization, authorization code authorization, and a proof key for authorization code exchange (PKCE); requesting an access token for calling the service API from the API information function entity based on the method information; and the method information is used to determine the calling method of the service API.

[0027] In the method provided in the second aspect, an API caller receives method information of a service API from an API information function entity. Thus, when the API caller calls the service API, it can determine the calling method of the service API based on the method information. For example, for a service API that can access user privacy, by using an authorization code authorization method or a PKCE method as the calling method, the API caller requires the user to participate in authorization when calling the service API, thereby improving security performance.

[0028] In one possible implementation, the method information includes two or three of the client credential authorization, the authorization code authorization, and the PKCE, and the method further includes: the API caller determines the calling method of the service API based on the method information. The method information of the same service API may include multiple calling methods, but the API caller can only use one of the calling methods when calling the service API. In this case, the API caller can determine a calling method from the method information.

[0029] In one possible implementation, determining the service API call method based on the method information includes: selecting one of the call methods from the method information based on a local policy; wherein the local policy indicates a priority of different call methods. The API caller selects the call method with the highest priority based on the priorities of the different call methods, thereby ensuring that the selected call method is optimal.

[0030] In one possible implementation, it is determined whether the calling method of the service API is applicable to the service API.

[0031] In one possible implementation, requesting an access token for calling the service API from the API information functional entity according to the method information includes: when the calling method is a client credential authorization method, requesting an access token for calling the service API from the API information functional entity; or, when the calling method is an authorization code authorization method, obtaining a first authorization code, and using the first authorization code to request an access token for calling the service API from the API information functional entity; or, when the calling method is a PKCE method, obtaining a second authorization code and a verification value, and using the second authorization code and the verification value to request an access token for calling the service API from the API information functional entity.

[0032] In one possible implementation, an identifier of the authorization function AuF is received from the API information function entity; wherein the identifier of the AuF is used to indicate the address of the AuF. When the calling method is the authorization code authorization method, the first authorization code is requested from the AuF according to the identifier of the AuF; or, when the calling method is the PKCE method, the second authorization code is requested from the AuF according to the identifier of the AuF. It is understandable that when the calling method is the authorization code authorization method or PKCE, the API caller needs to request an authorization code from the AuF. By receiving the identifier of the AuF from the API information function entity, the API caller can determine the address of the AuF.

[0033] In one possible implementation, a scope is received from the API information functional entity. A determination is made as to whether the scope includes the scope used by the API caller when requesting an access token for calling the service API; wherein the scope is used to indicate the scope that the service API allows to be authorized. It is understandable that the scope received from the API information functional entity is the scope within which the service API is authorized to access user resources. Therefore, the scope used by the API caller when requesting an access token for calling the service API cannot exceed the scope received from the API information functional entity. By sending the scope to the API caller, call failures caused by excessive scope when the API caller uses the access token to call the API are avoided.

[0034] In one possible implementation, a PKCE security method is received from the API information function entity. When the calling method is the PKCE method, obtaining a second authorization code and verification value includes: generating a challenge value based on the verification value and the PKCE security method; wherein the challenge value is used to verify the identity of the API caller.

[0035] In one possible implementation, second information is received from the API information functional entity, the second information including updated method information. An access token for calling the service API is requested from the API information functional entity based on the updated method information. The API caller uses the updated method information to request an access token for calling the service API, thereby preventing the API caller from using outdated service API information to call the service API, resulting in a call failure.

[0036] In one possible implementation, second information is received from the API information function entity, the second information including an updated AuF identifier. A third authorization code is requested from the AuF based on the updated AuF identifier; wherein the third authorization code is used to request an access token for invoking the service API from the API information function entity.

[0037] In one possible implementation, second information is received from the API information function entity, the second information including an updated scope, and it is determined whether the updated scope includes the scope used by the API caller when requesting an access token for calling the service API.

[0038] In one possible implementation, second information is received from the API information function entity, the second information including an updated PKCE security method, and a challenge value is generated according to the verification value and the updated PKCE security method.

[0039] In one possible implementation, the API caller is accessing the service API through the first information, and the method further includes: the API caller uses the second information to re-initiate a request to call the access token of the service API. In the case where the API caller uses the old service API information to access the service API, for the same service API, the API caller re-initiates the call of the service API by using the received new second information. For example, the range in the first information includes the user location, but the range in the second information does not include the user location. By the API caller re-initiating the call of the service API, it is ensured that the information used by the API caller is the latest, thereby improving the security of authorization and avoiding privacy leaks.

[0040] In one possible implementation, before receiving method information from the API information functional entity, the method further includes: sending capability information to the API information functional entity, where the capability information indicates the calling methods supported by the API caller. For related descriptions, refer to the content related to the first aspect above and will not be repeated here.

[0041] In a possible implementation manner, sending capability information to the API information function entity includes: sending capability information and an identifier of an API open function AEF to the API information function entity.

[0042] In one possible implementation, the method information includes one or more of client credential authorization, authorization code authorization, proof key for authorization code exchange (PKCE), implicit authorization, and resource owner password authorization. Implicit authorization is applicable to applications that do not require backend server support, while resource owner password authorization is applicable to backend applications. For related descriptions, refer to the content related to the first aspect above and will not be repeated here.

[0043] In one possible implementation, receiving method information from the API information functional entity includes: sending a service discovery request message to the API information functional entity, the service discovery request message being used to request discovery of the service API, and receiving a service discovery response message from the API information functional entity, the service discovery response message including the method information.

[0044] In one possible implementation, receiving method information from the API information functional entity includes: sending a security method request message to the API information functional entity, the security method request message being used to negotiate a security method, and receiving a security method response message from the API information functional entity, the security method response message including the method information associated with the authorization type.

[0045] On the third aspect, a method for calling a service API is provided, which is applied under a general API framework, wherein the API publishing functional entity publishes the service API to the API caller through the API information functional entity, and the method includes: sending the identifier and first information of the service API to the API information functional entity; wherein the first information includes an authorization type; the authorization type is used to indicate the authorization method of the service API.

[0046] Based on the method provided in the third aspect, the identifier of the service API and the corresponding authorization type are sent to the API information functional entity. Subsequently, the API caller obtains the authorization type of the service API from the API information functional entity. In this way, when the API caller calls the service API, the calling method of the service API can be determined according to the authorization type of the service API. For example, for a service API that can access user privacy, by publishing the authorization type corresponding to the service API as authorization code authorization or PKCE, the API caller needs the user to participate in the authorization when calling the service API, thereby improving security performance.

[0047] In a possible implementation, the first information further includes an identifier of an API open function AEF.

[0048] In one possible implementation, after sending the identifier and first information of the service API to the API information functional entity, the method further includes: sending the identifier and second information of the service API to the API information functional entity; wherein the second information is different from the first information.

[0049] In a possible implementation, a reason value is sent to the API information function entity, where the reason value is used to indicate that the information corresponding to the service API is updated.

[0050] In one possible implementation, the first information also includes one or more of the identifier, scope, and PKCE security method of the authorization function AuF; wherein the identifier of the AuF is used to indicate the address of the AuF; the scope is used to indicate the scope of authorization allowed by the service API; the PKCE security method is used to indicate the method of generating a challenge value, and the challenge value is used to verify the identity of the API caller.

[0051] In a possible implementation, the authorization type includes one or more of client credential authorization, authorization code authorization, and proof key for authorization code exchange (PKCE).

[0052] In one possible implementation, the authorization type also includes implicit authorization and resource owner password authorization. For related descriptions, please refer to the content related to the first aspect above and will not be repeated here.

[0053] In one possible implementation, sending the identifier and first information of the service API to the API information function entity includes: sending a service API publishing request message to the API publishing function entity, wherein the service API publishing request message is used to publish the service API, and the service API publishing request message includes the identifier and first information of the service API.

[0054] In a fourth aspect, an embodiment of the present application provides a device having the function of implementing the behavior of the API information functional entity in the above-mentioned method design. The function can be implemented by hardware, or by hardware executing corresponding software implementation. The hardware or software includes one or more modules corresponding to the above-mentioned functions. For example, the device can be an API information functional entity, or it can be a chip in an API information functional entity.

[0055] In one possible design, the apparatus is an API information function entity, which includes a processor configured to support the API information function entity in performing the corresponding functions in the above method. Furthermore, the API information function entity may also include a communication interface configured to support communication between the API information function entity and a user plane entity or other network element of a centralized unit. Furthermore, the API information function entity may also include a memory configured to be coupled to the processor and to store necessary program instructions and data for the API information function entity.

[0056] In a fifth aspect, embodiments of the present application provide a device having the function of implementing the API caller behavior in the above-mentioned method design. The function can be implemented by hardware, or by hardware executing corresponding software implementation. The hardware or software includes one or more modules corresponding to the above-mentioned functions. For example, the device can be an API caller, or it can be a chip in the API caller.

[0057] In one possible design, the apparatus is an API caller, which includes a processor configured to support the API caller in executing the corresponding functions of the above method. Furthermore, the API caller may also include a communication interface configured to support communication between the API caller and a user plane entity or other network element of a centralized unit. Furthermore, the API caller may also include a memory configured to be coupled to the processor and to store program instructions and data necessary for the API caller.

[0058] In a sixth aspect, an embodiment of the present application provides a device having the function of implementing the behavior of the API publishing functional entity in the above-mentioned method design. The function can be implemented by hardware, or by hardware executing corresponding software implementation. The hardware or software includes one or more modules corresponding to the above-mentioned functions. For example, the device can be an API publishing functional entity, or it can be a chip in an API publishing functional entity.

[0059] In one possible design, the apparatus is an API publishing functional entity, which includes a processor configured to support the API publishing functional entity in performing the corresponding functions in the above method. Furthermore, the API publishing functional entity may also include a communication interface, which is used to support communication between the API publishing functional entity and a user plane entity or other network element of a centralized unit. Furthermore, the API publishing functional entity may also include a memory, which is used to couple with the processor and store program instructions and data necessary for the API publishing functional entity.

[0060] In the seventh aspect, an embodiment of the present application provides a communication system, which includes the API caller and API information functional entity described in the above aspects; or, the system includes the API information functional entity and API publishing functional entity described in the above aspects; or, the system includes the API caller, API publishing functional entity and API information functional entity described in the above aspects.

[0061] In an eighth aspect, an embodiment of the present application provides a computer storage medium for storing computer software instructions used for the above-mentioned API information functional entity, which includes a program designed for executing the actions of the API information functional entity in the above-mentioned first aspect or fourth aspect.

[0062] In the ninth aspect, an embodiment of the present application provides a computer storage medium for storing computer software instructions used by the above-mentioned API caller, which includes a program designed to execute the actions of the API caller in the second aspect or the fifth aspect.

[0063] In the tenth aspect, an embodiment of the present application provides a computer storage medium for storing computer software instructions used for the above-mentioned API publishing functional entity, which includes a program designed to execute the actions of the API publishing functional entity in the third aspect or the sixth aspect.

[0064] On the eleventh aspect, an embodiment of the present application provides a chip system, which is applied to an API information functional entity. The chip system includes at least one processor, a memory and an interface circuit. The memory, the interface circuit and the at least one processor are interconnected through lines, and instructions are stored in the at least one memory; the instructions are executed by the processor to perform the operations of the API information functional entity in the above method.

[0065] In the twelfth aspect, an embodiment of the present application provides a chip system for use in an API caller, wherein the chip system includes at least one processor, a memory and an interface circuit, wherein the memory, the interface circuit and the at least one processor are interconnected through lines, and instructions are stored in the at least one memory; the instructions are executed by the processor to perform the operations of the API caller in the above method.

[0066] In the thirteenth aspect, an embodiment of the present application provides a chip system, which is applied to an API publishing functional entity. The chip system includes at least one processor, a memory and an interface circuit. The memory, the interface circuit and the at least one processor are interconnected through lines, and instructions are stored in the at least one memory; the instructions are executed by the processor to perform the operations of the API publishing functional entity in the above method.

[0067] In a fourteenth aspect, a computer program product is provided, comprising a computer program or instructions, which, when the computer program or instructions are run on a computer, enables the computer to execute the method described in any one of the possible implementation methods above.

[0068] In the above solution, under CAPIF, the API information functional entity receives the service API's identifier and authorization type. Thus, the API caller can obtain the authorization type from the API information functional entity. When the API caller calls the service API, it can then call the service API based on the authorization type. This enables the calling of service APIs with different authorization types under the CAPIF architecture, thereby improving security performance. BRIEF DESCRIPTION OF THE DRAWINGS

[0069] FIG1 shows a communication network architecture diagram applicable to the present application;

[0070] FIG2 shows a schematic diagram of the architecture of CAPIF applicable to the present application;

[0071] FIG3 is a schematic diagram of a process of calling an API;

[0072] FIG4 is a schematic diagram of another process of calling an API;

[0073] FIG5 is a schematic diagram of another process of calling an API;

[0074] FIG6 is a flow chart of a communication method 600 provided in an embodiment of the present application;

[0075] FIG7 is a flow chart of a communication method 700 provided in an embodiment of the present application;

[0076] FIG8 is a flow chart of a communication method 800 provided in an embodiment of the present application;

[0077] FIG9 is a flow chart of a communication method 900 provided in an embodiment of the present application;

[0078] FIG10 is a schematic block diagram of a device provided in an embodiment of the present application;

[0079] FIG11 is a schematic structural diagram of a device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0080] To make the objectives, technical solutions, and advantages of this application more clear, the present application will be further described in detail below with reference to the accompanying drawings. The specific operating methods in the method embodiments can also be applied to the device embodiments or system embodiments. In the description of this application, unless otherwise specified, the meaning of "multiple" is two or more.

[0081] In the various embodiments of the present application, unless otherwise specified or there is a logical conflict, the terms and / or descriptions between different embodiments are consistent and can be referenced by each other. The technical features in different embodiments can be combined to form new embodiments according to their inherent logical relationships.

[0082] It is understood that the various numbers used in this application are for ease of description and are not intended to limit the scope of this application. The order of the numbers of the following processes does not imply a specific order of execution; the order of execution of each process should be determined by its function and inherent logic.

[0083] The terms "first," "second," "third," "fourth," and various other terminology designations, if any, in the specification and claims of this application and in the accompanying drawings are used to distinguish similar objects and are not necessarily used to describe a particular order or precedence. It should be understood that the terms used in this manner are interchangeable where appropriate so that the embodiments described herein can be implemented in an order other than that illustrated or described herein. In addition, the terms "including" and "having," and any variations thereof, are intended to cover non-exclusive inclusions, e.g., a process, method, system, product, or apparatus comprising a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0084] The technical solutions provided in this application can be applied to various communication systems, such as: fifth generation (5G) or new radio (NR) systems, long term evolution (LTE) systems, LTE frequency division duplex (FDD) systems, LTE time division duplex (TDD) systems, etc. The technical solutions provided in this application can also be applied to future communication systems, such as the sixth generation mobile communication system. The technical solutions provided in this application can also be applied to device to device (D2D) communication, vehicle-to-everything (V2X) communication, machine to machine (M2M) communication, machine type communication (MTC), and Internet of Things (IoT) communication systems or other communication systems.

[0085] The following will describe a 5G system applicable to the embodiment of the present application with reference to (a) and (b) in Figure 1. It should be understood that the 5G system described herein is merely an example and does not constitute any limitation to the present application.

[0086] It should also be understood that certain network elements in the 5G system can communicate using a service-oriented interface or a point-to-point interface. The following introduces the 5G system framework based on a point-to-point interface and the 5G system framework based on a service-oriented interface in conjunction with (a) in Figure 1 and (b) in Figure 1, respectively.

[0087] As an exemplary illustration, FIG1 shows a schematic diagram of the architecture of a 5G system to which an embodiment of the present application applies. The network architecture may include, but is not limited to, the following network elements (or referred to as functional network elements, functional entities, nodes, devices, etc.):

[0088] (Radio) access network equipment (radio access network, (R)AN), access and mobility management function (AMF) network element, session management function (SMF) network element, user plane function (UPF) network element, policy control function (PCF) network element, unified data management (UDM) network element, AF network element, data network (DN), network exposure function (NEF), network storage function (NF repository function, NRF), authentication server function (AUSF), unified data management (UDM), unified data repository (UDR), etc.

[0089] The following is a brief introduction to the network elements shown in Figure 1:

[0090] 1. User equipment (UE): This term may also be referred to as terminal equipment, terminal device, access terminal, subscriber unit, subscriber station, mobile station, mobile station (MS), mobile terminal (MT), remote station, remote terminal, mobile device, user terminal, terminal, communication device, user agent, or user device. UE is a device that provides voice / data connectivity to a user, such as a handheld device or vehicle-mounted device with wireless connectivity. At present, some examples of terminals may include: mobile phones, tablet computers, computers with wireless transceiver functions (such as laptops, PDAs, etc.), mobile internet devices (MIDs), virtual reality (VR) devices, augmented reality (AR) devices, wireless terminals in industrial control, wireless terminals in self-driving, wireless terminals in remote medical, wireless terminals in smart grids, wireless terminals in transportation safety, wireless terminals in smart cities, wireless terminals in smart homes, cellular phones, cordless phones, session initiation protocol (SIP) phones, wireless local loop (WLL) stations, personal digital assistants (PDAs), handheld devices with wireless communication functions, computing devices or other processing devices connected to wireless modems, vehicle-mounted devices, wearable devices, terminal devices in 5G networks or future evolved public land mobile communication networks (PLMNs). terminal equipment in network, PLMN, etc.

[0091] Furthermore, user devices can also be terminal devices in the Internet of Things (IoT) system. IoT is a crucial component of future information technology development. Its primary technical feature is connecting objects to the Internet through communications, thereby enabling intelligent networks that interconnect humans and machines, and objects and things. IoT technology, for example, utilizes narrowband (NB) technology to achieve massive connectivity, deep coverage, and power-saving terminals.

[0092] It should be understood that the user equipment may be any device that can access a network. The user equipment and the access network device may communicate with each other using a certain air interface technology.

[0093] 2. (Radio) access network (R)AN) equipment: used to provide network access for authorized user devices in a specific area, and can use transmission tunnels with different service qualities based on the level of user devices and business requirements.

[0094] (R)AN can manage wireless resources, provide access services to user equipment, and forward control signals and user equipment data between the user equipment and the core network. (R)AN can also be understood as a base station in a traditional network.

[0095] Exemplarily, the access network device in the embodiment of the present application can be any communication device with wireless transceiver functions for communicating with a user equipment. The access network device includes but is not limited to an evolved Node B (eNB) or a gNB in ​​a 5G, such as an NR, system, or a transmission point (TRP or TP), one or a group (including multiple antenna panels) of antenna panels of a base station in a 5G system, or a network node constituting a gNB or a transmission point, such as a baseband unit (BBU), or a distributed unit (DU).

[0096] In some deployments, a gNB may include a centralized unit (CU) and a DU. The gNB may also include an active antenna unit (AAU). The CU implements some gNB functions, while the DU implements some gNB functions. For example, the CU is responsible for processing non-real-time protocols and services, implementing the functions of the radio resource control (RRC) and packet data convergence protocol (PDCP) layers. The DU is responsible for processing physical layer protocols and real-time services, implementing the functions of the radio link control (RLC), media access control (MAC), and physical (PHY) layers. The AAU implements some physical layer processing functions, RF processing, and active antenna-related functions. Because RRC layer information ultimately becomes PHY layer information, or is converted from PHY layer information, in this architecture, higher-layer signaling, such as RRC layer signaling, can also be considered to be sent by the DU, or by both the DU and the AAU. It is understood that access network equipment may include one or more of the following: a CU node, a DU node, or an AAU node. In addition, the CU may be classified as an access network device in an access network (radio access network, RAN), or the CU may be classified as an access network device in a core network (core network, CN), which is not limited in this application.

[0097] 3. User plane function (UPF) network element: used for packet routing and forwarding, as well as quality of service (QoS) processing of user plane data.

[0098] In a 5G communication system, the user plane network element may be a user plane function (UPF) network element. In future communication systems, the user plane network element may still be a UPF network element, or may have other names, which are not limited in this application.

[0099] 4. Access and mobility management function (AMF) network element: The access and mobility management function network element is mainly used for mobility management and access management, such as user location update, user registration network, user switching, etc.

[0100] In future communication systems, the access and mobility management device may still be AMF, or may have other names, which is not limited in this application.

[0101] 5. Session management function (SMF) network element: mainly used for session management, Internet protocol (IP) address allocation and management of user equipment, selection of UPF that provides message forwarding function, termination point of policy control and charging function interface, and downlink data notification.

[0102] In future communication systems, the session management network element may still be an SMF network element, or may have other names, which is not limited in this application.

[0103] 6. Policy control function (PCF) network element: a policy management function used to guide network behavior and provide policy rule information to control plane function network elements (such as AMF, SMF, etc.).

[0104] In future communication systems, the policy control network element may still be a PCF network element, or may have other names, which is not limited in this application.

[0105] 7. Application function (AF): mainly supports interaction with the 3GPP core network to provide services, such as influencing data routing decisions, providing some third-party services to the policy control function or the network side, etc.

[0106] In future communication systems, the application network element may still be an AF network element, or may have other names, which is not limited in this application.

[0107] 8. Unified data management (UDM) network element: used to store user data, such as contract data, authentication / authorization data, etc.

[0108] In future communication systems, unified data management may still be a UDM network element, or it may have other names, which is not limited in this application.

[0109] 9. Authentication server function (AUSF) network element: used for authentication services, generating keys to achieve two-way authentication of user devices, and supporting a unified authentication framework.

[0110] In future communication systems, the authentication server function network element may still be an AUSF network element, or it may have other names, which is not limited in this application.

[0111] 10. Data Network (DN): A DN is a network located outside of a carrier network. A carrier network can access multiple DNs, and a variety of services can be deployed on the DN, providing data and / or voice services to terminal devices. For example, a DN is the private network of a smart factory. Sensors installed in the workshop of the smart factory can be terminal devices. A control server for the sensors is deployed in the DN, and the control server can provide services to the sensors. The sensors can communicate with the control server, obtain instructions from the control server, and transmit the collected sensor data to the control server according to the instructions. For another example, a DN is the internal office network of a company. The mobile phones or computers of the company's employees can be terminal devices, and the employees' mobile phones or computers can access information, data resources, etc. on the company's internal office network.

[0112] 11. Network Exposure Function (NEF) network elements are primarily used to support the openness of capabilities and events. NEF network elements can provide open interfaces for network functions, allowing third-party applications to access various services and resources in the 5G network. NEF network elements can expose network functions to third-party applications, allowing these applications to utilize these network functions to provide richer services and applications.

[0113] 12. The Network Repository Function (NRF) element is primarily used to maintain information about network resources, including network functions, services, and applications. The NRF element provides query and discovery capabilities for network resources, enabling third-party applications to quickly locate required network resources and utilize them to provide richer services and applications.

[0114] In FIG1(a), Nausf, Nnef, Npcf, Nudm, Naf, Namf, Nsmf, N1, N2, N3, N4, and N6 are interface sequence numbers. The meanings of these interface sequence numbers can be found in the 3GPP standard protocol and are not limited here.

[0115] In the network architecture shown in (a) of Figure 1, each network element can communicate with each other through the interfaces shown in the figure. As shown in the figure, the UE and AMF can interact through the N1 interface, and the interaction message can be called an N1 message. The RAN and AMF can interact through the N2 interface, and the N2 interface can be used for sending non-access stratum (NAS) messages, etc. The RAN and UPF can interact through the N3 interface, and the N3 interface can be used to transmit user plane data, etc. The SMF and UPF can interact through the N4 interface, and the N4 interface can be used to transmit information such as tunnel identification information of the N3 connection, data cache indication information, and downlink data notification messages. The UPF and DN can interact through the N6 interface, and the N6 interface can be used to transmit user plane data, etc. The relationship between other interfaces and each network element is shown in (a) of Figure 1. For the sake of brevity, they are not described in detail here.

[0116] As shown in Figure 1(b), this is a schematic diagram of a 5G network architecture based on a point-to-point interface. The functions of the network elements therein can be referred to the functions of the corresponding network elements in Figure 1(a), and will not be repeated here. The main difference between Figure 1(b) and Figure 1(a) is that the interfaces between the network elements in Figure 1(b) are point-to-point interfaces, rather than service-based interfaces.

[0117] In the architecture shown in Figure 1(b), the interface names and functions between the various network elements are as follows:

[0118] 1) N1: Interface between AMF and UE, used to deliver QoS control rules to UE.

[0119] 2) N2: The interface between AMF and RAN, used to transmit radio bearer control information from the core network side to the RAN.

[0120] 3) N3: Interface between RAN and UPF, used to transmit user plane data, etc.

[0121] 4) N4: The interface between SMF and UPF is used to transfer information between the control plane and the user plane, including the control of the forwarding rules, QoS control rules, traffic statistics rules, etc. for the user plane and the reporting of information on the user plane.

[0122] 5) N5: The interface between AF and PCF, used for issuing application service requests and reporting network events.

[0123] 6) N6: Interface between UPF and DN, used to transmit user plane data, etc.

[0124] 7) N7: The interface between PCF and SMF, used to deliver protocol data unit (PDU) session granularity and service data flow granularity control policy.

[0125] 8) N8: Interface between AMF and UDM, used by AMF to obtain access and mobility management related subscription data and authentication data from UDM, and AMF to register UE current mobility management related information with UDM.

[0126] 9) N9: The interface between UPFs, used to transmit uplink and downlink user data flows between UPFs.

[0127] 10) N10: Interface between SMF and UDM, used by SMF to obtain session management related subscription data from UDM, and SMF to register UE current session related information with UDM.

[0128] 11) N11: The interface between SMF and AMF, used to transfer PDU session tunnel information between RAN and UPF, transfer control messages sent to UE, transfer radio resource control information sent to RAN, etc.

[0129] 12) N12: Interface between AMF and AUSF, used by AMF to initiate the authentication process to AUSF, which can carry SUCI as the contract identifier;

[0130] 13) N13: Interface between UDM and AUSF, used by AUSF to obtain the user authentication vector from UDM to execute the authentication process.

[0131] 14) N15: Interface between PCF and AMF, used to deliver UE policies and access control related policies.

[0132] 15) N35: Interface between UDM and UDR, used by UDM to obtain user contract data information from UDR.

[0133] 16) N36: Interface between PCF and UDR, used by PCF to obtain policy-related contract data and application data-related information from UDR.

[0134] The solution of the embodiment of the present application can be applied to the network architecture described in Figure 2, which is a schematic diagram of the CAPIF architecture. It is understandable that the terms given below are illustrated using the current NR system as an example, but it should be understood that in other communication systems (such as the future sixth-generation communication system), the following terms may have other names, and this application does not limit this. The architecture shown in Figure 2 mainly includes the following network elements:

[0135] 1. API invoker, usually provided by a third-party application provider that has a service agreement with the operator network. The API invoker has the following functions: 1) Provide the API caller identity and other information required for API caller authentication to support authentication; 2) Support mutual authentication with the CAPIF core functional entity; 3) Obtain authorization before accessing the service API; 4) Discover service API information; 5) Call the service API. The API caller can be AF, UE, etc., or it can be a client and a third-party application on the UE. Among them, third-party applications refer to applications developed by non-operating systems or software developers, usually to provide additional functions or services on the operating system or other applications. For example, social media applications, music players, weather applications, etc. The location of the API caller in the communication network can be seen in the AF network element in Figure 1 (a) and Figure 1 (b). Among them, the functions (3), (4), and (5) of the API caller are related to the present invention.

[0136] 2. The CAPIF core function (CCF) entity is the central storage for service API policies and the center for authentication and authorization of API callers and service APIs. It has the following functions: 1) Authenticate API callers based on the identity and other information required for API caller authentication; 2) Support mutual authentication with API callers; 3) Provide authorization for API callers before accessing service APIs; 4) Publish, store, and support discovery of service API information; 5) Control service API access based on policies configured by PLMN operators; 6) Store service API call logs and provide service API call logs to authorization entities; 7) Bill based on service API call logs; 8) Monitor service API calls; 9) Add new API callers and remove API callers; 10) Store policy configurations related to CAPIF and service APIs; 11) Support access logs for auditing (e.g., detecting abuse); 12) Support the use of another CAPIF core function to publish and discover service API information during CAPIF docking. Among them, functions (1), (3), and (4) of the CAPIF core function entity are relevant to the present invention.

[0137] 3. The API exposing function (AEF) entity is an entry point for the service provider to open up its services to the outside world. API callers can use the services provided by the service provider through the AEF entity. The functions include: 1) authenticating the API caller based on the identity and other information required for API caller authentication provided by the CAPIF core function; 2) verifying the authorization provided by the CAPIF core function; 3) recording the service API calls of the CAPIF core function. In the 3GPP network, the AEF can be an NEF, that is, the location of the AEF in the communication network can be seen in the NEF network element in Figure 1(a). The NEF is an API interface that provides the operator network to the outside world and provides interaction between external service terminals and internal operator networks. It can be understood that because the service provider opens the service to the API caller through the service API on the AEF, the API caller generally calls the service API by sending a request to the AEF.

[0138] 4. The API publishing function entity enables API providers to publish APIs. It publishes service API information to the CAPIF core function entity so that API callers can find the service API information there. It should be noted that the API publishing function entity and the NEF can be co-located.

[0139] 5. The API management function entity performs management of the service API, such as monitoring the status of the service API, recording call information, etc. It should be noted that the API management function entity can be co-located with the NEF.

[0140] 6. The Authorization Function (AuF) entity is used to obtain user authorization. After the user authorizes, the client is authorized to access the authorization server of the user's data. It should be noted that the AuF entity can be co-located with the CCF entity.

[0141] 7. Resource Owner Client (RO Client): The application client used by the user can display the operation interface to the user. For example, the operating system, browser, etc. The RO Client can be the application on the UE in Figure 1(a) and Figure 1(b).

[0142] In Figure 2, a public land mobile network trust domain (PLMN trust domain) represents an area trusted by a public land mobile network. An API provider domain represents an area where an API provider is located.

[0143] The connection relationship between the above network elements is as follows:

[0144] The interface between the API caller outside the PLMN trust domain and the CAPIF core functional entity is the CAPIF-1e interface, the interface between the API caller and the AEF entity is the CAPIF-2e interface, and the interface between the API caller and the AuF entity is the CAPIF-10e interface. The interface between the API caller within the PLMN trust domain and the CAPIF core functional entity is the CAPIF-1 interface, the interface between the API caller and the AEF entity is the CAPIF-2 interface, and the interface with the AuF entity is the CAPIF-10 interface. The interface between the CAPIF core functional entity and the AEF entity is the CAPIF-3 interface, the interface between the API caller and the API publishing functional entity is the CAPIF-4 interface, and the interface between the API caller and the API management function is the CAPIF-5 interface. The interface between the AEF entity and the AuF entity is the CAPIF-9 interface, and the interface between the AEF entity and the RO Client is the CAPIF-8 interface.

[0145] To facilitate understanding of the embodiments of the present application, some of the terms involved in the present application are exemplified below.

[0146] 1. Application Programming Interface (API): This includes the following types: 1) CAPIF API, which provides some common API interfaces. CAPIF APIs are typically provided by the system or platform, providing API callers with an interface to the core CAPIF functional entities. 2) Service API: System components expose services to API callers by abstracting them from the underlying mechanisms. Services can be of any type, such as web services, cloud services, and database services. Service APIs are typically provided by service providers for accessing and using services, providing API callers with an interface to the API's exposed functional entities. 3) Authorization APIs are used to verify user identities and authorize user access to resources. Authorization APIs are typically provided by authentication and authorization systems to protect the security of applications and data, providing API callers with an interface to the authorization functional entity. These three types of APIs differ in their functionality. CAPIF APIs are general API frameworks used to implement various functions; service APIs are APIs used to access and use services; and authorization APIs are APIs used for authorization and authentication.

[0147] 2. Resource Owner (RO): The resource owner can be a 3GPP signatory, such as a user.

[0148] 3. Access Token: Access token is a key that the client can use to access user-authorized data on the resource server.

[0149] 4. Scope: Scopes are used to restrict the user data that API callers can access. For example, an application can request one or more scopes. The requested scope information is presented to the user on the screen, and the access token issued to the application is limited to the authorized scopes.

[0150] OAuth (Open Authorization) is an authorization protocol used to grant third-party applications access to a user's resources on another service provider without sharing the user's credentials. The main purpose of the OAuth protocol is to solve the problem of users having to provide their username and password when using third-party applications, thereby improving user privacy and security.

[0151] Open Authorization 2.0 (OAuth2.0) is the next generation version of the OAuth protocol. It can be used to authorize third-party applications, also known as "clients" (third-party applications, clients, etc. are all API callers) to obtain user resources. Among them, the client refers to the application that needs to access user resources, and the user is the owner of the resources. For example, the user can decide whether to authorize the third-party application to access his resources on a certain service provider (such as user basic information, photos, videos, etc.). The authorization of OAuth2.0 can be understood as the process of the API caller obtaining an access token (access_token). The API caller must be authorized to obtain an access token. The authorization types defined by OAuth2.0 are as follows:

[0152] 1. Client Credential Grant: The client uses the client's identity information to request an access token from the authentication server. It is suitable for situations where the client needs to access the client's resources without user participation.

[0153] 2. Authorization Code Grant: The client requests authorization from the authentication server, the authentication server requests authorization from the user, and after the user agrees to the authorization, the authentication server sends the authorization code to the client, and the client then uses the authorization code to request an access token from the authentication server.

[0154] 3. Implicit Grant: The client directly requests an access token from the authentication server, omitting the authorization code step. This is suitable for situations where the client cannot keep the authorization code confidential. The token is visible to the visitor and the client does not need to authenticate.

[0155] 4. Resource Owner Password Credentials Grant: The client uses the user's username and password to request an access token from the authentication server. It is suitable for situations where the client and user have high trust and the number of users is small.

[0156] 5. Extended Authorization: Extensions to authorization methods, such as Proof Key for Code Exchange (PKCE), enhance the aforementioned authorization code authorization to prevent authorization code attacks. Authorization code attacks are a common network attack in which attackers steal authorization codes and use them to obtain access tokens, thereby obtaining private user information.

[0157] Among them, implicit authorization and resource owner password authorization have relatively low security. Here we introduce three authorization methods under CAPIF: client credential authorization (Figure 3), authorization code authorization (Figure 4), and PKCE (Figure 5).

[0158] The Transport Layer Security (TLS) protocol protects network communications in several ways:

[0159] 1. TLS-PSK (Pre-Shared Key) is a TLS implementation based on pre-shared keys. During the TLS handshake, the client and server use a pre-shared key for authentication and key exchange. This method is suitable for scenarios where only a few trusted devices need to communicate, such as communication between IoT devices.

[0160] 2. TLS-PKI (Public Key Infrastructure) is a TLS implementation based on public key infrastructure. During the TLS handshake, digital certificates are used between the client and server for authentication and key exchange. This approach is suitable for scenarios requiring large-scale communication, such as websites and mobile applications.

[0161] 3. TLS with OAuth tokens is a TLS implementation based on the OAuth protocol. During the TLS handshake, the client uses an OAuth token for authentication, and the server uses a digital certificate for authentication and key exchange. This approach is suitable for scenarios requiring secure API calls, such as mobile applications and cloud services.

[0162] The following describes the client credential grant (client_credential grant) method under CAPIF, combining the steps shown in Figure 3. This method implements the process by which the CCF authorizes an API caller to call a specific API from the AEF. Client credential grant can be understood as the API caller requesting an access token from the CCF using their identity information. Client credential grant is a grant type used in the TLS with OAuth token authentication method.

[0163] Step 301: The API caller sends an API caller registration request (Onboard API Invoker Request) message to the CCF. The API caller registration request message is used to register the API caller with the CCF.

[0164] The API caller registration request message includes onboarding information and enrollment APIs. The onboarding information includes the API caller's information. The enrollment APIs include a list of APIs to be registered. The enrollment APIs can be understood as the API caller sending CCF pre-configured criteria for discovering certain service APIs when registering with the CCF.

[0165] Step 302: The CCF sends an Onboard API Invoker Response message to the API caller.

[0166] The API caller registration response message includes the registration status, registered information, and service API information. The registration status is used to indicate the result of the registration, such as success or failure. The registered information includes the API caller ID and the authentication method. The API caller ID is assigned to the API caller by the CCF, and the authentication method indicates the authentication method used by subsequent API callers. The authentication method includes one or more of the TLS-PSK method, TLS-PKI method, and TLS with OAuth token method. The service API information is used to indicate the registered API information, which includes the service API identifier, AEF location, IP address, port number, protocol, etc.

[0167] Step 303: The API caller sends a service discovery request message to the CAPIF core function entity. The service discovery request message is used to request the discovery service API.

[0168] The service discovery request includes the API caller ID and request information, wherein the request information includes the criteria for discovering certain APIs, which may be information preferred by the API caller, such as the API caller's preferred AEF location, preferred protocol, etc.

[0169] Step 304: CCF sends a service discovery response (Discovery Service Response) message to the API caller.

[0170] The service discovery response message includes service API information, which CCF obtains based on the request information sent by the API caller in step 303. The service API information includes the service API identifier, AEF location, IP address, port number, protocol, etc.

[0171] It should be noted that the service API information sent by CCF in step 302 may be the pre-configured default service API information obtained based on the API registration in step 301 , and the service API information sent by CCF in step 304 may be the service API information obtained based on the request information in step 303 .

[0172] In step 305, the API caller sends an Obtain Authorization Request message to the CCF. The Obtain Authorization Request message is used by the API caller to request the CCF to authenticate its identity and obtain an access token.

[0173] It should be noted that, in step 302, when the authentication method sent by the CCF to the API caller is the TLS with OAuth token method, the API caller sends an authorization request message to the CCF.

[0174] The authorization request message includes the API caller ID and the identifier of the service API.

[0175] Step 306: After the CCF confirms that the API caller can be authorized to access the service API, it sends an Obtain Authorization Response message to the API caller.

[0176] CCF confirms that the API caller can be authorized to access the service API. It can be understood that when CCF verifies that the API caller ID and the identifier of the service API are both valid, CCF authorizes the API caller to access the service API. Valid means that the API caller ID is the same as the API caller ID received by CCF in step 304, and the identifier of the service API is the same as the identifier of the service API issued by CCF to the API caller in step 304. The authorization response message includes an access token (access_token). The access token is used to authorize the API caller to access a specific service API. Optionally, the authorization response message also includes an update token (refresh_token), which is used to authorize the API caller to update the access token. The update token and the access token include a statement and a signature. The statement includes the following contents: timeout period, API caller ID, identifier of AEF, and identifier of service API. The signature is the digital signature of CCF on the token. Optionally, the statement also includes a user identifier.

[0177] It should be noted that the timeout period in the token can be used to limit the time that the user grants the API caller to access user resources through specific AEFs and service APIs. That is to say, if the "timeout period" is exceeded, it means that the access token has expired. At this time, you need to use the update token to apply for a new access token.

[0178] Step 307: The API caller sends a service API invocation request message to the AEF.

[0179] The service API call request message includes the API caller ID, the service API identifier, and an access token. The access token includes a declaration and a signature, and the access token is obtained by the API caller in step 306. Optionally, the service API call request message also includes a user identifier.

[0180] It is understandable that, because the service provider opens the service to the API caller through the service API on the AEF, the API caller generally calls the service API by sending a request to the AEF.

[0181] Step 308: The AEF verifies the access token in the service API call request message.

[0182] For example, AEF verifies the declaration and signature in the access token. AEF verifies the signature of the access token: AEF verifies the signature of the access token through the pre-configured CCF authentication credentials (such as a certificate). AEF verifies the declaration of the access token: AEF determines whether the API caller ID in the declaration of the access token is consistent with the API caller ID in the message, and determines whether the identifier of the service API in the declaration of the access token is consistent with the identifier of the service API requested in the message. Optionally, when the call request message also includes a user identifier, AEF also determines whether the user identifier in the declaration of the access token is consistent with the user identifier requested in the message. And AEF determines whether the current access token has timed out based on the timeout period.

[0183] If the signature and declaration of the access token are verified, the AEF executes step 309. Otherwise, the API call request is rejected.

[0184] Step 309: The AEF sends a Service API Invocation Response message to the API caller.

[0185] If the AEF verifies the access token successfully, the API call response message indicates that the service API call is successful. Otherwise, the API call response message indicates that the service API call fails.

[0186] The main difference between Figure 4 and Figure 3 is that the authorization process in Figure 4 involves the participation of the user, which can prevent the API caller from directly obtaining the access token without user authorization and then obtaining user data. In conjunction with the various steps in Figure 4, the authorization code grant method under CAPIF is introduced to implement the process of CCF authorizing the API caller to call a specific API to AEF. The authorization code authorization method can be understood as the API caller obtaining an authorization code under the condition of user authorization, and then using the authorization code to obtain the access token. Among them, the authorization code authorization is a type of authorization in the transport layer token (TLS with OAuth token) authentication method.

[0187] Step 401: The API caller sends an authorization code request message to the Resource Owner client (RO client).

[0188] The authorization code request is used by the API caller to request the RO client to obtain an authorization code from the authorization function (AuF). The authorization code request includes the API caller ID, scope, and redirect Uniform Resource Locator (redirect URL). Optionally, it also includes the AuF identifier. The scope is used to indicate the scope of authorized authorization, which can be represented by parameters in the API request message, such as API identifier, API ID, API input parameters, etc. It should be noted that the scope is used to define the scope of the API caller's access to user resources. The API caller can request one or more scopes, and the RO (user) can reject or accept the scope requested by the API caller. The access token obtained by the API caller will contain the scope of the user's ultimate permission for the API caller to access user resources, so the access token can only be used to access resources within its scope. The redirect URL is used to return the address of the authorization code, and the address of the authorization code usually indicates the API caller address. The AuF identifier is used to indicate the AuF address.

[0189] In step 402, the RO client sends an authorization request message to the AuF. The authorization request message is used to request an authorization code.

[0190] The authorization request message includes the response type, API caller ID, redirect URL, and scope. The response type is "code," indicating that the authorization type is an authorization code authorization. The API caller ID, redirect URL, and scope are obtained from the API caller in step 401.

[0191] Optionally, when the authorization request in step 401 includes the identifier of the AuF, the RO client determines the address of the AuF according to the identifier of the AuF, and then sends the authorization request message to the AuF.

[0192] Step 403: The RO agrees to the relevant authorization to the AuF.

[0193] The RO can be understood as the user. One implementation method is for the AuF to send an authorization query to the RO Client based on the scope. For example, if the scope indicates that the API can obtain location information, the AuF sends an authorization query to the RO Client. This query can be encapsulated using the Hypertext Transfer Protocol (HTTP) protocol and ultimately parsed by the RO Client as a message containing "Do you agree to allow the API caller to access your location information?" The user can click "Agree" or "Disagree." If the user agrees, the RO Client sends the consent result back to the AuF, thus obtaining the RO's authorization.

[0194] Optionally, after the RO client and AuF complete the authentication for the RO, the RO agrees to the relevant authorization to the AuF.

[0195] For example, the RO client can authenticate with the AuF using HTTP-based username and password. The RO enters a pre-registered username and password in the RO client, and the AuF verifies that the username and password are the same as those stored in the database. If they are the same, the RO is authenticated.

[0196] Step 404: AuF sends an authorization response message to the RO client.

[0197] After AuF obtains authorization from RO, AuF sends an authorization response message to RO client, which includes an authorization code and a redirect URL.

[0198] It can be understood that the AuF sends the authorization code to the API caller through the RO client, and the address of the API caller is the redirect URL in the authorization request message sent by the API caller in step 401.

[0199] Step 405: The RO client sends an authorization code to the API caller.

[0200] The address of the API caller is the redirect URL received by the RO client in step 404 .

[0201] Step 406: The API caller sends a token request message to the CCF to request a token.

[0202] The token request message includes the grant type, authorization code, and redirect URL. The grant type is "authorization code grant (authorization_code)". The authorization code is obtained by the API caller in step 405. The redirect URL indicates the address of the API caller.

[0203] Step 407: CCF requests AuF to verify the authorization code of the API caller. AuF verifies the authorization code and returns the verification result.

[0204] The AuF verifies whether the authorization code and redirect URL sent by the CCF are the same as the authorization code and redirect URL sent by the AuF to the RO client in the authorization response message in step 404. If they are the same, the authorization code verification passes and the process proceeds to step 408. If they are different, the authorization code verification fails is returned.

[0205] Step 408: If the authorization code verification is successful, the CCF sends a token response message to the API caller.

[0206] The token response message includes an access token and, optionally, a refresh token. This refresh token is used to obtain the next access token. This eliminates the need for the user to re-authorize when the access token needs to be updated, thus reducing the need for frequent authorization.

[0207] It should be noted that the access token includes scope and signature. The scope can represent the scope of user resources that the user grants to the API caller. For example, the user can use the scope to restrict the API caller to only access the user name, avatar, etc.

[0208] Step 409: The API caller sends an API request message to the AEF.

[0209] The API request message includes an access token, which is used to request the AEF to call the relevant API.

[0210] In step 410 , the AEF sends an API response message to the API caller.

[0211] Before sending the API response, the AEF verifies the access token's signature and scope. For example, the AEF verifies the access token's signature using pre-configured CCF authentication credentials (e.g., a certificate). For example, the AEF verifies the scope of the access token to see if the scope in the access token falls within the user's permitted access range. If both the access token signature and scope verification pass, the API caller is authorized to access the user's resources through the API response.

[0212] The difference between Figure 5 and Figure 4 is that Figure 5 uses OAuth 2.0's PKCE to implement authorization. PKCE can be understood as the API caller adding a random string (called code_verifier) ​​to the authorization request and using the hash value of the string (called code_challenge) in the authorization code request to verify the legitimacy of the authorization code. In this way, even if an attacker steals the authorization code, the authorization code cannot be used to obtain an access token because the attacker cannot provide the correct code_verifier. Combined with the various steps in Figure 5, the PKCE method under CAPIF is introduced to implement the process of CCF authorizing API callers to AEF to call specific APIs. Among them, PKCE is an authorization type in the transport layer token (TLS with OAuth token) authentication method.

[0213] In step 501, the API caller sends an authorization code request message to the resource owner client (RO client). For details, please refer to the above step 401.

[0214] The difference from step 401 is that the authorization code request message sent by the API caller to the RO client also includes a challenge value (code_challenge) and a security method (code_challenge_method). The API caller first generates a verification value (code_verifier) ​​and generates a code_challenge based on the code_verifier and code_challenge_method.

[0215] code_verifier can be a random number. code_challenge can be generated using code_verifier and code_challenge_method in any of the following ways:

[0216] 1) code_challenge and code_verifier are the same, in which case the security method is null (represented by plain).

[0217] 2) Performing a hash operation on code_verifier to generate code_challenge, for example, code_challenge_method is Secure Hash Algorithm (SHA) 256 (denoted by S256).

[0218] Wherein, code_challenge_method is used to indicate the security method for generating code_challenge. Exemplarily, the security method may include null and SHA256.

[0219] In step 502, the RO client sends an authorization request message to the AuF. The authorization request message is used to request an authorization code. For details, please refer to step 402 above.

[0220] The difference from step 402 is that the authorization request message also includes code_challenge and code_challenge_method. Upon receiving the authorization code, the AuF stores the associated authorization code, code_challenge, and code_challenge_method. This associated storage stores the correspondence between the authorization code, code_challenge, and code_challenge_method. For example, the AuF can subsequently determine the corresponding code_challenge and code_challenge_method based on the received authorization code.

[0221] Steps 503 to 505 are the same as the above-mentioned steps 403 to 405 and will not be repeated here.

[0222] In step 506, the API caller sends a token request message to the CCF to request a token. For details, please refer to step 406 above.

[0223] The difference from step 406 is that the token request message sent by the API caller to the CCF also includes code_verifier.

[0224] In step 507, CCF requests AuF to verify the authorization code and code_verifier of the redirect URL. AuF verifies the authorization code and code_verifier and returns the verification result. For the specific steps of the authorization code verification, please refer to the above step 407.

[0225] The difference from step 407 is that the AuF can obtain the code_challenge and code_challenge_method corresponding to the authorization code based on the authorization code and the association stored in step 502. Furthermore, the AuF can generate a code_challenge based on the received code_verifier and the stored code_challenge_method. The generated code_challenge is verified to be consistent with the code_challenge stored in step 502. If both the authorization code and code_verifier are verified, the AuF instructs the CCF to send a token to the API caller and proceed to step 508. Otherwise, the AuF returns a verification failure. Steps 508-510 are the same as steps 408-410 above and are not repeated here.

[0226] Figures 3-5 introduce three OAuth authorization methods under CAPIF (client credential authorization, authorization code authorization, and PKCE) to implement authorization for API callers. However, the above authorization methods do not take into account the support and negotiation of different authorization methods for the service API by the API caller and AEF itself.

[0227] In light of this, method 600 provides a method for integrating multiple OAuth authorization methods with the CAPIF API publishing process. When an API caller calls a service API from an AEF, the API caller uses different methods based on its capabilities and the service API authorization method. This method is described below with reference to Figure 6.

[0228] Step 601: The API publishing function sends a service API publishing request message to the API information function. Correspondingly, the API information function receives the service API publishing request message from the API publishing function. The service API publishing request message is used to publish a service API.

[0229] It should be noted that the API information functional entity in this application is used to support the discovery of service API information and provide authorization for API callers before accessing the service API. Exemplarily, the API information functional entity can be a CAPIF core function entity (CAPIF core function, CCF).

[0230] The service API publish request message includes the identifier of the service API and the first information. Among them, the identifier of the service API can be API ID, API name, URL, IP address and port number, etc. The first information includes the authorization type, which is the authorization type corresponding to the service API, and is used to indicate the authorization method of the service API. It can be understood as a way to authorize API callers to access user resources, and it can also be understood as the API caller using the authorization method to obtain user resources indicated by the service API. The authorization type can be an OAuth authorization type, which is used to indicate different authorization types of OAuth, and can include one or more of authorization code grant, client credential grant, implicit grant, resource owner password credentials grant and extended authorization. Exemplarily, the extended authorization may include a Proof Key for Code Exchange (PKCE) for authorization code exchange.

[0231] It should be noted that, in method 600, the first information may be service API information.

[0232] Optionally, the service API information also includes the identifier, scope, and one or more of the PKCE security methods of the Authorization Function (AuF). The AuF may be the authorization function entity in FIG2 , and the AuF identifier is used to indicate the address of the AuF. Exemplarily, the AuF's Uniform Resource Locator (URL) may be indicated.

[0233] The scope is used to indicate the scope of authorization allowed by the service API, which can be understood as the scope of resources that can be accessed using the service API. It can be represented by parameters in the API request message, such as API identifier, API ID, API input parameters, etc. For example, if the scope indicates that the service API can obtain user location information, the AuF allows the API caller to access the user's location information through the service API.

[0234] The PKCE security method indicates the method for generating the code_challenge, which is used to verify the identity of the API caller. The PKCE security method can include secure methods for generating the code_challenge, such as null (represented by plain) and SHA256 (represented by S256). The specific steps for generating the code_challenge can be referred to in step 501 above and will not be repeated here.

[0235] It should be noted that, when the authorization type is PKCE, the service API information may include the AuF identifier, scope, and PKCE security method.

[0236] When the authorization type is authorization code authorization, the service API information may include the AuF identifier and scope. It is understood that when the authorization type is authorization code authorization, the service API information may not include the PKCE security method. It should be noted that the AuF and API information functional entities can be co-located. When the AuF and API information functional entities are co-located, the AuF identifier may not be used to indicate the AuF address, that is, the service API information may not include the AuF identifier.

[0237] In one possible implementation, the service API publishing request message includes identifiers of multiple service APIs and service API information corresponding to each service API identifier. For example, for different service APIs, there may be the following types of service API information:

[0238] 1. API ID1: The service API information includes the authorization type corresponding to API ID1, which is authorization code authorization. The service API information also includes the AuF identifier and scope.

[0239] 2. API ID 2: The service API information includes the authorization type corresponding to API ID 2, which is PKCE. The service API information also includes the AuF identifier, scope, and PKCE security method.

[0240] 3. API ID3: The service API information includes the authorization type corresponding to API ID3, which is client credential authorization.

[0241] 4. API ID 4: The service API information includes the authorization type corresponding to API ID 4, which is authorization code authorization and PKCE. The service API information also includes the AuF identifier, scope, and PKCE security method.

[0242] 5. API ID5: The service API information includes the authorization type corresponding to API ID5, which is client credential authorization and PKCE. The service API information also includes the AuF identifier, scope, and PKCE security method.

[0243] Step 602: The API information function entity sends a service API publish response (Service API Publish Response) message to the API publish function entity.

[0244] The Service API Publish Response message includes a Result and a Service API Published Information Reference. The Result indicates whether the Service API information was published successfully or unsuccessfully. The Service API Published Information Reference is used by the API Publisher to locate the published Service API.

[0245] It is understandable that if the API information functional entity receives the above-mentioned API information and stores it successfully or determines that the API information can be stored, the result is used to notify the API publishing functional entity that the API information is successfully published; otherwise (for example, due to limited configuration permissions, etc.), the result is used to notify the API publishing functional entity that the API information fails to be published. Among them, successful storage can be that the API information functional entity has stored the API information. Determining that the API information can be stored, for example, the API information functional entity determines whether the API information is allowed to be stored based on the configuration permissions, and determines that the API information can be stored if the configuration permissions allow.

[0246] Step 603: The API information functional entity stores the service API information, wherein the service API information is the parameters received by the API information functional entity through the service API publishing request message in step 601.

[0247] Exemplarily, corresponding to the first information received in step 601, the API information function entity may store the first information corresponding to different API IDs in the following manner:

[0248] 1. API ID1: The API information functional entity associates and stores the API ID1, authorization code authorization, AuF identifier, and scope. This association storage can be understood as the API information functional entity being able to determine the first information using the API ID. For example, the API ID and the first information can be stored as a corresponding relationship. Alternatively, the API ID and the first information can be stored separately, and an index established between the API ID and the first information. For example, the API ID1 can be used to subsequently determine the authorization code authorization, AuF identifier, and scope corresponding to the API.

[0249] 2. API ID2: The API information functional entity stores the API ID2, PKCE, AuF identifier, scope, and PKCE security method together.

[0250] 3. API ID3: The API information functional entity stores the API ID3 and client credential authorization in an associated manner.

[0251] 4. API ID4: The API information functional entity stores the API ID4, authorization code authorization, PKCE, AuF identification, scope, and PKCE security method together.

[0252] 5. API ID5: The API information functional entity stores the API ID5, client credential authorization, and PKCE, AuF identifiers, scopes, and PKCE security methods together.

[0253] It should be noted that there is no restriction on the order in which the API information functional entity sends the service API release response message in step 602 and the API information functional entity stores the service API information in step 603. It is understandable that the API information functional entity can also store the service API information first and then send the service API release response message.

[0254] Step 604: The API caller sends an API caller registration request (Onboard API Invoker Request) message to the API information function entity. The API caller registration request message is used to register the API caller to the API information function entity.

[0255] For the description of the API caller registration request, please refer to the description of step 301 and will not be repeated here.

[0256] Optionally, the API caller registration request message includes the capability information of the API caller, which is used to indicate the calling methods supported by the API caller. The capability information includes the OAuth authorization types supported by the API caller, and optionally, may also include the PKCE security methods supported by the API caller. Among them, the OAuth authorization type is used to indicate different authorization types of OAuth, which may include one or more of authorization code authorization, client credential authorization, implicit authorization, resource owner password authorization, and extended authorization (such as PKCE). The PKCE security method includes a security method for generating code_challenge, which may include null (represented by plain), SHA256 (represented by S256), etc.

[0257] The API caller's capability information may also include supported authentication methods, such as TLS-PSK, TLS-PKI, and TLS with OAuth token.

[0258] For example, the API caller's capability information includes TLS with OAuth token authentication method and authorization code authorization. Another example is that the API caller's capability information includes TLS with OAuth token authentication method, authorization code authorization and PKCE, and SHA256 method.

[0259] For example, the capability information of the API caller can be represented using the following table:

[0260] Table 1 Supported security methods

[0261] Or it can be represented using the following table:

[0262] Table 2 Supported security methods

[0263] It is worth noting that the first two rows in Table 1 are the existing design. The third row can improve the readability of the security method by expanding the sub-keys to clarify the cluster relationship of the sub-security methods.

[0264] It's worth noting that the first three rows in Table 2 represent the existing design. Row 3 defaults to support OAuth client credentials grant. The last three rows include both OAuth grant types and PKCE security methods. This maintains backward compatibility with legacy methods without changing the data types of the existing security methods, and expands security methods to support more fine-grained capability negotiation.

[0265] In one possible method, the capability information of the API caller includes authorization code authorization. Then the capability information of the API caller can be represented by row 4 in Table 1 or row 6 in Table 2.

[0266] In another possible method, the API caller's capability information includes client credential authorization and authorization code authorization. The API caller's capability information can be represented using rows 3 and 4 in Table 1, or rows 3 and 6 in Table 2.

[0267] In another possible approach, the API caller's capability information includes TLS with OAuth token authentication method, authorization code authorization and PKCE (supported OAuth authorization types), and SHA256 method (supported PKCE security method). The API caller's capability information can be represented using rows 4 and 6 of Table 1, or rows 5 and 6 of Table 2.

[0268] For example, when the API caller is ready to register with the API information function entity, step 604 may be executed.

[0269] Step 605: The API information function entity replies to the API caller with an Onboard API Invoker Response message.

[0270] The API caller registration response message includes the registration status, registered information, and service API information. The registration status is used to indicate the result of the registration, such as success or failure. The registered information includes the API caller ID and the authentication method. The API caller ID is assigned to the API caller by the API information function entity, and the authentication method indicates the authentication method used by subsequent API callers. The authentication method includes one or more of the TLS-PSK method, TLS-PKI method, and TLS with OAuth token method. The service API information is used to indicate the registered API information. The service API information includes the service API identifier, AEF location, IP address, port number, protocol, etc.

[0271] Step 606: The API caller sends a service discovery request message to the API information function entity. The service discovery request message is used to request discovery of a service API.

[0272] For the description of the discovery service request, please refer to the description of step 303 and will not be repeated here.

[0273] Optionally, the service discovery request message may further include capability information of the API caller. For the capability information of the API caller, reference may be made to the description of step 604 .

[0274] For example, when the API caller is ready to discover the service API, step 606 may be executed.

[0275] Step 607: The API information function entity obtains method information.

[0276] The API information functional entity obtains method information based on the authorization type, where the authorization type is the authorization type corresponding to the service API, and the method information is used to determine the calling method of the service API.

[0277] Optionally, the API information functional entity may directly use the authorization type corresponding to the service API as the method information.

[0278] For example, the API information functional entity obtains the stored service API information according to the service API standard, and then uses the authorization type in the stored service API information as the method information.

[0279] Exemplarily, the API information functional entity obtains API ID1 according to the service API standard and obtains the service API information corresponding to API ID1, including the associated authorization type, namely authorization code authorization. The API information functional entity uses the authorization code authorization as method information.

[0280] Exemplarily, the API information functional entity obtains API ID 4 according to the service API standard and obtains the service API information corresponding to API ID 4, including the associated authorization type, namely authorization code authorization and PKCE. The API information functional entity uses the authorization code authorization and PKCE as method information.

[0281] Optionally, the API information function entity selects method information based on capability information and authorization type. The capability information is used to indicate the authorization type supported by the API caller.

[0282] For example, the API information functional entity obtains the stored service API information according to the service API standard, and then selects method information according to the capability information of the API caller and the authorization type in the stored service API information.

[0283] Exemplarily, the API information functional entity obtains API ID 1 based on the service API standard and obtains the service API information corresponding to API ID 1, including the associated authorization type, namely, authorization code authorization. The capability information indicates that the API caller supports authorization code authorization. The API information functional entity selects authorization code authorization as the method information based on the mutually supported method.

[0284] Exemplarily, the API information functional entity obtains API ID 4 according to the service API standard and obtains the service API information corresponding to API ID 4, including the associated authorization types, namely, authorization code authorization and PKCE. The capability information indicates that the API caller supports both client credential authorization and authorization code authorization. The API information functional entity selects authorization code authorization as the method information based on the mutually supported method.

[0285] Exemplarily, the API information functional entity obtains API ID 5 according to the service API standard and obtains the service API information corresponding to API ID 5, including the associated authorization type, namely, client credential authorization and PKCE. The capability information indicates that the API caller supports client credential authorization and PKCE. The API information functional entity selects client credential authorization and PKCE as the method information based on the mutually supported methods.

[0286] Exemplarily, the API information functional entity obtains API ID 4 based on the service API standard and obtains the service API information corresponding to API ID 4, including the associated authorization types, namely, authorization code authorization and PKCE. The capability information indicates that the API caller supports authorization code authorization and PKCE. The API information functional entity selects the more secure PKCE as the method information based on the mutually supported methods and the priority list.

[0287] Exemplarily, the API information functional entity obtains API ID 2 according to the service API standard and obtains the service API information corresponding to API ID 2, including the associated authorization type, namely, PKCE. The capability information indicates that the API caller supports authorization code authorization. Since both parties do not have a mutually supported method, the API information functional entity fails to select the method information and returns a failure indication.

[0288] Optionally, when the API caller supports PKCE, the API caller's capability information may also include the PKCE security method supported by the API caller. After the API information functional entity determines that the method information is PKCE according to the above method, the API information functional entity determines the PKCE security method based on the PKCE security method supported by the API caller and the PKCE security method in the stored service API information.

[0289] For example, the API information functional entity obtains the stored service API information according to the service API standard, and then selects the PKCE security method according to the PKCE security method supported by the API caller and the PKCE security method in the stored service API information.

[0290] Exemplarily, the API information functional entity obtains API ID 4 based on the service API standard and selects PKCE as the method information, referring to the above method. The PKCE security methods corresponding to API ID 4 include null and SHA256. The PKCE security methods supported by the API caller include SHA256. The API information functional entity selects SHA256 as the confirmed PKCE security method based on the mutually supported methods.

[0291] Exemplarily, the API information functional entity obtains API ID 4 based on the service API standard and selects PKCE as the method information, referring to the above method. The PKCE security methods corresponding to API ID 4 include null and SHA256. The API caller's supported PKCE security methods include null and SHA256. The API information functional entity selects the more secure SHA256 as the final PKCE security method based on the mutually supported methods and the priority list.

[0292] The capability information of the API caller may be obtained by the API information function entity from step 604 or step 606 .

[0293] Step 608: The API information function entity sends a service discovery response message to the API caller.

[0294] The service discovery response message includes method information. It is understood that this method information is associated with an authorization type. The authorization type corresponds to the service API. This method information is used to determine the calling method for the service API. This method information includes one or more of client credential authorization, authorization code authorization, and a proof key (PKCE) for authorization code exchange. The method information is determined according to the method in step 607.

[0295] Optionally, the service discovery response message also includes the AuF identifier, scope, and one or more of the determined PKCE security methods. It should be noted that the AuF identifier and scope are the same as the AuF identifier and scope received in step 601. The determined PKCE security method may be the same as the PKCE security method received in step 601, or may be obtained according to the method in step 607.

[0296] Optionally, when the OAuth authorization type is client credentials authorization, the service API information sent by the API information function entity may not include the OAuth authorization type. It is understood that when the service API information does not include the OAuth authorization type, the default OAuth authorization type is client credentials authorization.

[0297] Exemplarily, the API information function entity determines corresponding method information for different service API identifiers based on the association between the API ID and the service API information stored in step 603. The service discovery response includes the following information:

[0298] 1. API ID1: Method information includes authorization code, AuF identifier, and scope.

[0299] 2. API ID4: Method information includes authorization code authorization and PKCE, AuF identification, scope, and PKCE security method is SHA256.

[0300] Step 609: The API caller requests an access token for calling the service API from the API information function entity according to the method information.

[0301] The method information is the method information received by the API caller from the API information function entity. This method information may include multiple calling methods, such as client credential authorization, authorization code authorization, and proof key for authorization code exchange (PKCE). This method information corresponds to the API ID and can be used to determine the calling method of the service API. The access token is used to authorize the API caller to access a specific service API.

[0302] When the API caller receives a method information sent from the API information function entity, the method information can be determined as the calling method of the service API.

[0303] Optionally, when the service discovery response message in step 608 does not include method information, the API caller determines that the calling method of the service API is client credential authorization.

[0304] For example, if the API caller receives API ID 1 and the method information is authorization code authorization, the API caller determines that the calling method of API ID 1 is authorization code authorization.

[0305] When an API caller receives multiple method information sent from an API information function entity, it can select one of the calling methods from the method information according to the local policy, that is, use one of the method information as the calling method of the service API. Among them, the local policy can be used to indicate the priority of different calling methods. For example, the local policy can be in the form of a priority list of different calling methods, or a calling method that is preferred when certain conditions are met. For example, a specific API gives priority to PKCE, which is not limited in this embodiment. For example, the priority list can be PKCE, authorization code authorization, and client credential authorization, which means that when the three calling methods of PKCE, authorization code authorization, and client credential authorization exist at the same time, PKCE takes precedence over authorization code authorization, and authorization code authorization takes precedence over client credential authorization.

[0306] For example, the API caller receives API ID 4 and the method information is authorization code authorization and PKCE, then the API caller determines that the calling method of API ID 4 is PKCE according to the priority list.

[0307] When the calling method is the client credentials authorization method, the API caller requests an access token for calling the service API from the API information function entity, and the subsequent API caller uses the access token to call the service API from the AEF entity.

[0308] The calling step includes: the API caller sends an Obtain Authorization Request message to the API information function entity (same as the above step 305), and the subsequent process is the same as steps 306 to 309 in method 300.

[0309] When the calling method is the authorization code authorization method, the API caller obtains the first authorization code and uses the first authorization code to request an access token for calling the service API from the API information function entity. Subsequent API callers use the access token to call the service API from the AEF entity.

[0310] The calling step includes: the API caller sends an authorization code request message to the RO client (same as step 401 above), and the subsequent process is the same as steps 402 to 410 in method 400. For example, the API caller obtains API ID1 from the API information function entity in step 608, and the API ID1 determined by the API caller corresponds to the authorization code authorization method.

[0311] Optionally, the API caller receives an identifier for an authorization function (AuF) from the API information function entity. The AuF identifier is used to indicate the address of the AuF. When the calling method is an authorization code authorization method, a first authorization code is requested from the AuF based on the AuF identifier. Optionally, the API caller receives a scope from the API information function entity. The API caller determines whether the scope includes the scope used by the API caller when requesting an access token for calling the service API. The scope indicates the scope of authorization permitted by the service API. It should be noted that the AuF identifier and scope are obtained according to step 608.

[0312] For example, the API caller obtains the scope of the current request through the user request, such as requesting location information. The API caller also obtains the allowed scope of requesting avatar information through step 608. The API caller then determines that the current request exceeds the allowed scope and rejects the API call.

[0313] For example, the API caller obtains the scope of the current request through the user request, such as requesting location information. The API caller also obtains the allowed scope of requesting location information and avatar information through step 608. The API caller then determines that the current request belongs to the allowed scope and continues to execute the calling method.

[0314] When the calling method is the PKCE method, the API caller obtains the second authorization code and code_verifier, and uses the second authorization code and code_verifier to request an access token for calling the service API from the API information function entity. Subsequent API callers use the access token to call the service API from the AEF entity.

[0315] The calling process includes: the API caller sends an authorization code request message to the RO client (same as step 501 above). The subsequent process is the same as steps 502-510 in method 500. Optionally, the AuF ID and range are obtained according to step 608. Optionally, the API caller also determines whether the currently requested range falls within the range obtained from the API information function entity. The code_verifier is generated by the API caller and can be a random number. The API caller can generate a code_challenge based on the code_verifier and the determined PKCE security method.

[0316] Exemplarily, code_verifier can be a random number, the PKCE security method is null, and the API caller generates code_challenge based on code_verifier and the null method. In this case, code_challenge is the same as code_verifier.

[0317] Exemplarily, code_verifier can be a random number, the PKCE security method is SHA256, and the API caller generates code_challenge based on code_verifier and the SHA256 method. In this case, code_challenge is a hash value of code_verifier.

[0318] Optionally, the API caller receives an identifier of the authorization function AuF from the API information function entity. The identifier of AuF is used to indicate the address of AuF. When the calling method is the PKCE method, the API caller requests a second authorization code from AuF based on the identifier of AuF. Optionally, the API caller receives a scope from the API information function entity. The API caller determines whether the scope includes the scope used when the API caller requests the access token for calling the service API. The scope is used to indicate the scope that the service API allows to be authorized. Optionally, the API caller receives a PKCE security method from the API information function entity. When the calling method is the PKCE method, the API caller obtains a second authorization code and code_verifier. The API caller generates a code_challenge based on the code_verifier and the PKCE security method. The code_challenge is used to verify the identity of the API caller. It should be noted that the identifier, scope and PKCE security method of AuF are obtained according to step 608.

[0319] Through the process of method 600, the publication and use of authorization-related information at the API level is implemented under the CAPIF architecture. Thus, the API publishing functional entity can publish the service APIs it supports and the corresponding first information to the API information functional entity. API callers can obtain the first information of the service APIs from the API information functional entity, thereby enabling API callers to automatically adapt and process different OAuth authorization methods, enabling service API calls with different authorization methods under the existing CAPIF architecture. For example, for service APIs that can access user privacy, by publishing the first information corresponding to the service API as authorization code authorization or PKCE, API callers are required to participate in authorization when calling the service API, thereby improving security performance.

[0320] It should be noted that the publication and storage of the first information in this embodiment is based on API granularity, so that the API caller can use the API identifier as an index to obtain the first information of the API that the AEF can provide, and thus can call the corresponding API using an appropriate calling method.

[0321] Method 700 provides a method for integrating multiple OAuth authorization methods with the CAPIF API publishing process. Unlike method 600, the first information in method 700 is the AEF granularity. The AEF is a portal for service providers to open their services to the outside world. Different AEFs can provide different or identical APIs, but due to their inherent capability limitations, they may only implement a limited number of authorization methods. This method is described below with reference to Figure 7.

[0322] Step 701: The API publishing function sends a request message to the API information function. Correspondingly, the API information function receives the request message from the API publishing function.

[0323] This request message can be used to publish a service API or to update AEF information.

[0324] It should be noted that the API information functional entity in this application is used to support the discovery of service API information and provide authorization for API callers before accessing the service API. Exemplarily, the API information functional entity can be a CAPIF core function entity (CAPIF core function, CCF).

[0325] The request message includes the identifier of the AEF and the first information. Optionally, it may also include the identifier of the service API. The identifier of the AEF may be the AEF ID, the AEF location, the URL of the AEF, the IP address of the AEF, etc. The first information includes the authorization type corresponding to the AEF. The authorization type is used to indicate the authorization method of the service API, which can be understood as the authorization method of the service API supported by the AEF, and can also be understood as the authorization method used by the AEF to provide the user resources indicated by the service API to the API caller. The authorization type may be an OAuth authorization type. The OAuth authorization type is used to indicate different authorization types of OAuth, and may include one or more of authorization code grant, client credential grant, implicit grant, resource owner password credentials grant, and extended authorization. Exemplarily, the extended authorization may include a Proof Key for Code Exchange (PKCE) for authorization code exchange.

[0326] It should be noted that, in method 700, the first information may be AEF information.

[0327] Optionally, the AEF information also includes the AuF identifier, scope, and one or more of the PKCE security methods. The AuF identifier is used to indicate the address of the AuF. Exemplarily, it can indicate the Uniform Resource Locator (URL) of the AuF. The scope is used to indicate the scope of permitted authorization, which can be understood as the scope of resources allowed to be accessed using the service API provided by the AEF, and can be represented by parameters in the API request message, such as API identifier, API ID, API input parameters, etc. Exemplarily, if the scope indicates that the service API provided by the AEF can obtain user location information, then the AuF allows the API caller to access the user's location information through the service API.

[0328] The PKCE security method may include a security method for generating a code_challenge, which is used to verify the identity of the API caller. The PKCE security method may include a security method for generating a code_challenge, such as null (represented by plain) or SHA256 (represented by S256). The specific steps for generating the code_challenge can be referred to in step 501 above and will not be repeated here.

[0329] It should be noted that, when the authorization type is PKCE, the AEF information may include one or more of the AuF identifier, scope, and PKCE security method.

[0330] In the case of authorization code authorization, the AEF information may include the AuF identifier and scope. In other words, in the case of authorization code authorization, the AEF information may not include the PKCE security method. It should be noted that the AuF and API information functional entities can be co-located. In the case of the AuF and API information functional entities being co-located, the AEF information may not include the AuF identifier.

[0331] In a possible implementation, the service API publishing request message includes identifiers of multiple AEFs and AEF information corresponding to each AEF identifier. For example, for different AEFs, there may be the following types of AEF information:

[0332] 1. AEF ID1: The AEF information includes the authorization type corresponding to AEF ID1, which is authorization code authorization. The AEF information also includes the AuF identifier and scope.

[0333] 2. AEF ID2: The AEF information includes the authorization type corresponding to AEF ID2, which is PKCE. The AEF information also includes the AuF identifier, scope, and PKCE security method.

[0334] 3. AEF ID3: The AEF information includes the authorization type corresponding to AEF ID3, which is client credential authorization.

[0335] 4. AEF ID4: The AEF information includes the authorization type corresponding to AEF ID4, which is authorization code authorization and PKCE. The AEF information also includes the AuF identifier, scope, and PKCE security method.

[0336] 5. AEF ID5: The AEF information includes the authorization type corresponding to AEF ID5, which is client credential authorization and PKCE. The AEF information also includes the AuF identifier, scope, and PKCE security method.

[0337] Step 702: The API information function entity sends a response message to the API publishing function entity.

[0338] The response message is used to respond to the request message in step 701. The response message may be a service API publishing response message.

[0339] The response message includes a result, which indicates whether the request succeeded or failed.

[0340] It is understandable that if the API information function entity receives the above-mentioned AEF information and stores it successfully, where the storage success may be that the API information function entity has stored the AEF information, or that the API information function entity has determined that the AEF information can be stored, then the API publishing function entity is notified of the successful release of the AEF information through the result of the publishing response. If the API information function entity fails to successfully receive the above-mentioned AEF information or fails to store it successfully (for example, due to limited configuration permissions, etc.), the API publishing function entity is notified of the failure of the AEF information release through the result of the publishing response.

[0341] Step 703: The API information function entity stores the AEF information, wherein the AEF information is the parameter received by the API information function entity through the service API publishing request message in step 701.

[0342] Exemplarily, corresponding to the first information received in step 701, that is, the AEF information, the API information function entity may store the AEF information corresponding to different AEF identifiers in the following manner:

[0343] 1. AEF ID1: The API information functional entity associates and stores the AEF ID1, the authorization code grant, the AuF identifier, and the scope. This association can be understood as the API information functional entity being able to identify the first information using the AEF ID. For example, the AEF ID and the first information can be stored as a corresponding relationship. Alternatively, the AEF ID and the first information can be stored separately, with an index established between the AEF ID and the first information. For example, the AEF ID1 can be used to subsequently determine the authorization code grant, AuF identifier, and scope associated with the AEF.

[0344] 2. AEF ID2: The API information functional entity stores the AEF ID2, PKCE, AuF identifier, scope, and PKCE security method together.

[0345] 3. AEF ID3: The API information functional entity stores the AEF ID3 and client credential authorization in association.

[0346] 4. AEF ID4: The API information functional entity associates and stores the AEF ID4, authorization code authorization, PKCE, AuF identification, scope, and PKCE security method.

[0347] 5. AEF ID5: The API information functional entity associates and stores the AEF ID5, client credential authorization, PKCE, AuF identifiers, scopes, and PKCE security methods.

[0348] It should be noted that there is no restriction on the order in which the API information functional entity sends the service API release response message in step 702 and stores the AEF information in step 703. It is understandable that the API information functional entity can also store the AEF information first and then send the service API release response message.

[0349] Step 704: The API caller sends a security method request message to the API information function entity. The security method request message is used to negotiate a security method.

[0350] Optionally, the security method request message includes the identifier of the AEF and the capability information of the API caller. The identifier of the AEF is used to indicate the AEF with which the API caller may interact. The capability information is used to indicate the authorization type supported by the API caller, which can also be understood as the security method (Security Method) supported by the API caller. The capability information includes the OAuth authorization type supported by the API caller, and optionally, it can also include the PKCE security method supported by the API caller. The OAuth authorization type is used to indicate different authorization types of OAuth, which can include one or more of authorization code authorization, client credential authorization, implicit authorization, resource owner password authorization and extended authorization. Exemplarily, the extended authorization can include PKCE. The PKCE security method includes a security method for generating code_challenge, which can exemplarily include null (represented by plain), SHA256 (represented by S256), etc.

[0351] The API caller's capability information may also include supported authentication methods, such as one or more of the TLS-PSK method, the TLS-PKI method, and the TLS with OAuth token method.

[0352] The capability information of the API caller can be represented using Table 1 or Table 2 in step 604, which will not be described in detail here.

[0353] For example, after the API caller completes authentication with the API information function entity, step 704 may be executed.

[0354] Step 705: Optionally, the API information function entity obtains method information.

[0355] The API information functional entity obtains method information based on the authorization type. The authorization type is the authorization type corresponding to the AEF, and the method information is the method information corresponding to the AEF.

[0356] Optionally, the API information function entity may directly use the authorization type corresponding to the AEF as method information.

[0357] For example, the API information function entity obtains the stored AEF information according to the identifier of the AEF, and then uses the authorization type in the stored AEF information as the method information.

[0358] Exemplarily, the API information function entity obtains the AEF information corresponding to the AEF ID1 according to the AEF identifier AEF ID1, including the associated authorization type, ie, authorization code authorization. The API information function entity uses the authorization code authorization as method information.

[0359] Exemplarily, the API information function entity obtains the AEF information corresponding to the AEF ID4 according to the AEF identifier AEF ID4, including the associated authorization types, namely, authorization code authorization and PKCE. The API information function entity uses the authorization code authorization and PKCE as method information.

[0360] Optionally, the API information function entity selects method information based on capability information and authorization type. The capability information is used to indicate the authorization type supported by the API caller.

[0361] For example, the API information function entity obtains the stored AEF information according to the AEF identifier, and then selects the method information according to the capability information of the API caller and the authorization type in the stored AEF information.

[0362] Exemplarily, the API information functional entity obtains the AEF information corresponding to AEF ID1 based on the AEF identifier AEF ID1, including the associated authorization type, namely, authorization code authorization. The capability information indicates that the API caller supports authorization code authorization. The API information functional entity selects authorization code authorization as the method information based on the method supported by both parties.

[0363] Exemplarily, the API information functional entity obtains the AEF information corresponding to AEF ID4 based on the AEF identifier AEF ID4, which includes the associated authorization types, namely, authorization code authorization and PKCE. The capability information indicates that the API caller supports client credential authorization and authorization code authorization. The API information functional entity selects authorization code authorization as the method information based on the mutually supported methods.

[0364] Exemplarily, the API information function entity obtains the AEF information corresponding to AEF ID5 based on the AEF identifier AEF ID5, including the associated authorization types, namely, client credential authorization and PKCE. The capability information indicates that the API caller supports client credential authorization and PKCE. The API information function entity selects client credential authorization and PKCE as the method information based on the methods supported by both parties.

[0365] Exemplarily, the API information functional entity obtains the AEF information corresponding to AEF ID4 based on the AEF identifier AEF ID4, including the associated authorization types, namely, authorization code authorization and PKCE. The capability information indicates that the API caller supports authorization code authorization and PKCE. The API information functional entity selects PKCE, which has a higher priority and is more secure, as the method information based on the methods supported by both parties and the priority list.

[0366] Exemplarily, the API information functional entity obtains the AEF information corresponding to AEF ID2 based on the AEF identifier AEF ID2, including the associated authorization type, namely PKCE. The capability information indicates that the API caller supports authorization code authorization. Since both parties do not have a mutually supported method, the API information functional entity fails to select the method information and returns a failure indication.

[0367] Optionally, when the API caller supports PKCE, the API caller's capability information may also include the PKCE security method supported by the API caller. After the API information functional entity determines that the method information is PKCE according to the above method, the API information functional entity determines the PKCE security method based on the PKCE security method supported by the API caller and the PKCE security method in the stored AEF information.

[0368] For example, the API information function entity obtains the stored AEF information according to the identifier of the AEF, and then selects the PKCE security method according to the PKCE security method supported by the API caller and the PKCE security method in the stored AEF information.

[0369] Exemplarily, the API information function entity selects PKCE as the method information based on the AEF ID 4 and the aforementioned method. The PKCE security methods corresponding to AEF ID 4 include null and SHA256. The PKCE security methods supported by the API caller include SHA256. The API information function entity selects SHA256 as the confirmed PKCE security method based on the mutually supported methods.

[0370] Exemplarily, the API information functional entity selects PKCE as the method information based on the AEF ID 4 and the aforementioned method. The PKCE security methods corresponding to AEF ID 4 include null and SHA256. The API caller's supported PKCE security methods include null and SHA256. The API information functional entity selects SHA256, which has a higher priority and is more secure, as the final PKCE security method based on the mutually supported methods and the priority list.

[0371] The capability information of the API caller may be obtained by the API information function entity from step 704 .

[0372] Step 706: The API information function entity sends a security method response (Security Method Response) message to the API caller.

[0373] Optionally, the security method response message includes method information. It is understandable that the method information is associated with the authorization type. The authorization type is the authorization type corresponding to AEF. The method information includes one or more of client credential authorization, authorization code authorization, and proof key PKCE for authorization code exchange. The method information is determined according to the method in step 705. Optionally, a security method is also included. Exemplary security methods may include TLS-PSK method, TLS-PKI method, and TLS with OAuth token method.

[0374] Optionally, the security method response message also includes the AuF identifier, range, and one or more of the determined PKCE security methods. It should be noted that the AuF identifier and range are the same as the AuF identifier and range received in step 701. The determined PKCE security method may be the same as the PKCE security method received in step 701, or may be obtained according to the method in step 705.

[0375] Step 707: The API caller sends a service discovery request message to the API information function entity. The service discovery request message is used to request discovery of a service API.

[0376] For the description of the discovery service request, please refer to the description of step 303 and will not be repeated here.

[0377] Optionally, the service discovery request message may further include capability information of the API caller. For the capability information of the API caller, reference may be made to the description of step 704 .

[0378] For example, when the API caller is ready to discover the service API, step 707 may be executed.

[0379] Step 708: The API information function entity sends a service API discovery response message to the API caller.

[0380] The service API discovery response message can refer to step 304 and will not be repeated here.

[0381] Optionally, the method information, AuF identifier, scope, and one or more of the determined PKCE security methods in step 706 may also be sent to the API caller via the service discovery response message in step 708.

[0382] In one possible approach, the API information function entity sends the AEF identifier, method information, AuF identifier, scope, and determined PKCE security method to the API caller through the service API discovery response message.

[0383] In another possible manner, the API information function entity sends the AEF identifier, method information, AuF identifier, and the determined PKCE security method to the API caller in step 706, and then sends the service API information to the API caller in step 708. The service API information includes the identifier and scope of the service API.

[0384] In another possible manner, the API information function entity sends the AEF identifier, method information, and the determined PKCE security method to the API caller in step 706, and then sends the service API information to the API caller in step 708. The service API information includes the service API identifier, the AuF identifier, and the scope.

[0385] Step 709: The API caller requests an access token for calling the service API from the API information function entity according to the method information.

[0386] The method information is the method information received by the API caller from the API information function entity. This method information may include multiple calling methods, such as one or more of client credential authorization, authorization code authorization, and proof key PKCE for authorization code exchange. This method information corresponds to the AEF identifier. The service API information also includes the AEF identifier, so the calling method of the service API can be determined. The access token is used to authorize the API caller to access a specific service API.

[0387] When the API caller receives a method information sent from the API information function entity, the method information can be determined as the calling method of the service API.

[0388] Specifically, when the API caller determines to call a service API, and the service API information includes a corresponding AEF identifier, and the AEF information corresponding to the AEF includes corresponding method information, the API caller determines the method information as the calling method for the service API. Optionally, when the service discovery response message in step 608 does not include method information, the API caller determines that the calling method for the service API is client credential authorization.

[0389] For example, the API caller will call API 2, and the AEF ID corresponding to API ID2 in the service API information is AEF ID2, and the method information of AEF ID2 in the AEF information is PKCE, then the API caller determines that the calling method of API 2 is PKCE.

[0390] When the API caller receives multiple method information sent from the API information function entity, it can select one of the calling methods from the method information according to the local policy, that is, use one of the method information as the calling method of the service API. Among them, the local policy can be used to indicate the priority of different calling methods. For example, the local policy can be in the form of a priority list of different calling methods, or a calling method that is preferred when certain conditions are met, for example, PKCE is preferred, which is not limited in this embodiment. For example, the priority list can be PKCE, authorization code authorization, and client credential authorization in the order of priority, which means that when the three calling methods of PKCE, authorization code authorization, and client credential authorization exist at the same time, PKCE takes precedence over authorization code authorization, and authorization code authorization takes precedence over client credential authorization.

[0391] For example, the API caller will call API 4, and the AEF ID corresponding to API ID4 in the service API ID information is AEF ID4, AEF ID 4 and the method information in the AEF information are authorization code authorization and PKCE, and the API caller's pre-configured priority list is PKCE, authorization code authorization, and client credential authorization. The API caller determines that the calling method of API 4 is PKCE according to the priority list.

[0392] Optionally, the API caller determines whether the determined calling method is applicable to the service API.

[0393] Specifically, the API caller determines whether the determined calling method is applicable to the service API according to the current calling instruction, and determines whether to execute the process of requesting the API information function entity for an access token for calling the service API.

[0394] For example, the user triggers the API caller to execute the API call with PKCE, that is, the current calling instruction is to execute the API call with PKCE, and the calling method determined by the API caller is also PKCE. The API caller determines that the determined calling method is applicable to the service API, and executes the process of requesting an access token for calling the service API from the API information function entity.

[0395] For example, the user triggers the API caller to execute the API call with the authorization code credential, that is, the current calling instruction is to execute the API call with the authorization code credential, and the calling method determined by the API caller is PKCE. The API caller determines that the determined calling method is not applicable to the service API. The API caller can re-determine a new calling method or stop executing the process of requesting the API information function entity for an access token to call the service API.

[0396] The process of the API caller requesting the API information function entity for an access token for calling the service API according to the method information is referred to the above step 609 and will not be repeated here.

[0397] Through the process of method 700, the publication and use of first information at the AEF granularity is implemented in CAPIF. This allows the API publishing functional entity to publish its supported APIs and the corresponding AEF authorization methods to the API information functional entity. API callers obtain the corresponding AEF method information through the API information functional entity, enabling automated adaptation and processing of different OAuth authorization methods by API callers. This allows for service API calls with different authorization methods to be implemented within the existing CAPIF architecture. For example, for a service API that can access user privacy, this service API is provided by the AEF. By publishing the first information corresponding to the AEF as authorization code authorization or PKCE, the API caller requires user participation in authorization when calling the service API, thereby improving security performance.

[0398] It should be noted that the publication and storage of the first information is based on the AEF granularity, so that the API caller can use the AEF identifier as an index to negotiate the available first information with the AEF, and thus can call the corresponding API using an appropriate authorization method.

[0399] Method 800 provides a method for updating first information at an API / AEF granularity. The API-granular first information corresponds to method 600, and the AEF-granular first information corresponds to method 700. Based on methods 600 and 700, when the first information corresponding to a service API / AEF is updated, the API information function also updates the first information corresponding to the service API / AEF, thereby ensuring that the published service API / AEF information is up-to-date. This method is described below with reference to FIG8 .

[0400] Step 801: The API publishing function entity sends a service API update request message to the API information function entity. The service API update request message is used to update the published service API information or AEF information.

[0401] The service API update request message includes the identifier and second information of the service API. It should be noted that before the API publishing functional entity sends the identifier and second information of the service API to the API information functional entity, it also sends the identifier and first information of the service API to the API information functional entity, wherein the second information is different from the first information. Optionally, it also includes a service API published information reference, where the second information is the new service API information or new AEF information corresponding to the service API. The published index is used by the API publishing functional entity to search for published service APIs. It can be understood that when the second information includes the identifier of the AEF, the service API update request message is used to update the published AEF information.

[0402] The second information may be new API information corresponding to the identifier of the service API, or new AEF information corresponding to the identifier of the AEF. It is understood that when the second information includes the identifier of the AEF, it is new AEF information corresponding to the identifier of the AEF. When the second information does not include the identifier of the AEF, it is new API information corresponding to the identifier of the service API. The second information includes one or more of client credential authorization, authorization code authorization, and proof key PKCE for authorization code exchange. Optionally, the second information also includes one or more of the identifier, scope, and PKCE security method of the AuF.

[0403] Optionally, the service API update request message also includes an update reason value, which indicates that the information corresponding to the service API is being updated. Exemplary reason values ​​include a target address change, a change in the scope of authorized authorization, a change in the authorization method, etc. The target address can be the IP address of the service API or the location of the AEF, etc.

[0404] In a possible implementation, when the first information on the API publishing functional entity side is updated, that is, when the service API information or AEF information is updated, the API publishing functional entity sends the service API update request message.

[0405] It is understood that when the API information function entity receives two messages about API ID 1, the first message being the first message and the second message being the second message, and the first and second messages being different, it determines that the first message corresponding to API ID 1 is updated to the second message. The determination method for AEF information is the same as that for service API information and will not be repeated here.

[0406] In one implementation, the second information can be a change in the authorization type compared to the first information. For example, the first information corresponding to API ID1 is the authorization code authorization, the AuF identifier, and the scope. Subsequently, the API information function entity receives the second information corresponding to API ID1, which is the authorization code authorization, the PKCE identifier, and the AuF identifier, as well as the scope. In another implementation, the second information corresponding to API ID1 is the PKCE identifier and the AuF identifier, as well as the scope.

[0407] In another implementation, the second information may be a change in information in the API information other than the authorization type compared to the first information. For example, the first information corresponding to API ID1 includes an authorization code authorization, an AuF identifier, and a scope, where the AuF identifier is AuF ID1, and the scope allows access to the user's profile picture and location information. Subsequently, the API information function entity receives the second information corresponding to the API ID, which includes an authorization code authorization, an AuF identifier, and a scope, where the AuF identifier is AuF ID2, and the scope allows access to the user's profile picture.

[0408] Step 802: The API information function entity updates the first information to the second information.

[0409] It can be understood that after receiving the service API update request message, the API information function entity replaces the first information corresponding to the originally stored API ID or AEF ID with the second information corresponding to the service API identifier or AEF identifier.

[0410] Exemplarily, this corresponds to the update of the service API information for API ID 1 in step 801. For example, for API ID 1, the corresponding first information is the authorization code authorization, the AuF identifier, and the scope. The second information corresponding to API ID 1 is the authorization code authorization and PKCE, the AuF identifier, and the scope. The API information functional entity replaces the previously stored first information corresponding to API ID 1 with the second information. That is, the second information corresponding to API ID 1 stored on the API information functional entity side is the authorization code authorization and PKCE, the AuF identifier, and the scope.

[0411] Step 803: The API information function entity sends a service API update response (Service API update Response) message to the API publishing function entity.

[0412] The service API update response message includes a result, which indicates whether the update succeeded or failed.

[0413] Step 804 (optional): If the API caller subscribes to the API change event from the API information function entity, the API information function entity sends an event notification message to the API caller.

[0414] The event notification message includes the updated service API information / AEF information, ie, the second information.

[0415] Step 805 (optional): The API caller requests an access token for calling the service API from the API information function entity according to the second information.

[0416] If the first information of the service API being accessed by the API caller is updated to the second information, the calling steps performed by the API caller according to the second information refer to the above step 609 and are not repeated here.

[0417] Through the process of method 800, the first information update at the API / AEF granularity is implemented in CAPIF, thereby ensuring that the information of the service API published by the API information functional entity is the latest, avoiding the API caller using old service API information to call the service API resulting in call failure, thereby enabling the API caller to use different OAuth authorization methods for automatic adaptation and processing.

[0418] FIG9 shows an exemplary flow chart of a method 900 provided in the present application, which includes the following steps.

[0419] S901, the API publishing functional entity sends the identifier and first information of the service API to the API information functional entity.

[0420] In one possible implementation, the API publishing function sends a service API publishing request message to the API information function. The service API publishing request message includes the service API identifier and the first information. (For details, see step 601 in method 600).

[0421] In another possible implementation, the API publishing function sends a request message to the API information function, including the AEF identifier and the first information (for details, see step 701 in method 700).

[0422] In another possible implementation, the API publishing function sends a service API update request to the API information function. The service API update request message includes the service API identifier and second information. Before sending the service API identifier and second information to the API information function, the API publishing function also sends the service API identifier and first information to the API information function. (For details, see step 901 in method 900).

[0423] In one possible implementation, the API publishing function sends a service API update request to the API information function. The service API update request message includes an update reason value. (For details, see step 901 in method 900).

[0424] S902, the API information functional entity stores the identification and first information of the service API.

[0425] In a possible implementation, the API information function entity stores service API information, where the service API information includes an identifier of the service API and the first information (for details, refer to step 603 in method 600).

[0426] In another possible implementation, the API information function entity stores AEF information, where the AEF information includes an AEF identifier and first information (for details, refer to step 703 in method 700 ).

[0427] In another possible implementation, the API information functional entity stores the identifier and first information of the service API. Subsequently, the API information functional entity receives the identifier and second information of the service API, and the API information functional entity updates the stored first information to the second information (for details, please refer to step 802 in method 800).

[0428] S903, the API caller sends capability information to the API information function entity.

[0429] In a possible implementation, the API caller sends an API caller registration request to the API information function entity. The registration request includes the capability information of the API caller (for details, please refer to step 604 in method 600).

[0430] In another possible implementation, the API caller sends a service discovery request message to the API information function entity. The service discovery request message includes the capability information of the API caller (for details, please refer to step 606 in method 600).

[0431] In a possible implementation, the API caller sends a security method request to the API information function entity. The security method request message includes the identifier of the AEF and the capability information of the API caller (for details, please refer to step 704 in method 700).

[0432] S904, the API information function entity obtains method information according to the authorization type.

[0433] In one possible implementation, the API information functional entity may directly use the authorization type corresponding to the service API as the method information. Alternatively, the API information functional entity selects the method information based on the capability information and the authorization type. (For details, see step 607 in method 600).

[0434] In another possible implementation, the API information function entity may directly use the authorization type corresponding to the AEF as the method information. Alternatively, the API information function entity selects the method information according to the capability information and the authorization type (for details, refer to step 705 in method 700).

[0435] S905, the API information function entity sends method information to the API caller.

[0436] In a possible implementation, the API information function entity sends a service discovery response message to the API caller, wherein the service discovery response message includes method information (for details, please refer to step 608 in method 600).

[0437] In another possible implementation, the API information function entity sends a security method response message to the API caller, wherein the security method response message includes method information (for details, refer to step 706 in method 700).

[0438] In another possible implementation, the API information function entity sends an event notification to the API caller. The event notification includes the second information stored by the API information function entity in step 902. (For details, please refer to step 804 in method 800).

[0439] S906: The API caller requests an access token for calling the service API from the API information function entity according to the method information.

[0440] In one possible implementation, the API information function entity sends a service discovery response message to the API caller, wherein the service discovery response message includes method information (for details, see step 609 in method 600, step 709 in method 700, and step 805 in method 800).

[0441] The above mainly introduces the solution provided by the embodiment of the present application from the perspective of interaction between different network elements. It can be understood that in order to realize the above functions, the API caller, API information functional entity and API publishing functional entity include hardware structures and / or software modules corresponding to the execution of each function. In combination with the units and algorithm steps of each example described in the embodiments disclosed in this application, the embodiments of the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in the form of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the technical solution of the embodiment of the present application.

[0442] The embodiment of the present application can divide the API caller, API information functional entity and API publishing functional entity into functional units according to the above method example. For example, each functional unit can be divided according to each function, or two or more functions can be integrated into one processing unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional units. It should be noted that the division of units in the embodiment of the present application is schematic and is only a logical functional division. There may be other division methods in actual implementation.

[0443] In the case of adopting an integrated unit, Figure 10 shows a possible exemplary block diagram of a device involved in an embodiment of the present application. The device 1000 can exist in the form of software, hardware, or a combination of software and hardware. Figure 10 shows a possible schematic block diagram of a device involved in an embodiment of the present application. The device 1000 includes: a processing unit 1002 and a communication unit 1003. The processing unit 1002 is used to control and manage the actions of the device. The communication unit 1003 is used to support communication between the device and other devices. The device may also include a storage unit 1001 for storing program code and data of the device.

[0444] The device 1000 shown in Figure 10 can be the API caller, API information functional entity or API publishing functional entity involved in the embodiments of the present application.

[0445] When the device 1000 shown in Figure 10 is an API caller, the processing unit 1002 can support the device 1000 to perform the actions performed by the API caller in the above-mentioned method examples. For example, the processing unit 1002 can support the device 1000 to perform step 609 in Figure 6, step 709 in Figure 7, step 805 in Figure 8, and / or other processes for the technology described in this article. The communication unit 1003 can support communication between the device 1000 and an API information functional entity or an API publishing functional entity, etc. For example, the communication unit 1003 supports the device 1000 to execute steps 301 to 309 in Figure 3, steps 406 to 408 in Figure 4, steps 506 to 508 in Figure 5, steps 601 to 602, steps 604 to 606 and step 608 in Figure 6, steps 701 to 702, step 704 and steps 706 to 708 in Figure 7, step 801 and steps 803 to 804 in Figure 8, and / or other related communication processes.

[0446] When the apparatus 1000 shown in FIG10 is an API publishing functional entity, the communication unit 1003 can support communication between the apparatus 1000 and an API caller or an API information functional entity, for example, the communication unit 1003 supports the apparatus 1000 in executing steps 301 to 306 in FIG3 , steps 406 and 408 in FIG4 , steps 506 and 508 in FIG5 , steps 604 to 606 and step 608 in FIG6 , step 704 and steps 706 to 708 in FIG7 , step 801 in FIG8 , and / or other related communication processes.

[0447] When the device 1000 shown in FIG10 is an API information functional entity, the processing unit 1002 can support the device 1000 in performing the actions performed by the API information functional entity in the above-mentioned method examples, for example, the processing unit 1002 supports the device 1000 in performing steps 603 and 607 in FIG6, steps 703 and 705 in FIG7, step 802 in FIG8, and / or other processes used in the technology described herein. The communication unit 1003 can support communication between the device 1000 and an API caller or an API publishing functional entity, for example, the communication unit 1003 supports the device 1000 in performing steps 301-306 in FIG3, step 407 in FIG4, step 507 in FIG5, steps 601-602, steps 604-606, and step 608 in FIG6, steps 701-702, step 704, and steps 706-708 in FIG7, steps 801 and 804 in FIG8, and / or other related communication processes.

[0448] Exemplarily, the processing unit 1002 may be a processor or a controller, such as a central processing unit (CPU), a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, a transistor logic device, a hardware component or any combination thereof. It may implement or execute the various exemplary logic blocks, units and circuits described in conjunction with the disclosure of this application. The processor may also be a combination that implements a computing function, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, and the like. The communication unit 1003 may be a communication interface, which is a general term. In a specific implementation, the communication interface may include one or more interfaces. The storage unit 1001 may be a memory.

[0449] When the processing unit 1002 is a processor, the communication unit 1003 is a communication interface, and the storage unit 1001 is a memory, the device involved in the embodiment of the present application may be the device 1100 shown in Figure 11.

[0450] Referring to FIG. 11 , the device 1100 includes a processor 1102 and a communication interface 1103. Furthermore, the device 1100 may also include a memory 1101. Optionally, the device 1100 may also include a bus 1104. The communication interface 1103, the processor 1102, and the memory 1101 may be interconnected via the bus 1104; the bus 1104 may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus. The bus 1104 may be divided into an address bus, a data bus, a control bus, and the like. For ease of illustration, FIG. 11 shows only one thick line, but this does not mean that there is only one bus or only one type of bus.

[0451] The processor 1102 may execute various functions of the device 1100 by running or executing programs stored in the memory 1101 .

[0452] Exemplarily, the device 1100 shown in FIG11 may be the API caller, API information functional entity or API publishing functional entity involved in the embodiments of the present application.

[0453] When the apparatus 1100 is an API caller, the processor 1102 can execute the actions performed by the API caller in the above-mentioned method examples by running or executing the program stored in the memory 1101. When the apparatus 1100 is an API information functional entity, the processor 1102 can execute the actions performed by the API information functional entity in the above-mentioned method examples by running or executing the program stored in the memory 1101.

[0454] When the apparatus 1100 is an API publishing functional entity, the processor 1102 may execute or run a program stored in the memory 1101 to perform the actions of the API publishing functional entity in the above-mentioned method examples.

[0455] The steps of the method or algorithm described in conjunction with the disclosure of the embodiments of the present application can be implemented in hardware or by a processor executing software instructions. The software instructions can be composed of corresponding software modules, which can be stored in random access memory (RAM), flash memory, read-only memory (ROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, hard disks, mobile hard disks, read-only compact discs (CD-ROMs), or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor so that the processor can read information from the storage medium and write information to the storage medium. Of course, the storage medium can also be an integral part of the processor. The processor and storage medium can be located in an ASIC. In addition, the ASIC can be located in an API caller, an API information functional entity, or an API publishing functional entity. Of course, the processor and storage medium can also exist as discrete components in an API caller, an API information functional entity, or an API publishing functional entity.

[0456] Those skilled in the art will appreciate that in one or more of the above examples, the functions described in the embodiments of the present application can be implemented using hardware, software, firmware, or any combination thereof. When implemented using software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or codes on a computer-readable medium. Computer-readable media include computer storage media and communication media, wherein communication media include any media that facilitates the transmission of computer programs from one place to another. The storage medium can be any available medium that can be accessed by a general-purpose or special-purpose computer.

[0457] The specific implementation methods described above further illustrate the purpose, technical solutions and beneficial effects of the embodiments of the present application. It should be understood that the above description is only a specific implementation method of the embodiments of the present application and is not intended to limit the scope of protection of the embodiments of the present application. Any modifications, equivalent replacements, improvements, etc. made on the basis of the technical solutions of the embodiments of the present application should be included in the scope of protection of the embodiments of the present application.

Claims

1. A method for calling a service application programming interface API, characterized in that: The method is applied in a general API framework, wherein the API information function entity provides an API caller with an interface for calling the service API published by the API publishing function entity, and the method comprises: Receive the identifier and first information of the service API from the API publishing function entity; wherein the first information includes an authorization type; the authorization type is used to indicate the authorization method of the service API; The method information associated with the authorization type is sent to the API caller; the method information is used to determine the calling method of the service API.

2. The method according to claim 1, characterized in that Before sending the method information associated with the authorization type to the API caller, the method further includes: According to the authorization type, the method information is obtained.

3. The method according to claim 2, characterized in that Before sending the method information associated with the authorization type to the API caller, the method further includes: Receiving capability information from the API caller; wherein the capability information is used to indicate the authorization type supported by the API caller; The obtaining the method information according to the authorization type includes: The method information is selected according to the capability information and the authorization type.

4. The method according to claim 3, characterized in that The first information also includes an identifier of an API open function AEF, and the receiving capability information from the API caller includes: Receiving capability information and an AEF identifier from the API caller; The method further comprises: The authorization type is determined according to the identifier of the AEF; the authorization type is used to indicate the authorization type corresponding to the AEF.

5. The method according to any one of claims 1 to 4, characterized in that: The method further comprises: The identifier of the service API and the first information are stored.

6. The method according to claim 5, characterized in that After receiving the identifier and the first information of the service API from the API publishing function entity, the method further includes: Receiving an identifier and second information of the service API from the API publishing function entity; wherein the second information is different from the first information; The first information is updated to the second information.

7. The method according to claim 6, characterized in that The method further comprises: A reason value is received from the API publishing functional entity; the reason value is used to indicate updating of information corresponding to the service API.

8. The method according to any one of claims 6 or 7, characterized in that: The method further comprises: The second information is sent to the API caller.

9. The method according to claims 1-8, characterized in that The first information also includes one or more of the identifier, scope, and PKCE security method of the authorization function AuF; wherein the AuF identifier is used to indicate the address of the AuF; the scope is used to indicate the scope of authorization allowed by the service API; the PKCE security method is used to indicate the method of generating a challenge value, and the challenge value is used to verify the identity of the API caller.

10. The method according to claim 9, characterized in that The method further comprises: Sending the AuF identifier, the scope, and one or more of the determined PKCE security methods to the API caller; wherein the determined PKCE security method is determined based on the PKCE security method.

11. The method according to any one of claims 1 to 10, characterized in that: The authorization type includes one or more of client credential authorization, authorization code authorization, and proof key PKCE for authorization code exchange.

12. The method according to any one of claims 1 to 11, characterized in that: Receiving the identifier and first information of the service API from the API publishing function entity includes: A service API publishing request message is received from the API publishing functional entity, where the service API publishing request message is used to publish the service API, and the service API publishing request message includes an identifier of the service API and first information.

13. A method for calling a service application programming interface API, characterized in that: The method is applied in a general API framework, wherein an API caller calls the service API published by an API publishing function entity through an API information function entity, and the method comprises: Receive method information from the API information function entity; wherein the method information includes one or more of client credential authorization, authorization code authorization, and proof key PKCE for authorization code exchange; An access token for calling the service API is requested from the API information function entity according to the method information; the method information is used to determine the calling method of the service API.

14. The method according to claim 13, characterized in that The method information includes two or three of the client credential authorization, the authorization code authorization, and the PKCE, and the method further includes: The calling method of the service API is determined according to the method information.

15. The method according to claim 14, characterized in that The determining the calling method of the service API according to the method information includes: One of the calling methods is selected from the method information according to a local policy; wherein the local policy is used to indicate the priority of different calling methods.

16. The method according to any one of claims 14 or 15, characterized in that: The method further comprises: Determine whether the calling method of the service API is applicable to the service API.

17. The method according to any one of claims 13 to 16, wherein the requesting the API information function entity for an access token for calling the service API according to the method information comprises: When the calling method is a client credential authorization method, requesting an access token for calling the service API from the API information function entity; or, When the calling method is an authorization code authorization method, obtaining a first authorization code, and using the first authorization code to request an access token for calling the service API from the API information function entity; or, When the calling method is the PKCE method, a second authorization code and a verification value are obtained, and the second authorization code and the verification value are used to request an access token for calling the service API from the API information function entity.

18. The method according to claim 17, characterized in that The method further comprises: receiving an identifier of an authorization function AuF from the API information function entity; wherein the identifier of the AuF is used to indicate an address of the AuF; When the calling method is an authorization code authorization method, requesting the first authorization code from the AuF according to the identifier of the AuF; or, When the calling method is the PKCE method, the second authorization code is requested from the AuF according to the identifier of the AuF.

19. The method according to claim 17 or 18, characterized in that The method further comprises: receiving a scope from the API information functional entity; Determine whether the scope includes the scope used by the API caller when requesting an access token for calling the service API; wherein the scope is used to indicate the scope that the service API allows to be authorized.

20. The method according to any one of claims 17 to 19, characterized in that: The method further comprises: Receiving a PKCE security method from the API information function entity, and obtaining a second authorization code and a verification value when the calling method is a PKCE method, comprising: A challenge value is generated according to the verification value and the PKCE security method; wherein the challenge value is used to verify the identity of the API caller.

21. The method according to any one of claims 13 to 20, characterized in that: The method further comprises: receiving second information from the API information function entity, wherein the second information includes updated method information; Request an access token for calling the service API from the API information function entity according to the updated method information.

22. The method according to any one of claims 13 to 21, characterized in that: Before receiving method information from the API information function entity, the method further includes: The capability information is sent to the API information function entity, where the capability information is used to indicate the calling methods supported by the API caller.

23. A method for calling a service application programming interface API, characterized in that: The method is applied in a general API framework, wherein an API publishing function entity publishes the service API to an API caller through an API information function entity, and the method includes: Sending the identifier and first information of the service API to the API information function entity; wherein the first information includes an authorization type; the authorization type is used to indicate the authorization method of the service API.

24. The method according to claim 23, characterized in that The first information also includes an identifier of an API open function AEF.

25. The method according to claim 23 or 24, characterized in that After sending the identifier of the service API and the first information to the API information function entity, the method further includes: Sending the identifier of the service API and second information to the API information function entity; wherein the second information is different from the first information.

26. The method according to claim 25, characterized in that The method further comprises: A reason value is sent to the API information function entity, where the reason value is used to indicate updating the information corresponding to the service API.

27. An application programming interface API information function entity, characterized in that: include: A unit for executing each step of the method according to any one of claims 1 to 12.

28. An application programming interface API caller, characterized in that: include: A unit for executing each step of the method according to any one of claims 13 to 22.

29. An application programming interface API publishing functional entity, characterized in that: include: A unit for executing each step of the method according to any one of claims 23 to 26.

30. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores instructions, which, when executed on a computer, enable the computer to perform the method according to any one of claims 1 to 26.

Images