Service API (Application Program Interface) calling method and device

Abstract

The invention provides a method and a device for calling a service API (Application Program Interface), which are applied to a general application programming interface API framework to realize calling of service APIs of different authorization types. The method comprises the steps that an API information function entity receives an identifier and an authorization type of a service API from an API release function entity, and the API information function entity sends the identifier and the authorization type of the service API to an API caller. Therefore, when an API caller calls the service API, the calling method of the service API can be determined according to the authorization type corresponding to the service API, so that the safety performance is improved.

Description

Technical Field

[0001] 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

[0002] The 3rd Generation Partnership Project (3GPP) defines a variety of application programming interface (API) related specifications. In order to avoid duplication and inconsistency between different API specifications, 3GPP defines a common API framework (CAPIF), which contains common features applicable to APIs. And 3GPP networks can provide external services through this CAPIF.

[0003] Under CAPIF, API callers can request 3GPP information from the 3GPP network. For example, API callers can request user location information from the 3GPP network, and user location information is user privacy information. If the API caller obtains 3GPP information without user authorization, there is a risk of user privacy information being exposed.

[0004] 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. Summary of the invention

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

[0006] In order to achieve the above objectives, this application adopts the following technical solutions:

[0007] In the first aspect, a method for calling a service API is provided, which is applied to a general API framework, wherein an API information function entity provides an API caller with an interface for calling the service API published by an API publishing function entity, and the method comprises: receiving an identifier and first information of the service API from the API publishing function entity. The first information comprises an authorization type; the authorization type is used to indicate the authorization method of the service API. 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.

[0008] It is understandable 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 a CAPIF core function entity (such as a chip or circuit), which is not limited to this.

[0009] 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 according to 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.

[0010] In a possible implementation, the same service API may have multiple authorization types, but the API caller may use only one authorization type when calling the service API, and the API information function entity may determine one of the multiple authorization types, namely, the method information. Before sending the method information associated with the authorization type to the API caller, the method further includes: obtaining the method information according to the authorization type.

[0011] In one possible implementation, before sending the method information associated with the authorization type to the API caller, the method also includes: receiving capability information from the API caller; wherein the capability information is used to indicate the authorization types 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, 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, and then ensure that the determined method information is an 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.

[0012] In a possible implementation, the first information also includes an identifier of an API open function AEF, and receiving capability information from the API caller includes: receiving capability information from the API caller and an identifier of the AEF. The method also includes: determining the authorization type according to the identifier of the AEF; the authorization type is used to indicate the authorization type corresponding to the AEF. It should be noted that the authorization type here is the AEF granularity, and the identifier of the AEF and the corresponding authorization type are obtained from the API publishing function entity through the API information function entity. Subsequently, when the API caller requests a security method, the capability information of the API caller and the identifier of the AEF are obtained, so that the API information function entity can determine the authorization type corresponding to the AEF according to the identifier of the AEF, and then the method information can be determined in combination with the authorization type supported by the API caller and the authorization type corresponding to the AEF, to ensure that the determined method information is the 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. In this way, when the API caller calls the service API through the AEF, the calling method of the service API can be determined according to the authorization type of the AEF.

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

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

[0015] In a 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 up to date, and avoids API callers using old service API information to call the service API, resulting in call failure.

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

[0017] In a possible implementation, the second information is sent to the API caller. In a possible implementation, the API caller subscribes to a service API information change event, and when the service API information changes, the second information is sent to the API caller. Thus, the API caller can obtain the latest service API information in a timely manner.

[0018] 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 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 a method for generating a challenge value, and the challenge value is used to verify the identity of the API caller.

[0019] In a possible implementation, one or more of the AuF identifier, the scope, 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.

[0020] 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 suitable for 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 suitable for 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.

[0021] In a possible implementation, the authorization type also includes implicit authorization and resource owner password authorization. Among them, implicit authorization is applicable to applications that do not require backend server support, and 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 PKCE for authorization code exchange, implicit authorization, and resource owner password authorization.

[0022] In a 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. In response to the service discovery request message, sending the method information associated with the authorization type to the API caller.

[0023] In a 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. In response to the security method request message, sending the method information associated with the authorization type to the API caller.

[0024] 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, and the method comprises: receiving method information from the API information function entity; wherein the method information comprises one or more of client credential authorization, authorization code authorization, and proof key PKCE for authorization code exchange. According to the method information, an access token for calling the service API is requested from the API information function entity; the method information is used to determine the calling method of the service API.

[0025] In the method provided in the second aspect, the API caller receives the method information of the service API from the API information function entity, so that when the API caller calls the service API, the calling method of the service API can be determined according to the method information. For example, for a service API that can access user privacy, the calling method is an authorization code authorization method or a PKCE method, so that the API caller needs the user to participate in the authorization when calling the service API, thereby improving security performance.

[0026] 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 according to the method information. The method information of the same service API may have multiple calling methods, but the API caller can only use one of the calling methods when calling the service API, and the API caller can determine a calling method from the method information.

[0027] In a possible implementation, determining the calling method of the service API according to the method information includes: selecting one of the calling methods from the method information according to a local policy; wherein the local policy is used to indicate the priority of different calling methods. The API caller selects the calling method with the highest priority according to the priorities of different calling methods, thereby ensuring that the selected calling method is the best.

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

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

[0030] In one possible implementation, an identifier of an 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 an 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 a 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 an 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.

[0031] In one possible implementation, a scope is received from the API information functional entity. It is determined 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 of user resources that the service API authorizes to access. 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.

[0032] In one possible implementation, a PKCE security method is received from the API information function entity, and 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.

[0033] In a possible implementation, second information is received from the API information functional entity, and the second information includes updated method information. An access token for calling the service API is requested from the API information functional entity according to the updated method information. The API caller requests an access token for calling the service API by using the updated method information, thereby avoiding a call failure caused by the API caller calling the service API using old service API information.

[0034] In a possible implementation, second information is received from the API information functional entity, the second information including an updated AuF identifier. A third authorization code is requested from the AuF according to the updated AuF identifier; wherein the third authorization code is used to request an access token for calling the service API from the API information functional entity.

[0035] In a 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 a scope used by the API caller when requesting an access token for calling the service API.

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

[0037] 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 to 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 leakage.

[0038] In a possible implementation, before receiving method information from the API information function entity, the method further includes: sending capability information to the API information function entity, the capability information being used to indicate the calling methods supported by the API caller. For related descriptions, refer to the above related content of the first aspect, which will not be repeated here.

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

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

[0041] In a 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.

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

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

[0044] In the method provided based on 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.

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

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

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

[0048] 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 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 a method for generating a challenge value, and the challenge value is used to verify the identity of the API caller.

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

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

[0051] In one possible implementation, sending the identifier and first information of the service API to the API information functional entity includes: sending a service API publishing request message to the API publishing functional 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.

[0052] 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 method design. The function can be implemented by hardware, or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above functions. For example, the device can be an API information functional entity, or it can be a chip in an API information functional entity.

[0053] In one possible design, the device is an API information function entity, and the API information function entity includes a processor, and the processor is configured to support the API information function entity to perform the corresponding functions in the above method. Further, the API information function entity may also include a communication interface, and the communication interface is used to support communication between the API information function entity and the user plane entity or other network elements of the centralized unit. Further, the API information function entity may also include a memory, and the memory is used to couple with the processor, which stores the necessary program instructions and data of the API information function entity.

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

[0055] In one possible design, the device is an API caller, and the API caller includes a processor, and the processor is configured to support the API caller to perform the corresponding functions in the above method. Further, the API caller may also include a communication interface, and the communication interface is used to support communication between the API caller and the user plane entity or other network elements of the centralized unit. Further, the API caller may also include a memory, and the memory is used to couple with the processor, which stores the necessary program instructions and data of the API caller.

[0056] 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 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 functions. For example, the device can be an API publishing functional entity, or can be a chip in an API publishing functional entity.

[0057] In one possible design, the device is an API publishing functional entity, and the API publishing functional entity includes a processor, and the processor is configured to support the API publishing functional entity to perform the corresponding functions in the above method. Further, the API publishing functional entity may also include a communication interface, and the communication interface is used to support communication between the API publishing functional entity and the user plane entity or other network elements of the centralized unit. Further, the API publishing functional entity may also include a memory, and the memory is used to couple with the processor, which stores the necessary program instructions and data of the API publishing functional entity.

[0058] In the seventh aspect, an embodiment of the present application provides a communication system, wherein the system 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.

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

[0060] In a 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 above-mentioned second aspect or fifth aspect.

[0061] 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 above-mentioned third aspect or sixth aspect.

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

[0063] In the twelfth aspect, an embodiment of the present application provides a chip system for application in an API caller, wherein the chip system comprises at least one processor, a memory and an interface circuit, wherein the memory, the interface circuit and the at least one processor are interconnected via 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.

[0064] In the thirteenth aspect, an embodiment of the present application provides a chip system, which is applied to an API publishing functional entity, and 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.

[0065] In a fourteenth aspect, a computer program product is provided, comprising a computer program or instructions, which, when executed on a computer, enables the computer to execute the method described in any one of the possible implementation modes.

[0066] In the above scheme, under CAPIF, the service API identifier and authorization type are received through the API information functional entity, so that the API caller can obtain the authorization type from the API information functional entity, and then when the API caller calls the service API, the service API can be called according to the authorization type. The calling of service APIs with different authorization types under the CAPIF architecture is realized, thereby improving security performance. BRIEF DESCRIPTION OF THE DRAWINGS

[0067] Figure 1 A communication network architecture diagram applicable to the present application is shown;

[0068] Figure 2 A schematic diagram of the architecture of CAPIF applicable to the present application is shown;

[0069] Figure 3 It is a flowchart of calling an API;

[0070] Figure 4 This is another flowchart for calling the API;

[0071] Figure 5 This is another flowchart of calling an API;

[0072] Figure 6 A flow chart of a communication method 600 provided in an embodiment of the present application;

[0073] Figure 7 A flow chart of a communication method 700 provided in an embodiment of the present application;

[0074] Figure 8 A flow chart of a communication method 800 provided in an embodiment of the present application;

[0075] Fig. 9 A flow chart of a communication method 900 provided in an embodiment of the present application;

[0076] Fig.10 A schematic block diagram of a device provided in an embodiment of the present application;

[0077] Fig.11 A schematic diagram of the structure of a device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0078] In order to make the purpose, technical solution and advantages of the present application clearer, the present application will be further described in detail below with reference to the accompanying drawings. The specific operation method in the method embodiment can also be applied to the device embodiment or the system embodiment. In the description of the present application, unless otherwise specified, the meaning of "multiple" is two or more.

[0079] In the various embodiments of the present application, unless otherwise specified or provided for in any logical conflict, the terms and / or descriptions between the different embodiments are consistent and may be referenced to each other, and the technical features in the different embodiments may be combined to form new embodiments according to their inherent logical relationships.

[0080] It is understood that the various numbers involved in this application are only for the convenience of description and are not used to limit the scope of this application. The order of execution of each process should be determined by its function and internal logic.

[0081] The terms "first", "second", "third", "fourth" and various other terminology labels (if any) in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be 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, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0082] The technical solution provided in this application can be applied to various communication systems, such as: fifth generation (5th generation, 5G) or new radio (new radio, NR) system, long term evolution (long term evolution, LTE) system, LTE frequency division duplex (frequency division duplex, FDD) system, LTE time division duplex (time division duplex, TDD) system, etc. The technical solution provided in this application can also be applied to future communication systems, such as the sixth generation mobile communication system. The technical solution 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 system or other communication systems.

[0083] The following will be combined Figure 1 (a) and (b) in the figure illustrate the 5G system to which the embodiment of the present application is applicable. It should be understood that the 5G system described in this article is only an example and should not constitute any limitation to the present application.

[0084] It should also be understood that some network elements in the 5G system can communicate using service-oriented interfaces or point-to-point interfaces. Figure 1 (a) and Figure 1 (b) in the figure introduces the 5G system framework based on point-to-point interface and the 5G system framework based on service-oriented interface respectively.

[0085] As an example, Figure 1 The schematic diagram of the architecture of the 5G system to which the embodiment of the present application is applicable is shown. 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.):

[0086] (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.

[0087] Below Figure 1 A brief introduction to each network element shown in FIG:

[0088] 1. User equipment (UE): can be called terminal equipment, terminal device, access terminal, user unit, user 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. User equipment can be a device that provides voice / data connectivity to users, such as handheld devices with wireless connection function, vehicle-mounted devices, etc. At present, some examples of terminals may include: mobile phones, tablet computers, computers with wireless transceiver functions (such as laptop computers, 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 (public land mobile network, PLMN) and other terminal devices.

[0089] In addition, the user device can also be a terminal device in the Internet of Things (IoT) system. IoT is an important part of the future development of information technology. Its main technical feature is to connect objects to the network through communication technology, thereby realizing an intelligent network of human-machine interconnection and object-to-object interconnection. IoT technology can achieve massive connections, deep coverage, and terminal power saving through narrowband (NB) technology, for example.

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

[0091] 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 according to the level of user devices and business requirements.

[0092] (R)AN can manage wireless resources, provide access services for user equipment, and then complete the forwarding of control signals and user equipment data between user equipment and the core network. (R)AN can also be understood as a base station in a traditional network.

[0093] Exemplarily, the access network device in the embodiment of the present application can be any communication device with wireless transceiver function for communicating with user equipment. The access network device includes but is not limited to an evolved NodeB (eNB) or a gNB in ​​a 5G, such as NR, system, or a transmission point (TRP or TP), one or a group of antenna panels (including multiple 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).

[0094] In some deployments, the gNB may include a central unit (CU) and a DU. The gNB may also include an active antenna unit (AAU). The CU implements some functions of the gNB, and the DU implements some functions of the gNB. For example, the CU is responsible for processing non-real-time protocols and services, and 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, and implementing the functions of the radio link control (RLC) layer, the media access control (MAC) layer, and the physical (PHY) layer. The AAU implements some physical layer processing functions, radio frequency processing, and related functions of active antennas. Since the information of the RRC layer will eventually become the information of the PHY layer, or be converted from the information of the PHY layer, under this architecture, high-level signaling, such as RRC layer signaling, can also be considered to be sent by the DU, or by the DU+AAU. It can be understood that the access network device may include one or more of the devices of the CU node, the DU node, and the AAU node. In addition, the CU may be classified as an access network device in a radio access network (RAN), or may be classified as an access network device in a core network (CN), which is not limited in the present application.

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

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

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

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

[0099] 5. Session management function (SMF) network element: mainly used for session management, allocation and management of Internet protocol (IP) addresses of user equipment, selection of UPF that provides message forwarding function, endpoints of policy control and charging function interfaces, and downlink data notification, etc.

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

[0101] 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.).

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

[0103] 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 to the network side.

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

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

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

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

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

[0109] 10. Data network (DN): DN is a network outside the operator network. The operator network can access multiple DNs. A variety of services can be deployed on the DN, which can provide data and / or voice services to terminal devices. For example, DN is the private network of a smart factory. The sensors installed in the workshop of the smart factory can be terminal devices. The control server of the sensors is deployed in the DN, and the control server can provide services for 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, DN is the internal office network of a company. The mobile phones or computers of the company's employees can be terminal devices. The employees' mobile phones or computers can access information, data resources, etc. on the company's internal office network.

[0110] 11. Network exposure function (NEF) network element is mainly used to support the opening 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 use these network functions to provide richer services and applications.

[0111] 12. The NF repository function (NRF) network element is mainly used to maintain information about network resources, including network functions, services, applications, etc. The NRF network element can provide query and discovery functions for network resources, so that third-party applications can quickly find the required network resources and use these resources to provide richer services and applications.

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

[0113] exist Figure 1In the network architecture shown in (a), each network element can communicate with each other through the interface 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 (N1Message). 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 as follows: Figure 1 As shown in (a), for the sake of brevity, they are not described in detail here.

[0114] like Figure 1 (b) is a schematic diagram of a 5G network architecture based on a point-to-point interface. The functions of the network elements can be found in Figure 1 The introduction of the functions of the corresponding network elements in (a) will not be repeated here. Figure 1 (b) and Figure 1 The main difference of (a) is that: Figure 1 The interfaces between the network elements in (b) are point-to-point interfaces rather than service-oriented interfaces.

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

[0116] 1) N1: The interface between AMF and UE, used to deliver QoS control rules, etc. to UE.

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

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

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

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

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

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

[0123] 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's current mobility management related information with UDM.

[0124] 9) N9: Interface between UPFs, used to transfer uplink and downlink user data flows between UPFs.

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

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

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

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

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

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

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

[0132] The solution of the embodiment of the present application can be applied to Figure 2 The network architecture described, Figure 2It is a schematic diagram of the CAPIF architecture. It is understandable that the terms given below are explained 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. Figure 2 The architecture shown mainly includes the following network elements:

[0133] 1. API caller (API invoker), usually provided by a third-party application provider that has a service agreement with the operator network. The API caller 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 CAPIF core functional entities; 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 third-party application on the UE. Among them, third-party applications refer to applications developed by non-operating system 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 Figure 1 (a) and Figure 1 (b) AF network element. Among them, the functions (3), (4), and (5) of the API caller are related to the present invention.

[0134] 2. CAPIF core function (CCF) entity is the central storage of service API policies and the center of authentication and authorization of API callers and service APIs. It has the following functions: 1) Authenticate API callers according to 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 according to the policies configured by PLMN operators; 6) Store service API call logs and provide service API call logs to the authorization entity; 7) Bill according to service API call logs; 8) Monitor service API calls; 9) Add new API callers and exit 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 in CAPIF docking. Among them, functions (1), (3) and (4) of the CAPIF core function entity are related to the present invention.

[0135] 3. API exposing function (AEF) entity is an entry point for service providers to open services to the outside world. API callers can use the services provided by service providers through AEF entities. It includes the following functions: 1) Authenticate API callers based on the identity and other information required for API caller authentication provided by the CAPIF core function; 2) Verify the authorization provided by the CAPIF core function; 3) Record the service API calls of the CAPIF core function. In the 3GPP network, AEF can be NEF, that is, the location of AEF in the communication network can be seen in Figure 1 The NEF network element in (a) is an API interface that provides an open operator network to the outside world and provides interaction between external servers 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.

[0136] 4. API publishing function entity, a functional network element that enables API providers to publish APIs. Service API information can be published to the CAPIF core function entity so that API callers can find service API information in the CAPIF core function entity. It should be noted that the API publishing function entity and NEF can be set together.

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

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

[0139] 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. RO Client can be Figure 1 (a) and Figure 1 (b) Application on the UE.

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

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

[0142] 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 with the API publishing functional entity is the CAPIF-4 interface, and the interface with 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 with the RO Client is the CAPIF-8 interface.

[0143] In order to facilitate understanding of the embodiments of the present application, some terms involved in the present application are exemplified below.

[0144] 1. Application Programming Interface (API): Application Programming Interface. It includes the following types: 1) CAPIF API, which provides some general API interfaces. CAPIF API is usually provided by the system or platform, and provides API callers with an interface for the entry of CAPIF core functional entities; 2) Service API, system components expose their services to API callers by abstracting services from the underlying mechanism. Services can be of any type, such as Web services, cloud services, database services, etc. Service API is usually provided by service providers to access and use services, and provides API callers with an interface for the entry of API open functional entities; 3) Authorization API, which is used to verify user identity, authorize users to access resources, etc. Authorization API is usually provided by the identity authentication and authorization system to protect the security of applications and data, and provides API callers with an interface for the entry of authorization functional network entities. The difference between these three APIs lies in their different functions. Among them, CAPIF API is a general API framework used to implement various functions; service API is an API used to access and use services; authorization API is an API used for authorization and authentication.

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

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

[0147] 4. Scope: Scope is used to limit which user data the API caller can access. For example, an application can request one or more scopes, the requested scope information will be presented to the user on the screen, and the access token issued to the application is limited to the authorized scope.

[0148] OAuth (Open Authorization) is an authorization protocol used to authorize third-party applications to access the 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 that users need to provide their own username and password when using third-party applications, thereby improving the security of user privacy.

[0149] Open Authorization 2.0 (OAuth2.0) is the next generation version of the OAuth protocol, which 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 a third-party application to access his or her resources on a certain service provider (for example: 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:

[0150] 1. Client credential grant (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.

[0151] 2. Authorization Code Grant: The client requests authorization from the authentication server, and the authentication server requests authorization from the user. 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.

[0152] 3. Implicit Grant: The client directly requests an access token from the authentication server, omitting the authorization code step. It 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 be authenticated.

[0153] 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 the user have a high degree of trust and the number of users is small.

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

[0155] Among them, implicit authorization and resource owner password authorization are relatively less secure. Here we introduce client credential authorization under CAPIF ( Figure 3 ), Authorization Code Grant( Figure 4 ), PKCE( Figure 5 )Three authorization methods.

[0156] The Transport Layer Security (TLS) protocol protects network communications in the following ways:

[0157] 1. TLS-PSK (Pre-Shared Key) is a TLS implementation based on pre-shared keys. During the TLS handshake process, the client and server use pre-shared keys 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.

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

[0159] 3. TLS with OAuth token is a TLS implementation based on the OAuth protocol. During the TLS handshake process, the client uses the OAuth token for authentication, and the server uses a digital certificate for authentication and key exchange. This method is suitable for scenarios where secure API calls are required, such as mobile applications and cloud services.

[0160] Combine the following Figure 3 Each step in the introduction introduces the client credential authorization (client_credentialGrant) method under CAPIF, and implements the process of CCF authorizing API callers to call specific APIs from AEF. The client credential authorization method can be understood as the API caller using the caller's identity information to request an access token from CCF. Among them, the client credential authorization is a type of authorization in the TLS with OAuth token authentication method.

[0161] Step 301, the API caller sends an API caller registration request (Onboard API InvokerRequest) message to the CCF, and the API caller registration request message is used to register the API caller to the CCF.

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

[0163] Step 302: CCF sends an API caller registration response (Onboard API InvokerResponse) message to the API caller.

[0164] 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 by the CCF to the API caller, 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.

[0165] Step 303: The API caller sends a service discovery request (DiscoveryService Request) message to the CAPIF core function entity. The service discovery request message is used to request the discovery service API.

[0166] The service discovery request includes an API caller ID and request information, wherein the request information includes a standard for discovering certain APIs, which may be information preferred by the API caller, such as the AEF location and protocol preferred by the API caller.

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

[0168] The service discovery response message includes service API information, and CCF obtains the service API information according to 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.

[0169] 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 by registering the API in step 301 , and the service API information sent by CCF in step 304 may be the service API information obtained by requesting information in step 303 .

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

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

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

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

[0174] 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). Among them, 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), wherein the update token 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. Among them, the statement includes the following contents: timeout period, API caller ID, identifier of AEF, identifier of service API. The signature is the digital signature of CCF on the token. Optionally, the statement also includes a user identifier.

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

[0176] Step 307: The API caller sends a service API invocation request (Service API InvocationRequest) message to the AEF.

[0177] The service API call request message includes an API caller ID, an identifier of the service API, and an access token, wherein the access token includes a statement and a signature, and the access token is obtained by the API caller from step 306. Optionally, the service API call request message also includes a user identifier.

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

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

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

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

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

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

[0184] Figure 4 and Figure 3 The main difference is Figure 4 The authorization process involves the participation of users, which can prevent API callers from directly obtaining access tokens and user data without user authorization. Figure 4 The steps in the chapter introduce the authorization code grant method under CAPIF, which implements the process of CCF authorizing API callers to call specific APIs through AEF. The authorization code grant 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 an access token. Among them, the authorization code grant is a type of authorization in the transport layer token (TLS with OAuthtoken) authentication method.

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

[0186] The authorization code request is used by the API caller to request the RO client to obtain an authorization code from the authorization function (AuthorizationFunction, 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. Among them, 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, APIID, API input parameters, etc. It should be noted that the scope is used to define the scope of API callers' access to user resources. API callers can request one or more scopes, and 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.

[0187] Step 402: RO client sends an authorization request message to AuF. The authorization request message is used to request an authorization code.

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

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

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

[0191] RO can be understood as a user. One implementation method is that AuF sends authorization query information to RO Client based on the scope. For example, if the scope indicates that the API can obtain location information, AuF sends authorization query information to RO Client. The information can be encapsulated by the Hypertext Transfer Protocol (HTTP) protocol and finally parsed by RO Client as content containing "whether you agree that the API caller can access your location information". The user can click "Agree" or "Disagree". If the user agrees, RO Client sends the user consent result back to AuF, and AuF has obtained the authorization of RO.

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

[0193] For example, the RO client can use HTTP-based username and password for authentication with the AuF. The RO enters the pre-registered username and password in the RO client, and the AuF completes the authentication of the RO by verifying whether the username and password are the same as the username and password stored in the database.

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

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

[0196] It can be understood that 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.

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

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

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

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

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

[0202] AuF verifies whether the authorization code and redirect URL sent by CCF are the same as the authorization code and redirect URL sent by AuF to RO client through the authorization response message in step 404. If they are the same, the authorization code verification is passed and step 408 is performed. If they are different, the authorization code verification fails is returned.

[0203] Step 408: When the authorization code verification passes, CCF sends a token response message to the API caller.

[0204] The token response message includes an access token. Optionally, it also includes a refresh token. The refresh token is used to obtain the next access token. When the access token needs to be updated, the user does not need to perform authorization again, thus avoiding frequent authorization operations.

[0205] 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 limit the API caller to access only the user name, avatar, etc. through the scope.

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

[0207] The API request message includes an access token, which is used to request the AEF to call a related API.

[0208] Step 410: AEF sends an API response message to the API caller.

[0209] Before sending the API response message, AEF verifies the signature and scope of the access token. Among them, the way of verifying the signature is, for example, AEF verifies the signature of the access token through the pre-configured CCF authentication credentials (such as certificates). The way of verifying the scope is, for example, to verify whether the scope in the access token is within the scope allowed to be accessed by the user. If both the access token signature and scope checks are passed, the API caller is authorized to access user resources through the API response message.

[0210] Figure 5 and Figure 4 The difference is Figure 5 The PKCE of OAuth 2.0 is used 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, he cannot use the authorization code to obtain an access token because the attacker cannot provide the correct code_verifier. Combined with Figure 5 The steps in the introduction introduce the PKCE method under CAPIF, which implements 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.

[0211] Step 501: The API caller sends an authorization code request message to the Resource Owner client (RO client). For specific steps, please refer to the above step 401.

[0212] 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 code_challenge according to code_verifier and code_challenge_method.

[0213] Where 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:

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

[0215] 2) Perform hash operation on code_verifier to generate code_challenge, for example, code_challenge_method is Secure Hash Algorithm (SHA) 256 (characterized by S256).

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

[0217] 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 specific steps, please refer to the above step 402.

[0218] The difference from step 402 is that the authorization request message also includes code_challenge and code_challenge_method. After receiving the authorization code, AuF stores the authorization code, code_challenge and code_challenge_method in an associated manner. The associated storage means storing the corresponding relationship between the authorization code, code_challenge and code_challenge_method. For example, the corresponding code_challenge and code_challenge_method can be determined later by the received authorization code.

[0219] Step 503 to step 505 are the same as the above-mentioned step 403 to step 405, and will not be repeated here.

[0220] Step 506: The API caller sends a token request message to the CCF to request a token. For specific steps, please refer to the above step 406.

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

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

[0223] The difference from step 407 is that AuF can obtain the code_challenge and code_challenge_method corresponding to the authorization code according to the authorization code and the association relationship stored in step 502. And AuF can generate code_challenge according to the received code_verifier and the stored code_challenge_method. Check whether the generated code_challenge is consistent with the code_challenge stored in step 502. When the authorization code and code_verifier are verified, AuF instructs CCF to send a token to the API caller and proceed to step 508. Otherwise, return verification failure. Steps 508-510 are the same as the above steps 408-410, and will not be repeated here.

[0224] Figure 3-Figure 5 Three OAuth authorization methods under CAPIF (client credential authorization, authorization code authorization, and PKCE) are introduced 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.

[0225] In view of this, method 600 provides a method for combining multiple OAuth authorization methods with the API publishing process of CAPIF. When an API caller calls a service API to AEF, the API caller uses different calling methods according to its own capabilities and the service API authorization method. Figure 6 This method is introduced.

[0226] 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 the service API.

[0227] It should be noted that the API information functional entity in the present 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).

[0228] 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 an API ID, an API name, a URL, an IP address, a port number, etc. The first information includes an authorization type, which is an 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 an authorization method used by API callers 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).

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

[0230] Optionally, the service API information also includes one or more of the authorization function (AuF) identification, scope, and PKCE security method. Figure 2 The AuF identifier is used to indicate the address of the AuF. For example, it can indicate the Uniform Resource Locator (URL) of the AuF.

[0231] The scope is used to indicate the scope of authorization allowed by the service API, which can be understood as the scope of resources allowed to be accessed using the service API, 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 can obtain user location information, then AuF allows the API caller to access the user's location information through the service API.

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

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

[0234] In the case where the authorization type is authorization code authorization, the service API information may include the AuF identifier and scope. It can be understood that in the case where 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 combined together. In the case where the AuF and API information functional entities are combined, the AuF identifier may not be used to indicate the AuF address, that is, the service API information may not include the AuF identifier.

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

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

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

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

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

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

[0241] Step 602: The API information functional entity sends a service API publish response (ServiceAPI Publish Response) message to the API publishing functional entity.

[0242] The service API publishing response message includes a result and a service API published information reference. The result is used to indicate whether the service API information is published successfully or failed. The service API published information reference is used by the API publishing function entity to search for the published service API.

[0243] It is understandable that if the API information functional entity receives the above 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, the configuration authority is limited, etc.), the result is used to notify the API publishing functional entity that the API information fails to be published. Among them, the storage success can be that the API information functional entity has stored the API information. It is determined that the API information can be stored, for example, the API information functional entity determines whether the API information is allowed to be stored according to the configuration authority, and determines that the API information can be stored if the configuration authority allows.

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

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

[0246] 1. API ID1: The API information functional entity stores API ID1, authorization code authorization, AuF identification and scope together in an associated manner. The associated storage can be understood as the API information functional entity can determine the first information through the API ID. For example, the API ID and the first information can be saved as a corresponding relationship; it can also be expressed as storing the API ID and the first information separately, and establishing an index between the API ID and the first information. For example, the authorization code authorization, AuF identification and scope corresponding to the API can be determined through API ID1 later.

[0247] 2. API ID2: The API information functional entity stores API ID2, PKCE, AuF identifier, scope, and PKCE security method in association with each other.

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

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

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

[0251] It should be noted that there is no restriction on the order in which the API information functional entity sends the service API publish 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 publish response message.

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

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

[0254] Optionally, the API caller registration request message includes the capability information of the API caller, and the capability information 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, it 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.

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

[0256] Exemplarily, the capability information of the API caller includes TLS with OAuth token authentication method, authorization code authorization. Another example is that the capability information of the API caller includes TLS with OAuth token authentication method, authorization code authorization and PKCE, and SHA256 method.

[0257] Exemplarily, the capability information of the API caller can be represented using the following table:

[0258] Table 1 Supported security methods

[0259]

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

[0261] Table 2 Supported security methods

[0262] Primary Key PSK PKI OAUTH OAUTH with PKCE with null OAUTH with PKCE with SHA256 OAUTH with Authorization code grant

[0263] It is worth noting that the first two rows in Table 1 are existing designs, and 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 is worth noting that the first three rows in Table 2 are existing designs, and the third row represents support for OAuth client credential authorization by default. The last three rows contain both OAuth authorization types and PKCE security methods. In this way, without changing the data type of the original security method, it is compatible with the previous old method and has backward compatibility, and the expanded security method supports 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 capability information of the API caller includes client credential authorization and authorization code authorization. Then the capability information of the API caller can be represented by rows 3 and 4 in Table 1, or rows 3 and 6 in Table 2.

[0267] In another possible method, 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). Then the API caller's capability information can be represented by rows 4 and 6 in Table 1, or rows 5 and 6 in 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 API caller registration response (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, and 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 relevant description of the discovery service request, please refer to the description of step 303, which will not be repeated here.

[0273] Optionally, the service discovery request message may further include capability information of the API caller. The capability information of the API caller may refer 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 according to 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 ID4 according to the service API standard, and obtains the service API information corresponding to API ID4, 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 according to 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 the 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 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 capability information indicates that the API caller supports authorization code authorization, and the API information functional entity selects authorization code authorization as the method information according to the method supported by both parties.

[0284] Exemplarily, the API information functional entity obtains API ID4 according to the service API standard, and obtains the service API information corresponding to API ID4, including the associated authorization type, namely, authorization code authorization and PKCE. The capability information indicates that the API caller supports client credential authorization and authorization code authorization, and the API information functional entity selects authorization code authorization as the method information according to the method supported by both parties.

[0285] Exemplarily, the API information functional entity obtains API ID5 according to the service API standard, and obtains the service API information corresponding to API ID5, 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, and the API information functional entity selects client credential authorization and PKCE as method information according to the method supported by both parties.

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

[0287] Exemplarily, the API information functional entity obtains API ID2 according to the service API standard, and obtains the service API information corresponding to API 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 method that they both support, 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 standard of the service API, 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 ID4 according to the standard of the service API, and selects PKCE as the method information with reference to the above method. The PKCE security method corresponding to API ID4 includes null and SHA256. The PKCE security method supported by the API caller includes SHA256, and the API information functional entity selects SHA256 as the determined PKCE security method according to the method supported by both parties.

[0291] Exemplarily, the API information functional entity obtains API ID4 according to the standard of the service API, and selects PKCE as the method information with reference to the above method. The PKCE security methods corresponding to API ID4 include null and SHA256. The PKCE security methods supported by the API caller include null and SHA256. The API information functional entity selects the more secure SHA256 as the determined PKCE security method based on the methods supported by both parties 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 can be understood that the method information is associated with the authorization type. Among them, the authorization type is the authorization type corresponding to the service API. The method information is used to determine the calling method of the service API. 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 607.

[0295] Optionally, the service discovery 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 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 credential authorization, the service API information sent by the API information function entity may not include the OAuth authorization type. It is understandable that when the service API information does not include the OAuth authorization type, the default OAuth authorization type is client credential authorization.

[0297] Exemplarily, the API information function entity determines corresponding method information for different service API identifiers according to the association relationship between the API ID and the service API information stored in step 603. The information included in the service discovery response is as follows:

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

[0299] 2. API ID4: Method information includes authorization code authorization and the identification, scope, and PKCE security method of AuF, which 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. The method information may include multiple calling methods, such as client credential authorization, authorization code authorization, and one or more of the proof key PKCE for authorization code exchange. The 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, the API caller receives API ID 1 and the method information is authorization code authorization, then the API caller determines that the calling method of API ID1 is authorization code authorization.

[0305] When the API caller receives multiple method information sent from the API information function entity, one of the calling methods can be selected from the method information according to the local policy, that is, one of the method information is used 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 preferentially selected 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 credential 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 ObtainAuthorization 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 the above step 401), and the subsequent process is the same as step 402-step 410 in method 400. For example, the API caller obtains API ID1 from the API information function entity in step 608, and the authorization type corresponding to API ID1 determined by the API caller is the authorization code authorization method.

[0311] Optionally, the API caller receives an identifier of the authorization function AuF from the API information function entity. The identifier of the AuF is used to indicate the address of the AuF. When the calling method is the authorization code authorization method, a first authorization code is requested from the AuF according to the identifier of the 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 an access token for calling the service API. The scope is used to indicate the scope that the service API allows to be authorized. It should be noted that the identifier and scope of the AuF are obtained according to step 608.

[0312] For example, the API caller obtains the scope of the current request through a 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 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 a 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 step includes: the API caller sends an authorization code request message to the RO client (same as the above step 501), and the subsequent process is the same as step 502-step 510 in method 500. Optionally, the AuF ID and the range are obtained according to step 608. Optionally, the API caller also determines whether the currently requested range belongs to the range obtained from the API information function entity. Among them, code_verifier is generated by the API caller and can be a random number. The API caller can generate code_challenge based on 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 according to code_verifier and the null method. In this case, code_challenge is the same as code_verifier.

[0317] Exemplarily, code_verifier may be a random number, the PKCE security method is SHA256, and the API caller generates code_challenge according to 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 by the API caller when requesting an access token to call the service API. The scope is used to indicate the scope of authorization allowed by the service API. Optionally, the API caller receives a PKCE security method from the API information function entity, and 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 release and use of authorization-related information at the API granularity is realized under the CAPIF architecture, so that the API release function entity can release the service API it supports and the corresponding first information to the API information function entity, and the API caller can obtain the first information of the service API from the API information function entity, so that the API caller can use different OAuth authorization methods for automatic adaptation and processing, and realize service API calls with different authorization methods under the existing CAPIF architecture. For example, for a service API that can access user privacy, by publishing the first information 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.

[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 combining multiple OAuth authorization methods with the API publishing process of CAPIF. The difference from method 600 is that the first information in method 700 is the AEF granularity. AEF is an entry point for service providers to open services to the outside world. Different AEFs can provide different or the same APIs, but because AEF has its own capacity limitations, it may only implement limited authorization methods. Figure 7 This method is introduced.

[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 the present 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. Among them, 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. Among them, the AuF identifier is used to indicate the address of the AuF. Exemplarily, the Uniform Resource Locator (URL) of the AuF can be indicated. 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) and SHA256 (represented by S256). The specific steps for generating a code_challenge can refer to the above step 501, which 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 where the authorization type is authorization code authorization, the AEF information may include the AuF identifier and scope, that is, 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 combined together. In the case where the AuF and API information functional entities are combined, the AEF information may not include the AuF identifier.

[0331] In a possible implementation, the service API publishing request message includes multiple AEF identifiers 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 functional entity sends a response message to the API publishing functional 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 can be understood that if the API information function entity receives the above 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 determines that the AEF information can be stored, then the API publishing function entity is notified of the successful release of the AEF information by publishing the result of the response. If the API information function entity fails to successfully receive the above AEF information or fails to store it successfully (for example, the configuration authority is limited, etc.), then the API publishing function entity is notified of the failure of the AEF information release by publishing the result of the 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 function entity stores AEF ID1, authorization code authorization, AuF identifier and scope together in an associated manner. Associated storage can be understood as the API information function entity being able to determine the first information through the AEF ID. For example, the AEF ID and the first information can be saved as a corresponding relationship; or it can be expressed as storing the AEF ID and the first information separately, and establishing an index between the AEF ID and the first information. For example, the authorization code authorization, AuF identifier and scope corresponding to the AEF can be determined later through AEF ID1.

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

[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 AEF ID4, authorization code authorization, PKCE, AuF identification, scope, and PKCE security method together.

[0347] 5. AEF ID5: The API information functional entity associates and stores the AEF ID5, client credential authorization, and 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 publish 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 publish response message.

[0349] Step 704: The API caller sends a security method request (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. Among them, the identifier of the AEF is used to indicate the AEF that the API caller may interact with. 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. Among them, 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 function entity obtains method information according to the authorization type, where 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 functional entity may directly use the authorization type corresponding to the AEF as the 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 functional entity obtains the AEF information corresponding to the AEF ID1 according to the AEF identifier AEF ID1, including the associated authorization type, that is, the authorization code authorization. The API information functional entity uses the authorization code authorization as method information.

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

[0360] Optionally, the API information function entity selects method information according to 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 identifier of the AEF, 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 according to the AEF identifier AEF ID1, which includes the associated authorization type, namely, authorization code authorization. The capability information indicates that the API caller supports authorization code authorization, and the API information functional entity selects authorization code authorization as the method information according to the method supported by both parties.

[0363] Exemplarily, the API information functional entity obtains the AEF information corresponding to AEF ID4 according to 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 according to the method supported by both parties.

[0364] Exemplarily, the API information functional entity obtains the AEF information corresponding to the AEF ID5 according to the AEF identifier AEF ID5, 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, and the API information functional entity selects client credential authorization and PKCE as the method information according to the method supported by both parties.

[0365] Exemplarily, the API information functional entity obtains the AEF information corresponding to AEF ID4 according to the AEF identifier AEF ID4, which includes the associated authorization type, 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 higher priority and more secure PKCE as the method information according to 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 according to 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 method that they both support, 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 methods 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 functional 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 functional entity selects PKCE as the method information according to the identification of AEF as AEF ID4 and with reference to the above method. The PKCE security methods corresponding to AEF ID4 include null and SHA256. The PKCE security methods supported by the API caller include SHA256, and the API information functional entity selects SHA256 as the determined PKCE security method according to the method supported by both parties.

[0370] Exemplarily, the API information functional entity selects PKCE as the method information according to the AEF ID4 identified by AEF and referring to the above method. The PKCE security methods corresponding to AEF ID4 include null and SHA256. The PKCE security methods supported by the API caller include null and SHA256. The API information functional entity selects SHA256 with higher priority and greater security as the determined PKCE security method according to the methods and priority list supported by both parties.

[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 MethodResponse) message to the API caller.

[0373] Optionally, the security method response message includes method information. It can be understood that the method information is associated with the authorization type. Among them, 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, it also includes a security method. Exemplary security methods may include TLS-PSK method, TLS-PKI method, and TLSwith 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 relevant description of the discovery service request, please refer to the description of step 303, which will not be repeated here.

[0377] Optionally, the service discovery request message may further include capability information of the API caller. The capability information of the API caller may refer 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 described in detail here.

[0381] Optionally, the method information in step 706, the AuF identifier, the scope, and one or more of the determined PKCE security methods 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 functional 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 through step 706, and then sends the service API information to the API caller through 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] Among them, the method information is the method information received by the API caller from the API information function entity. The 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. The method information corresponds to the AEF identifier. At the same time, 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 certain service API, and the service API information includes a corresponding AEF identifier, and the AEF information corresponding to the AEF includes a corresponding method information, the API caller determines the method information as the calling method of the service API. Optionally, when the service discovery response message of step 608 does not include method information, the API caller determines that the calling method of 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 AEFID2, 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, one of the calling methods can be selected from the method information according to the local policy, that is, one of the method information is used 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 preferentially selected when certain conditions are met, for example, PKCE is preferentially selected, which is not limited in this embodiment. For example, the priority list can be PKCE in the order of priority, 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.

[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 AEFID4, AEF ID 4 and the method information in the AEF information are authorization code authorization and PKCE, and the API caller's preconfigured 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, then 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 refers to the above step 609, which will not be repeated here.

[0397] Through the process of method 700, the release and use of the first information of AEF granularity is realized in CAPIF, so that the API release function entity can release the API it supports and the authorization method corresponding to AEF to the API information function entity, and the API caller obtains the method information corresponding to AEF through the API information function entity, so that the API caller can use different OAuth authorization methods for automatic adaptation and processing, so that service API calls with different authorization methods can be implemented under the existing CAPIF architecture. For example, for a service API that can access user privacy, the service API is provided by AEF, and the first information corresponding to the AEF is released as 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.

[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, wherein the first information at an API granularity corresponds to method 600, and the first information at an AEF granularity corresponds to method 700. Based on methods 600 and 700, when the first information corresponding to the service API / AEF is updated, the API information function entity also updates the first information corresponding to the service API / AEF, thereby ensuring that the published service API / AEF information is the latest. Figure 8 This method is introduced.

[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 the second information of the service API. It should be noted that before the API publishing functional entity sends the identifier and the second information of the service API to the API information functional entity, it also sends the identifier and the 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 can be 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 is used to indicate that the information corresponding to the service API is updated. Exemplary reason values ​​include target address change, authorized scope change, authorization method change, 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 can be understood that when the API information function entity receives two messages about API ID1, the first message is the first message, the second message is the second message, and the first message and the second message are different, it determines that the first message corresponding to API ID1 is updated to the second message. The judgment method of AEF information is the same as that of service API information, which will not be repeated here.

[0406] In one implementation, the second information may be a change in the authorization type compared to the first information. Exemplarily, the first information corresponding to API ID1 is the authorization code authorization, the identification and scope of AuF. Subsequently, the API information function entity receives the second information corresponding to API ID1, which is the authorization code authorization and the identification and scope of PKCE and AuF. Another implementation is that the second information corresponding to API ID1 is the identification and scope of PKCE and AuF.

[0407] In another implementation, the second information may be a change in information other than the authorization type in the API information compared to the first information. Exemplarily, the first information corresponding to API ID1 is authorization code authorization, AuF identifier and scope, wherein the AuF identifier is AuF ID1, and the scope is to allow access to user avatar and location information. Subsequently, the API information function entity receives the second information corresponding to the API ID, which is authorization code authorization, AuF identifier and scope, wherein the AuF identifier is AuFID2, and the scope is to allow access to user avatar.

[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 the AEF identifier.

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

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

[0412] The service API update response message includes a result, wherein the result is used to indicate whether the update is successful or failed.

[0413] Step 804 (optional): If the API caller subscribes to the API change event to the API information functional entity, the API information functional 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 that the API caller is accessing 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, which will not be 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 API callers using old service API information to call the service API resulting in call failures, thereby enabling API callers to use different OAuth authorization methods for automatic adaptation and processing.

[0418] Fig. 9 An exemplary flow chart of a method 900 provided in the present application is shown, and the method 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 a possible implementation, the API publishing function entity sends a service API publishing request message to the API information function entity. The service API publishing request message includes the identifier of the service API and the first information. (For details, please refer to step 601 in method 600).

[0421] In another possible implementation, the API publishing function entity sends a request message to the API information function entity, wherein the request message includes the identifier of the AEF and the first information. (For details, please refer to step 701 in method 700).

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

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

[0424] S902, the API information function entity stores the identifier and first information of the service API.

[0425] In a possible implementation, the API information function entity stores service API information, and the service API information includes an identifier of the service API and first information. (For details, please 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, 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, 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, refer to step 704 in method 700).

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

[0433] In a 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 according to the capability information and the authorization type. (For details, please refer to step 607 in method 600).

[0434] In another possible implementation, the API information functional entity may directly use the authorization type corresponding to the AEF as the method information. Alternatively, the API information functional 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. The service discovery response message includes method information (for details, 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. 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 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 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, the API information functional entity and the 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 may 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, API publishing functional entity, etc. 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 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 an integrated unit, Fig.10 A possible exemplary block diagram of a device involved in an embodiment of the present application is shown. The device 1000 may exist in the form of software, hardware, or a combination of software and hardware. Fig.10 A possible schematic block diagram of the device involved in the embodiments of the present application is shown. 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 the 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] Fig.10 The device 1000 shown may be an API caller, an API information functional entity or an API publishing functional entity involved in an embodiment of the present application.

[0445] when Fig.10 When the device 1000 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 method examples. For example, the processing unit 1002 can support the device 1000 to perform Figure 6 Step 609 in Figure 7 Step 709 in Figure 8The communication unit 1003 can support the communication between the device 1000 and the API information function entity or the API publishing function entity, for example, the communication unit 1003 supports the device 1000 to perform Figure 3 Steps 301 to 309 in Figure 4 Steps 406 to 408 in Figure 5 Steps 506 to 508 in Figure 6 Steps 601 to 602, steps 604 to 606, and step 608, Figure 7 Steps 701 to 702, step 704, and steps 706 to 708 in Figure 8 Step 801 and steps 803-804, and / or other related communication processes.

[0446] when Fig.10 When the device 1000 is an API publishing functional entity, the communication unit 1003 can support the communication between the device 1000 and the API caller or the API information functional entity, for example, the communication unit 1003 supports the device 1000 to execute Figure 3 Steps 301 to 306 in Figure 4 Steps 406 and 408 in Figure 5 Steps 506 and 508 in Figure 6 Steps 604 to 606 and step 608, Figure 7 Step 704 and steps 706 to 708 in Figure 8 Step 801 in, and / or other related communication processes.

[0447] when Fig.10 When the device 1000 is an API information functional entity, the processing unit 1002 can support the device 1000 to perform the actions performed by the API information functional entity in the above method examples. For example, the processing unit 1002 supports the device 1000 to perform Figure 6 Step 603 and step 607 in Figure 7 Step 703 and step 705 in Figure 8 The communication unit 1003 can support the communication between the device 1000 and the API caller or API publishing function entity, for example, the communication unit 1003 supports the device 1000 to perform Figure 3 Steps 301 to 306 in Figure 4 Step 407 in Figure 5 Step 507, Figure 6 Steps 601 to 602, steps 604 to 606, and step 608, Figure 7Steps 701 to 702, step 704, and steps 706 to 708 in Figure 8 Steps 801 and 804, and / or other related communication processes.

[0448] Exemplarily, the processing unit 1002 may be a processor or a controller, for example, a central processing unit (CPU), a general processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic devices, transistor logic devices, hardware components or any combination thereof. It may implement or execute various exemplary logic blocks, units and circuits described in conjunction with the disclosure of the present application. The processor may also be a combination that implements a computing function, for example, including 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, and 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 can be Fig.11 The device 1100 is shown.

[0450] See also Fig.11 As shown, the device 1100 includes: a processor 1102 and a communication interface 1103. Further, 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, etc. The bus 1104 may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Fig.11 Only one thick line is used in the diagram, but this does not mean that there is only one bus or only one type of bus.

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

[0452] For example, Fig.11 The device 1100 shown may be an API caller, an API information functional entity or an API publishing functional entity involved in an embodiment of the present application.

[0453] When the device 1100 is an API caller, the processor 1102 can execute the actions completed by the API caller in the above-mentioned method examples by running or executing the program stored in the memory 1101. When the device 1100 is an API information functional entity, the processor 1102 can execute the actions completed 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 device 1100 is an API publishing functional entity, the processor 1102 can perform the actions of the API publishing functional entity in the above-mentioned method examples by running or executing the program stored in the memory 1101.

[0455] The steps of the method or algorithm described in conjunction with the disclosed content of the embodiments of the present application can be implemented in a hardware manner, or can be implemented by a processor executing software instructions. The software instructions can be composed of corresponding software modules, and the software modules can be stored in a random access memory (Random Access Memory, RAM), a flash memory, a read-only memory (Read Only Memory, ROM), an erasable programmable read-only memory (Erasable Programmable ROM, EPROM), an electrically erasable programmable read-only memory (Electrically EPROM, EEPROM), a register, a hard disk, a mobile hard disk, a read-only compact disk (CD-ROM) or any other form of storage medium known in the art. An exemplary storage medium is coupled to a processor so that the processor can read information from the storage medium and can write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and the 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 the storage medium can also be present as discrete components in an API caller, an API information functional entity, or an API publishing functional entity.

[0456] Those skilled in the art should be aware that in one or more of the above examples, the functions described in the embodiments of the present application can be implemented with 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 the communication media include any media that facilitates the transmission of a computer program from one place to another. The storage medium can be any available medium that a general or special-purpose computer can access.

[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 the specific implementation method of the embodiments of the present application and is not intended to limit the protection scope of the embodiments of the present application. Any modifications, equivalent substitutions, improvements, etc. made on the basis of the technical solutions of the embodiments of the present application should be included in the protection scope 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