Apparatus, computer program and method

Abstract

An apparatus comprising means for: receiving, from a first Application Programming Interface, API, Exposing Function, AEF, a request to access a second AEF, wherein the request comprises a Client Credentials Assertion, CCA, token signed by an API invoker and a first access token of the API invoker for the first AEF; authenticating the API invoker using the CCA token; generating a second access token for the first AEF to access a service of the second AEF.

Description

[0001] APPARATUS, COMPUTER PROGRAM AND METHOD

[0002] TECHNICAL FIELD

[0003] Various example embodiments relate generally to authentication.

[0004] BACKGROUND

[0005] A nested API invocation scenario is a scenario where an API invocation towards a first API exposing function triggers that API exposing function to request an API invocation towards a second API exposing function. This is described in 3GPP TS 23.222. Each API exposing function may be in the same API provider domain as the first API exposing function.

[0006] BRIEF DESCRIPTION

[0007] According to an aspect of the invention, there is provided an apparatus comprising means for: receiving, from a first Application Programming Interface, API, Exposing Function, AEF, a request to access a second AEF, wherein the request comprises a Client Credentials Assertion, CCA, token signed by an API invoker and a first access token of the API invoker for the first AEF; authenticating the API invoker using the CCA token; generating a second access token for the first AEF to access a service of the second AEF.

[0008] According to some examples, the means are further configured for: sending the second access token to the first AEF.

[0009] According to some examples, the means are further configured for: receiving a discovery request from the API invoker; sending, to the API invoker, information identifying the first AEF and an indication to provide a CCA token when accessing the first AEF.

[0010] According to some examples, the means are further configured for: receiving a request for the first access token from the API invoker for the first AEF, the request comprising an identifier of the first AEF; sending the first access token to the API invoker.

[0011] According to some examples, the apparatus comprises a Common API Framework Core Function, CCF.

[0012] According to some examples, the CCA token includes an identifier of the API invoker, a timestamp, an expiration time, and at least one of: an address of the apparatus; and address of the first AEF.

[0013] According to some examples, the CCA token includes an identifier of at least one resource that the API invoker is requesting to access. According to some examples, the CCA token includes: an X.509 URL (x5u) referring to a resource for the X.509 public key certificate or certificate chain used by the API invoker for signing the CCA token; or an X.509 Certificate Chain (x5c) including the X.509 public key certificate or certificate chain used by the API invoker for signing the CCA token.

[0014] According to an aspect of the invention, there is provided a method comprising: receiving, from a first Application Programming Interface, API, Exposing Function, AEF, a request to access a second AEF, wherein the request comprises a Client Credentials Assertion, CCA, token signed by an API invoker and a first access token of the API invoker for the first AEF; authenticating the API invoker using the CCA token; generating a second access token for the first AEF to access a service of the second AEF.

[0015] According to some examples, the method comprises: sending the second access token to the first AEF.

[0016] According to some examples, the method comprises: receiving a discovery request from the API invoker; sending, to the API invoker, information identifying the first AEF and an indication to provide a CCA token when accessing the first AEF.

[0017] According to some examples, the method comprises: receiving a request for the first access token from the API invoker for the first AEF, the request comprising an identifier of the first AEF; sending the first access token to the API invoker.

[0018] According to some examples, the method is performed by a Common API Framework Core Function, CCF.

[0019] According to some examples, the CCA token includes an identifier of the API invoker, a timestamp, an expiration time, and at least one of: an address of the apparatus; and address of the first AEF.

[0020] According to some examples, the CCA token includes an identifier of at least one resource that the API invoker is requesting to access.

[0021] According to some examples, the CCA token includes: an X.509 URL (x5u) referring to a resource for the X.509 public key certificate or certificate chain used by the API invoker for signing the CCA token; or an X.509 Certificate Chain (x5c) including the X.509 public key certificate or certificate chain used by the API invoker for signing the CCA token.

[0022] According to an aspect of the invention, there is provided a computer program product embodied on a distribution medium readable by a computer and comprising program instructions which, when loaded into an apparatus, execute a method comprising: receiving, from a first Application Programming Interface, API, Exposing Function, AEF, a request to access a second AEF, wherein the request comprises a Client Credentials Assertion, CCA, token signed by an API invoker and a first access token of the API invoker for the first AEF; authenticating the API invoker using the CCA token; generating a second access token for the first AEF to access a service of the second AEF.

[0023] According to an aspect of the invention, there is provided an apparatus comprising at least one processor and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to perform: receiving, from a first Application Programming Interface, API, Exposing Function, AEF, a request to access a second AEF, wherein the request comprises a Client Credentials Assertion, CCA, token signed by an API invoker and a first access token of the API invoker for the first AEF; authenticating the API invoker using the CCA token; generating a second access token for the first AEF to access a service of the second AEF.

[0024] According to an aspect of the invention, there is provided an apparatus comprising means for: generating a Client Credentials Assertion, CCA, token and signing the CCA token using a private key of the apparatus; sending a service request for a first API Exposing Function, AEF, including the signed CCA token and an access token of the apparatus for the first AEF; receiving a service from the first AEF, wherein the first AEF invokes a service from a second AEF to provide the service from the first AEF to the apparatus.

[0025] According to some examples, the means are further configured for: sending a discovery request to a Common API Framework Core Function, CCF; receiving information identifying the first AEF and an indication to provide the signed CCA token when accessing the first AEF.

[0026] According to some examples, the means are further configured for: sending, to the CCF, a request for the access token for the first AEF, the request comprising an identifier of the first AEF; receiving, from the CCF, the access token.

[0027] According to some examples, the apparatus comprises a user equipment.

[0028] According to some examples, the signed CCA token includes an identifier of the apparatus a timestamp, an expiration time, and at least one of: an address of the CCF; and address of the first AEF.

[0029] According to some examples, the signed CCA token includes an identifier of at least one resource that the API invoker is requesting to access.

[0030] According to some examples, the signed CCA token includes: an X.509 URL (x5u) referring to a resource for the X.509 public key certificate or certificate chain used by the apparatus for signing the CCA token; or an X.509 Certificate Chain (x5c) including the X.509 public key certificate or certificate chain used by the apparatus for signing the CCA token. According to an aspect of the invention, there is provided a method comprising: generating a Client Credentials Assertion, CCA, token and signing the CCA token using a private key of the apparatus; sending a service request for a first API Exposing Function, AEF, including the signed CCA token and an access token of the apparatus for the first AEF; receiving a service from the first AEF, wherein the first AEF invokes a service from a second AEF to provide the service from the first AEF to the apparatus.

[0031] According to some examples, the method comprises: sending a discovery request to a Common API Framework Core Function, CCF; receiving information identifying the first AEF and an indication to provide the signed CCA token when accessing the first AEF.

[0032] According to some examples, the method comprises: sending, to the CCF, a request for the access token for the first AEF, the request comprising an identifier of the first AEF; receiving, from the CCF, the access token.

[0033] According to some examples, the method is performed by a user equipment.

[0034] According to some examples, the signed CCA token includes an identifier of the apparatus a timestamp, an expiration time, and at least one of: an address of the CCF; and address of the first AEF.

[0035] According to some examples, the signed CCA token includes an identifier of at least one resource that the API invoker is requesting to access.

[0036] According to some examples, the signed CCA token includes: an X.509 URL (x5u) referring to a resource for the X.509 public key certificate or certificate chain used by the apparatus for signing the CCA token; or an X.509 Certificate Chain (x5c) including the X.509 public key certificate or certificate chain used by the apparatus for signing the CCA token.

[0037] According to an aspect of the invention, there is provided a computer program product embodied on a distribution medium readable by a computer and comprising program instructions which, when loaded into an apparatus, execute a method comprising: generating a Client Credentials Assertion, CCA, token and signing the CCA token using a private key of an apparatus; sending a service request for a first API Exposing Function, AEF, including the signed CCA token and an access token of the apparatus for the first AEF; receiving a service from the first AEF, wherein the first AEF invokes a service from a second AEF to provide the service from the first AEF to the apparatus.

[0038] According to an aspect of the invention, there is provided an apparatus comprising at least one processor and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to perform: generating a Client Credentials Assertion, CCA, token and signing the CCA token using a private key of an apparatus; sending a service request for a first API Exposing Function, AEF, including the signed CCA token and an access token of the apparatus for the first AEF; receiving a service from the first AEF, wherein the first AEF invokes a service from a second AEF to provide the service from the first AEF to the apparatus.

[0039] According to an aspect of the invention, there is provided an apparatus comprising means for: receiving, from an Application Programming Interface, API, invoker a service request for a first API Exposure Function, AEF, wherein the request comprises a Client Credentials Assertion, CCA, token signed by the API invoker and a first access token of the API invoker for the apparatus; sending, to a Common API Framework Core Function, CCF, a request to access a second AEF, wherein the request comprises the CCA token signed by the API invoker and the first access token.

[0040] According to some examples, the means are further configured for: receiving, from the CCF, a second access token for the apparatus to access a service of the second AEF.

[0041] According to some examples, the means are further configured for: sending, to the second AEF, a service request comprising the second access token and the CCA token signed by the API invoker; receiving a service from the second AEF; providing a service to the API invoker using the service of the second AEF.

[0042] According to some examples, the apparatus comprises a first AEF.

[0043] According to some examples, the signed CCA token includes an identifier of the API invoker, a timestamp, an expiration time, and at least one of: an address of the apparatus; and address of the first AEF.

[0044] According to some examples, the signed CCA token includes an identifier of at least one resource that the API invoker is requesting to access.

[0045] According to some examples, the signed CCA token includes: an X.509 URL (x5u) referring to a resource for the X.509 public key certificate or certificate chain used by the API invoker for signing the CCA token; or an X.509 Certificate Chain (x5c) including the X.509 public key certificate or certificate chain used by the API invoker for signing the CCA token.

[0046] According to an aspect of the invention, there is provided a method comprising: receiving, from an Application Programming Interface, API, invoker a service request for a first Application Exposure Function, AEF, wherein the request comprises a Client Credentials Assertion, CCA, token signed by the API invoker and a first access token of the API invoker for an apparatus; sending, to a Common API Framework Core Function, CCF, a request to access a second AEF, wherein the request comprises the CCA token signed by the API invoker and the first access token. According to some examples, the method comprises: receiving, from the CCF, a second access token for the apparatus to access a service of the second AEF.

[0047] According to some examples, the method comprises: sending, to the second AEF, a service request comprising the second access token and the CCA token signed by the API invoker; receiving a service from the second AEF; providing a service to the API invoker using the service of the second AEF.

[0048] According to some examples, the method is performed by a first AEF.

[0049] According to some examples, the signed CCA token includes an identifier of the API invoker, a timestamp, an expiration time, and at least one of: an address of the apparatus; and address of the first AEF.

[0050] According to some examples, the signed CCA token includes an identifier of at least one resource that the API invoker is requesting to access.

[0051] According to some examples, the signed CCA token includes: an X.509 URL (x5u) referring to a resource for the X.509 public key certificate or certificate chain used by the API invoker for signing the CCA token; or an X.509 Certificate Chain (x5c) including the X.509 public key certificate or certificate chain used by the API invoker for signing the CCA token.

[0052] According to an aspect of the invention, there is provided a computer program product embodied on a distribution medium readable by a computer and comprising program instructions which, when loaded into an apparatus, execute a method comprising: receiving, from an Application Programming Interface, API, invoker a service request for a first API Exposure Function, AEF, wherein the request comprises a Client Credentials Assertion, CCA, token signed by the API invoker and a first access token of the API invoker for the apparatus; sending, to a Common API Framework Core Function, CCF, a request to access a second AEF, wherein the request comprises the CCA token signed by the API invoker and the first access token.

[0053] According to an aspect of the invention, there is provided an apparatus comprising at least one processor and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to perform: receiving, from an Application Programming Interface, API, invoker a service request for a first API Exposure Function, AEF, wherein the request comprises a Client Credentials Assertion, CCA, token signed by the API invoker and a first access token of the API invoker for the apparatus; sending, to a Common API Framework Core Function, CCF, a request to access a second AEF, wherein the request comprises the CCA token signed by the API invoker and the first access token. According to an aspect of the invention, there is provided an apparatus comprising means for: receiving, from a first Application Programming Interface, API, Exposing Function, AEF, a service request comprising a Client Credentials Assertion, CCA, token signed by an API invoker and an access token of the first AEF for a second AEF; authenticating the API invoker using the signed CCA token and validating the signed CCA token and access token.

[0054] According to some examples, the validating the signed CCA token and access token comprises validating that an identifier of the API invoker in the signed CCA token and an identifier of the API invoker in the access token are the same.

[0055] According to some examples, the means are further configured for: providing a service to the first AEF.

[0056] According to some examples, the apparatus comprises a second AEF.

[0057] According to some examples, the signed CCA token includes an identifier of the API invoker, a timestamp, an expiration time, and at least one of: an address of the apparatus; and address of the first AEF.

[0058] According to some examples, the signed CCA token includes an identifier of at least one resource that the API invoker is requesting to access.

[0059] According to some examples, the signed CCA token includes: an X.509 URL (x5u) referring to a resource for the X.509 public key certificate or certificate chain used by the API invoker for signing the CCA token; or an X.509 Certificate Chain (x5c) including the X.509 public key certificate or certificate chain used by the API invoker for signing the CCA token.

[0060] According to an aspect of the invention, there is provided a method comprising: receiving, from a first Application Programming Interface, API, Exposing Function, AEF, a service request comprising a Client Credentials Assertion, CCA, token signed by an API invoker and an access token of the first AEF for a second AEF; authenticating the API invoker using the signed CCA token and validating the signed CCA token and access token.

[0061] According to some examples, the validating the signed CCA token and access token comprises validating that an identifier of the API invoker in the signed CCA token and an identifier of the API invoker in the access token are the same.

[0062] According to some examples, the method comprises: providing a service to the first AEF.

[0063] According to some examples, the method is performed by a second AEF. According to some examples, the signed CCA token includes an identifier of the API invoker, a timestamp, an expiration time, and at least one of: an address of the apparatus; and address of the first AEF.

[0064] According to some examples, the signed CCA token includes an identifier of at least one resource that the API invoker is requesting to access.

[0065] According to some examples, the signed CCA token includes: an X.509 URL (x5u) referring to a resource for the X.509 public key certificate or certificate chain used by the API invoker for signing the CCA token; or an X.509 Certificate Chain (x5c) including the X.509 public key certificate or certificate chain used by the API invoker for signing the CCA token.

[0066] According to an aspect of the invention, there is provided a computer program product embodied on a distribution medium readable by a computer and comprising program instructions which, when loaded into an apparatus, execute a method comprising: receiving, from a first Application Programming Interface, API, Exposing Function, AEF, a service request comprising a Client Credentials Assertion, CCA, token signed by an API invoker and an access token of the first AEF for a second AEF; authenticating the API invoker using the signed CCA token and validating the signed CCA token and access token.

[0067] According to an aspect of the invention, there is provided an apparatus comprising at least one processor and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to perform: receiving, from a first Application Programming Interface, API, Exposing Function, AEF, a service request comprising a Client Credentials Assertion, CCA, token signed by an API invoker and an access token of the first AEF for a second AEF; authenticating the API invoker using the signed CCA token and validating the signed CCA token and access token.

[0068] Some embodiments of the invention are defined in the dependent claims.

[0069] LIST OF THE DRAWINGS

[0070] In the following, the invention will be described in greater detail with reference to the embodiments and the accompanying drawings, in which

[0071] Fig. 1 shows an example of a communication network to which examples disclosed herein may be applied;

[0072] Fig. 2 shows an example procedure for obtaining authorization information;

[0073] Fig. 3 shows a second example procedure for obtaining authorization information;

[0074] Fig. 4 shows an example of a method; Fig. 5 shows an example of a method;

[0075] Fig. 6 shows an example of a method;

[0076] Fig. 7 shows an example of a method; and

[0077] Fig. 8 shows an example of an apparatus.

[0078] DESCRIPTION OF EMBODIMENTS

[0079] The following embodiments are exemplary. Although the specification may refer to “an”, “one”, or “some” embodiment(s) in several locations of the text, this does not necessarily mean that each reference is made to the same embodiment(s), or that a particular feature only applies to a single embodiment. Single features of different embodiments may also be combined to provide other embodiments. Further, when a particular feature, structure, or characteristic is described in connection of an embodiment, it is within the knowledge of one skilled in the art to apply such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described. It shall be understood that although the terms “first,” “second” and the like may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another.

[0080] For the purposes of the present disclosure, the phrases “at least one of A or B”, “at least one of A and B”, and “A and / or B” means (A), (B), or (A and B). For the purposes of the present disclosure, the phrase “A, B, and / or C” means (A), (B), (C), (A and B), (A and C), (B and C), or (A, B, and C).

[0081] Embodiments described may be implemented in a communication network, such as any of the following radio access technologies (RATs): Worldwide Interoperability for Micro-wave Access (WiMAX), Global System for Mobile communications (GSM, 2G), GSM EDGE radio access Network (GERAN), General Packet Radio Service (GRPS), Universal Mobile Telecommunication System (UMTS, 3G) based on basic wideband-code division multiple access (W-CDMA), high-speed packet access (HSPA), Long Term Evolution (LTE), LTE-Advanced, and enhanced LTE (eLTE), 5G (also called NR), or any future RAT such as 6G. Moreover, communication within the communication network may utilize any proper wireless communication technology, comprising but not limited to: Code Division Multiple Access (CDMA), Frequency Division Multiple Access (FDMA), Time Division Multiple Access (TDMA), Frequency Division Duplex (FDD), Time Division Duplex (TDD), Multiple-Input Multiple-Output (M1M0), Orthogonal Frequency Division Multiple (OFDM), and / or Discrete Fourier Transform spread OFDM (DFT-s-OFDM). As used herein, the term “network device” or “network node” refers to a node in a communication network via which user equipment may access the network and / or which is capable of controlling radio communication and managing radio resources within a cell. The network node or network device may be referred to as a base station (BS), an access point (AP) or an access node. The network device may be, depending on the applied technology, for example, a node B (NodeB or NB), an evolved NodeB (eNodeB or eNB), an NR NB (also referred to as a gNB), a Remote Radio Unit (RRU), a radio head (RH), a remote radio head (RRH), a relay, an Integrated Access and Backhaul (1AB) node, a low power node, a nonterrestrial network (NTN) or non-ground network device such as a satellite network device, a low earth orbit (LEO) satellite and a geosynchronous earth orbit (GEO) satellite, or an aircraft network device.

[0082] Moreover, in connection of split radio access network (RAN), the network device may refer to a centralised unit (CU) of a base station and / or a distributed unit (DU) of a base station. An interface between CU and DU may be referred to as an Fl interface in NR. In the split RAN architecture, node operations may be carried out, at least partly, in the cen- tral / centralized unit, CU, (e.g. server, host or node) operationally coupled to the DU, (e.g. a radio head / node). One CU may control one or more DUs, acting at least as transmit / receive (Tx / Rx) nodes. In some embodiments, the DUs may comprise e.g. a radio link control (RLC), medium access control (MAC) layer and a physical (PHY) layer, whereas the CU may comprise the layers above RLC layer, such as a packet data convergence protocol (PDCP) layer, a radio resource control (RRC) and an internet protocol (IP) layers. Other functional splits are possible too. In practice, any processing task may be performed in either the CU or the DU andthe boundary where the responsibility is shifted between the CU and the DU may depend on the applied implementation.

[0083] The term “terminal device” refers to any end device that may be capable of wireless communication. By way of example, a terminal device may be referred to as a communication device, user equipment (UE), a Subscriber Station (SS), or a Mobile Station (MS). The terminal device may include a mobile phone, a cellular phone, a smart phone, voice over IP (VoIP) phones, wireless local loop phones a tablet, a wearable terminal device, a personal digital assistant (PDA), portable computers, desktop computer, image capture terminal devices such as digital cameras, gaming terminal devices, music storage and playback appliances, vehicle-mounted wireless terminal devices, USB dongles, an Internet of Things (loT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot and / or other wireless devices operating in an industrial and / or an automated processing chain contexts), a consumer electronics device, a device operating on commercial and / or industrial wireless networks, and the like.

[0084] A term “resource”, as used herein, may refer to radio resources in time domain, in frequency domain, in space domain, and / or in code domain. Some examples of resources include e.g. a physical resource block (PRE), a radio frame, a subframe, a time slot, a subband, a frequency region, a sub-carrier, a beam, etc. The term “transmission” and / or “reception” may refer to wirelessly transmitting and / or receiving via a wireless propagation channel on radio resources.

[0085] Fig. 1 illustrates an example of a communication network to which examples disclosed herein may be applied. The communication network or a cellular communication network may comprise a network node 110 providing one or more cells, such as cell 100, and a network node 112 providing one or more other cells, such as cell 102. Each cell may be, e.g., a macro cell, a micro cell, femto, or a pico cell, for example. The cell may define a coverage area or a service area of the corresponding access node.

[0086] The network node 110 may provide a user equipment (UE) 120 (one or more UEs) with wireless access to the communication network. The wireless access may comprise downlink (DL) communication from the network node to the UE 120 and uplink (UL) communication from the UE 120 to the network node. Examples of uplink channels comprise physical uplink control channel (PUCCH) for transmitting control information and physical uplink shared channel (PUSCH) for transmitting data towards the network. Examples of downlink channels comprise physical downlink control channel (PDCCH) for transmitting control information and physical downlink shared channel (PDSCH) for transmitting data towards the user equipment.

[0087] There may be a plurality of UEs 120, 122 in the system. Each of them may be served by the same or by different network nodes 110, 112. UE may be configured with dual connectivity (DC), wherein the UE, e.g. UE 120, may be connected to multiple network nodes 110, 112. The UEs 120, 122 may communicate with each other, in case device-to-device (D2D) communication interface is established between them via a so-called sidelink (SL). Such D2D communications may be referred to as machine-to-machine, peer-to-peer (P2P) communications, or vehicle-to-vehicle (V2V), for example.

[0088] In the case of multiple network nodes in the communication network, the network nodes may be connected to each other via an interface. LTE specifications call such an interface as X2 interface. An interface between an LTE node and a 5G node, or between two 5G nodes may be called Xn interface.

[0089] The network nodes 110 and 112 may be further connected via another interface to a core network 116 of the communication network. The LTE specifications specify the core network as an evolved packet core (EPC), and the core network may comprise e.g. a mobility management entity (MME) and a gateway node. The MME may handle mobility of terminal devices in a tracking area encompassing a plurality of cells and handle signalling connections between the terminal devices and the core network. The gateway node may handle data routing in the core network and to / from the terminal devices. The 5G specifications specify the core network as a 5G core (5GC). The 5G core may comprise e.g. an access and mobility management function (AMF) and a user plane function / gateway (UPF) and other functions. The AMF may handle termination of non-access stratum (NAS) signalling, NAS ciphering & integrity protection, registration management, connection management, mobility management, access authentication and authorization, security context management. The UPF node may support packet routing and forwarding, packet inspection and quality of service (QoS) handling, for example.

[0090] A nested API invocation may occur when a service API may require the services of other service APIs. For example, if the API invoker invokes SEAL SS_Locationlnfo Retrieval API (as described in clause 9.4.4 of TS 23.434), the location management server (acting as an API exposing function for an API invoker and as an API invoker for the Network Exposure Function (NEF)) may invoke NEF API to retrieve UE location information from 5GC. In this scenario, a Common API Framework (CAP1F) may reduce the authorization information inquiries for a nested API invocation using procedure described in FIG. 2.

[0091] FIG. 2 shows an example procedure for obtaining authorization information in a nested API invocation, where AEF 230 receiving the service API invocation request interacts with another AEF 232 to provide the service.

[0092] In some examples, AEF 230 and AEF 232 are in a same trust domain.

[0093] API invoker 224 may be able to communicate with API invoker 224. The API invoker may comprise a device, such as a UE.

[0094] At 201, API invoker 224 requests authorization information to invoke a service API exposed by AEF 230. The authorization information may comprise an access token. This request may involve resource owner function 226 and / or CAP1F core function (CCF) 228. The resource owner function can be involved depending on whether Resource owner-aware Northbound API Access (RNAA) is executed. API invoker may get authorization information (e.g., an access token) from CCF 228 to invoke the API service of AEF 2 232. AEF 2 232 may be in the same API provider domain as AEF 1 230.

[0095] At 203, API invoker 224 sends, to AEF 1230 a service API invocation request with the authorization information (e.g., an access token) received at 201.

[0096] At 205, based on the service API invocation request, AEF 1 230 determines to invoke another service API exposed by AEF 2 232.

[0097] At 207, AEF 1 230, acting as an API invoker, obtains from CCF 228 the authorization information to access the service API exposed by API exposing function 2 232.

[0098] To obtain the authorization information further interaction with the API invoker can be avoided if API exposing function 1 230 exchanges the authorization information provided in the API invoker's request (in 203) with authorization information for accessing to access the service API exposed by API exposing function 2 230. For example, a token exchange method may be used at 207. At 205, AEF 1230 can invoke the token end point of CCF 228 for token exchange. AEF 1 230 can send an access token received at 203 as the subject token to CCF 228. After token verification and access policy control, CCF 228 can issue a new access token to be used by AEF 1 230. The newly issued token includes the API invoker ID in the client id claim and optionally may include the AEF 1230 ID in the act claim. If the subject token includes the resOwnerld claim, CCF 2280decides not to execute RNAA flow and includes that resOwnerld claim in the newly issued token. If the resOwnerld claim is not present in the subject token, then CCF 228 or AEF 230 can decide to execute RNAA flow. After the RNAA flow execution, CCF 228 includes the resOwnerld claim in the newly issued token. If the resOwnerld claim is not present in the subj ect token and the RNAA flow is not executed, then CCF 228 does not include the resOwnerld claim in the newly issued token. The resOwnerld may comprise an identifier, known to CCF 228, of an owner of the resource(s) that API invoker 224 is trying to access. CCF 228 can also include the value in the scope claim of the subject token in the newly issued token. CCF 228 can return the newly issued access token to AEF 1 230 at 207.

[0099] At 209, AEF 1 230, acting as an API invoker for AEF 2 232, sends a service API invocation request to AEF 2 232 with the authorization information (e.g., an access token) received from the CCF at 207.

[0100] After 200, AEF 2 232 can check whether the API invoker is authorized to invoke the requested service API based on the authorization information. AEF 2 232 can also check whether the received access token includes the resOwnerld claim. If the received access token includes the resOwnerld claim, then AEF 2 232 can prefer to not execute any step to get permission from the resource owner. At 211, AEF 2 232 can send a service API invocation response resulting from the service API invocation.

[0101] At 213, AEF 1 230 sends the service API invocation response resulting from the service API invocation to API invoker 224.

[0102] The method of FIG. 2 can be used in a scenario (nested API invocation) where a service API requires the services of other service APIs. To avoid unnecessary interaction with API invoker 224, AEF 1 230 can exchange an access token of the API invoker 224 with the access token of AEF 1 224 to access the API exposed by AEF 2 232.

[0103] In some examples, the method of FIG. 2 can utilize the token exchange procedure specified in RFC 8693. AEF 1 230 assumes the role of actor defined in the RFC. The access token of the API invoker 224 to be used towards AEF 1 230 is used as the subject token. AEF 1 230 invokes the token end point of CCF 228 by sending the subject token to receive a new access token to be used towards AEF 2 232. The solution can use two different types of tokens (CAPIF legacy token and RNAA token) while adjusting the token exchange framework of the RFC to RNAA enhanced CAP1F.

[0104] In the nested API invocation method of FIG. 2, AEF 1 230 exposes API services of another AEF 232. If there is a vulnerability in the optimized authorization procedure for the nested API invocation of FIG. 2, an unauthorized API invoker can consume the API services, potentially resulting in information leakage and / or unauthorized modification to the resources of the resource owner. In the example of FIG. 3 below, the destination AEF (AEF 332) authenticate API invoker 324 and AEF 1 330 before providing authorization for API invoker 324 and AEF 1 330 to access AEF 2 332. This can reduce the likelihood of security vulnerabilities being exploited.

[0105] Some example methods described below use a CCA (Client Credential Assertion token) at CAPIF layer. The CCA is a self-sign token that API invokers need to sign.

[0106] At 351, API invoker 324 and CCF 328 are mutually authenticated. For example, mutual Transport Layer Secuirty (mTLS) may be established.

[0107] At 353, API invoker 324 sends a service discovery request to CCF 328. In some examples, the request may comprise an identifier of an API, for example an apiName. When an API invoker sends a service discovery request to CCF 328, CCF 328 may indicate to API invoker 324 in a service discovery response that a CCA should be included when requesting to use a service later. For example, CCF 328 may indicate to the API invoker 324 that a CCA is required for nested API support. This may be indicated using an “CCA indication” in the service discovery response sent at 355 by CCF 328 to API invoker 324. CCF 328 may also indicate in the response at 355 that nested API invocation is needed at AEF 1 330.

[0108] At 357, API invoker 324 requests an access token for AEF 1 330. At 359, CCF 328 provides the access token to API invoker 324.

[0109] At 361, API invoker 324 may mutually authenticates with the discovered AEF 1 330 and establishes a secure connection.

[0110] At 363, if nested API support indicated during discovery (or via other means), the API invoker generates a client credential assertion token (CCA) including at least one identifier of the API Invoker 324, the address of CCF 328 and in some examples, other information such as the expiry time of the CCA.

[0111] The CCA is a token that is signed by the API Invoker 324. The CCA enables the API invoker to authenticate towards the receiving end point (CCF 328, AEFs 330 and 332) by including the signed token in a service request.

[0112] In some examples, the CCA comprises a JSON Web Token as described in RFC 7519, which in some examples can be secured with digital signatures based on JSON Web Signature (JWS) as described in RFC 7515

[0113] In some examples, the CCA can include:

[0114] • an identifier of API invoker 324 (API Invoker ID). This can be a “subject” of the CCA;

[0115] • a timestamp (“iat”) and an expiration time (“exp”), and

[0116] • a CCF or AEF address in the expected audience (audience). This may be an address of CCF 328 or an address of AEF 1 330;

[0117] • optionally, a resOwnerlD. This can be used in an RNAA scenario.

[0118] The API Invoker 324 may digitally sign the generated CCA based on its private key as described in RFC 7515. The signed CCA may include one of the following fields:

[0119] • the X.509 URL (x5u) to refer to a resource for the X.509 public key certificate or certificate chain used for signing the client authentication assertion, or

[0120] • the X.509 Certificate Chain (x5c) include the X.509 public key certificate or certificate chain used for signing the client authentication assertion.

[0121] The CCA may be signed using a private key of a certificate assigned by CCF 328 to API invoker 324. API invoker may be part of (or all of) a UE, such that a UE can generate the CCA for CAPIF communication.

[0122] At 365, API invoker 324 includes CCA in a service request sent to AEF 1 330. The service request may also include the access token received at 359.

[0123] At 367, AEF 1 300 determine from the service request that AEF 1 330 needs to invoke another service. It then acts as an API invoker to AEF 2 332. As such, at 369 AEF 1 330 requests a second access token on behalf of the origin API invoker 324 by presenting the CCA and the access token previously received by API invoker 324 at 359. The CCA and access token previously received token from 359 can be sent in an access token request to CCF 328. This request can be sent by AEF 1 330 after AEF 1 330 has established mTLS with CCF 328.

[0124] At 371, CCF 328 authenticates API invoker 324 using CCA and authorizes the API invoker 324 and AEF 1 330 by issuing a new access token that can be used by AEF1 330 to access the nested API service from AEF2 332 on behalf of the origin API invoker 324. CCF 328 adds an identifier of the API invoker 324 (APIInvokerlD) in the access token and sends the new access token to AEF 1 330 at 373.

[0125] At 375, AEF 1330 sends a service request to AEF 2 332 including the CCA received from the origin API invoker 324 and the access token received by AEF 1 330 at 373.

[0126] At 377, AEF 2 332 authenticates origin API invoker 324 using the CCA and validates that the API invoker identifier in the CCA is matched with the identifier of the API invoker in the access token.

[0127] At 379, after authentication and validation at 377, AEF 2 332 provides a service to AEF 1 330. AEF 1 330 then provides a service to API invoker 324.

[0128] Fig. 4 shows an example method. The method may be performed by a CCF, such as CCF 328. The method may be performed by an apparatus or system implementing a CCF.

[0129] At 400, the method comprises receiving, from a first AEF, a request to access a second AEF, wherein the request comprises a CCA token signed by an API invoker and a first access token of the API invoker for the first AEF.

[0130] At 402, the method comprises authenticating the API invoker using the CCA token.

[0131] At 404, the method comprises generating a second access token for the first AEF to access a service of the second AEF.

[0132] Fig. 5 shows an example method. The method may be performed by an API invoker, such as API invoker 324. In some examples, API invoker may comprise, or be a part of, a UE.

[0133] At 500, the method comprises generating a CCA token and signing the CCA token using a private key of an apparatus.

[0134] At 502, the method comprises sending a service request for a first AEF including the signed CCA and an access token of the apparatus for the first AEF. The access token may be for the first AEF and be assigned to the apparatus.

[0135] At 504, the method comprises receiving a service from the first AEF, wherein the first AEF invokes a service from a second AEF to provide the service from the first AEF to the apparatus.

[0136] Fig. 6 shows an example method. The method may be performed by an AEF, such as AEF 1 330 for example. The method may be performed by an apparatus or system implementing an AEF.

[0137] At 600, the method comprises receiving, from an API invoker a service request for a first Application Exposure Function, AEF, wherein the request comprises a CCA token signed by the API invoker and a first access token of the API invoker for an apparatus.

[0138] At 602, the method comprises sending, to a CCF a request to access a second AEF, wherein the request comprises the CCA token signed by the API invoker and the first access token.

[0139] Fig. 6 shows an example method. The method may be performed by an AEF, such as AEF 2 332 for example. The method may be performed by an apparatus or system implementing an AEF.

[0140] At 700, the method comprises receiving, from a first AEF, a service request comprising a CCA token signed by an API invoker and an access token of the first AEF for a second AEF. The second AEF may comprise, or be part of, the apparatus. The second AEF may be implemented by the apparatus or a system including the apparatus,.

[0141] At 702, the method comprises authenticating the API invoker using the signed CCA token and validating the signed CCA token and access token.

[0142] Fig. 8 shows, by way of example, a block diagram of an apparatus 10. The apparatus 10 comprises, for example, at least one processor 12 and at least one memory 14 storing instructions 15 that, when executed by the at least one processor, cause the apparatus 10 at least to perform the method or methods as disclosed herein, and any of the embodiments thereof. In an example, the at least one memory and the instructions (e.g. a computer program code, software), are configured, with the at least one processor, to cause the apparatus 10 to perform the method or methods as disclosed herein, and any of the embodiments thereof.

[0143] A processor 12 may comprise circuitry, or be constituted as circuitry or circuitries, the circuitry or circuitries being configured to perform phases of methods in accordance with example embodiments described herein. As used in this application, the term “circuitry” may refer to one or more or all of the following: (a) hardware-only circuit implementations, such as implementations in only analog and / or digital circuitry, and (b) combinations of hardware circuits and software, such as, as applicable: (i) a combination of analog and / or digital hardware circuit(s) with software / firmware and (ii) any portions of hardware processor(s) with software (including digital signal processor(s)), software, and memory(ies) that work together to cause an apparatus, such as a user equipment, to perform various functions) and (c) hardware circuit(s) and or processor(s), such as a microprocessors) or a portion of a microprocessor(s), that requires software (e.g., firmware) for operation, but the software may not be present when it is not needed for operation. This definition of circuitry applies to all uses of this term in this application, including in any claims. As a further example, as used in this application, the term circuitry also covers an implementation of merely a hardware circuit or processor (or multiple processors) or portion of a hardware circuit or processor and its (or their) accompanying software and / or firmware. The term circuitry also covers, for example and if applicable to the particular claim element, a baseband integrated circuit or processor integrated circuit for a mobile device or a similar integrated circuit in server, a cellular network device, or other computing or network device.

[0144] The memory 14 may be implemented using any suitable data storage technology. The memory may comprise a database for storing data. The memory 14 may be at least in part external to apparatus 10 but accessible to apparatus 10.

[0145] The instructions 15 may be comprised in a computer readable medium or a non- transitory computer readable medium. A term non-transitory, as used herein, is a limitation of the medium itself (i.e. tangible, not a signal) as opposed to a limitation on data storage persistency (e.g. random access memory, RAM, vs. read only memory, ROM).

[0146] For example, the apparatus 10 is a terminal device, such as the UE of Fig. 2, 3, 4, 5, 6 or 7. As another example, the apparatus is comprised in such a terminal device, e.g. as a chipset configured to control the terminal device. The apparatus 10 may be caused or configured to perform at least the method of Fig. 5 and / or any one or more of the embodiments described.

[0147] As another example, the apparatus 10 is a network node. In another embodiment, the apparatus is comprised in such a network node, e.g. as a chipset configured to control the network node.

[0148] The apparatus may comprise one or more entities of any of protocol layers, such as a MAC entity, an RRC entity, an RLC entity, a PDCP entity or a PHY entity. In some embodiments, the entity is configured to perform at least the method of Fig. 8 to 12, and / or any one or more of the embodiments described.

[0149] The apparatus 10 comprises a radio interface 16. The radio interface 16 may provide the apparatus 10 with communication capabilities. The radio interface 16 may comprise a receiver configured to receive information in accordance with at least one cellular or non- cellular standard. The radio interface 16 may comprise a transmitter configured to transmit information in accordance with at least one cellular or non-cellular standard. The receiver may comprise more than one receiver. The transmitter may comprise more than one transmitter. The radio interface 16 may comprise a transceiver configured to receive and transmit information in accordance with at least one cellular or non-cellular standard. The transceiver may comprise more than one transceiver.

[0150] The apparatus 10 may comprise a user interface 18 comprising, for example, at least one of a keypad, a microphone, a touch display, a display, a speaker, etc. The user interface 18 may be used to control the apparatus by the user. The user interface 18 may be external to the apparatus 10. For example, the apparatus 10 may be connected to another device, such as a computer, either via wireless or wired connection, and the apparatus 10 is controlled by the user via the computer.

[0151] In an embodiment, at least some of the processes described herein may be carried out by an apparatus comprising means for carrying out at least some of the described processes. Means for performing method steps as disclosed herein may include software and / or hardware components of the apparatus 10. For example, the at least one processor 12, the memory 14, and the computer program code form means for carrying out the method or methods as disclosed herein, and any of the embodiments thereof. As used herein the term “means” is to be construed in singular form, i.e. referring to a single element, or in plural form, i.e. referring to a combination of single elements. Therefore, terminology “means for [performing A, B, C]”, is to be interpreted to cover an apparatus in which there is only one means for performing A, B and C, or where there are separate means for performing A, B and C, or partially or fully overlapping means for performing A, B, C. Further, terminology “means for performing A, means for performing B, means for performing C” is to be interpreted to cover an apparatus in which there is only one means for performing A, B and C, or where there are separate means for performing A, B and C, or partially or fully overlapping means for performing A, B, C.

[0152] Even though the invention has been described above with reference to an example according to the accompanying drawings, it is clear that the invention is not restricted thereto but can be modified in several ways within the scope of the appended claims. Therefore, all words and expressions should be interpreted broadly and they are intended to illustrate, not to restrict, the embodiment. It will be obvious to a person skilled in the art that, as technology advances, the inventive concept can be implemented in various ways.

[0153] Further, it is clear to a person skilled in the art that the described embodiments may, but are not required to, be combined with other embodiments in various ways.

Claims

1. CLAIMS1. An apparatus comprising means for: receiving, from a first Application Programming Interface, API, Exposing Function, AEF, a request to access a second AEF, wherein the request comprises a Client Credentials Assertion, CCA, token signed by an API invoker and a first access token of the API invoker for the first AEF; authenticating the API invoker using the CCA token; generating a second access token for the first AEF to access a service of the second AEF.

2. The apparatus according to claim 1, wherein the means are further configured for: sending the second access token to the first AEF.

3. The apparatus according to claim 1 or claim 2, wherein the means are further configured for: receiving a discovery request from the API invoker; sending, to the API invoker, information identifying the first AEF and an indication to provide a CCA token when accessing the first AEF.

4. The apparatus according to any preceding claim, wherein the means are further configured for: receiving a request for the first access token from the API invoker for the first AEF, the request comprising an identifier of the first AEF; sending the first access token to the API invoker.

5. The apparatus according to any preceding claim, wherein the apparatus comprises a Common API Framework Core Function, CCF.

6. The apparatus according to any preceding claim, wherein the CCA token includes an identifier of the API invoker, a timestamp, an expiration time, and at least one of: an address of the apparatus; and address of the first AEF.

7. The apparatus according to any preceding claim, wherein the CCA token includes an identifier of at least one resource that the API invoker is requesting to access.

8. The apparatus according to any preceding claim, wherein the CCA token includes: an X.509 URL (x5u) referring to a resource for the X.509 public key certificateor certificate chain used by the API invoker for signing the CCA token; or an X.509 Certificate Chain (x5c) including the X.509 public key certificate or certificate chain used by the API invoker for signing the CCA token.

9. A method comprising: receiving, from a first Application Programming Interface, API, Exposing Function, AEF, a request to access a second AEF, wherein the request comprises a Client Credentials Assertion, CCA, token signed by an API invoker and a first access token of the API invoker for the first AEF; authenticating the API invoker using the CCA token; generating a second access token for the first AEF to access a service of the second AEF.

10. A computer program comprising instructions stored thereon for performing at least the following: receiving, from a first Application Programming Interface, API, Exposing Function, AEF, a request to access a second AEF, wherein the request comprises a Client Credentials Assertion, CCA, token signed by an API invoker and a first access token of the API invoker for the first AEF; authenticating the API invoker using the CCA token; generating a second access token for the first AEF to access a service of the second AEF.

11. An apparatus comprising means for: generating a Client Credentials Assertion, CCA, token and signing the CCA token using a private key of the apparatus; sending a service request for a first API Exposing Function, AEF, including the signed CCA token and an access token of the apparatus for the first AEF; receiving a service from the first AEF, wherein the first AEF invokes a service from a second AEF to provide the service from the first AEF to the apparatus.

12. The apparatus according to claim 11, wherein the means are further configured for: sending a discovery request to a Common API Framework Core Function, CCF; receiving information identifying the first AEF and an indication to provide the signed CCA token when accessing the first AEF.

13. The apparatus according to claim 12, wherein the means are further configured for:sending, to the CCF, a request for the access token for the first AEF, the request comprising an identifier of the first AEF; receiving, from the CCF, the access token.

14. The apparatus according to any claim 11 to 13, wherein the apparatus comprises a user equipment.

15. The apparatus according to any of claims 11 to 14, wherein the signed CCA token includes an identifier of the apparatus a timestamp, an expiration time, and at least one of: an address of the CCF; and address of the first AEF.

16. The apparatus according to any of claims 10 to 15, wherein the signed CCA token includes an identifier of at least one resource that the API invoker is requesting to access.

17. The apparatus according to any of claims 10 to 16, wherein the signed CCA token includes: an X.509 URL (x5u) referring to a resource for the X.509 public key certificate or certificate chain used by the apparatus for signing the CCA token; or an X.509 Certificate Chain (x5c) including the X.509 public key certificate or certificate chain used by the apparatus for signing the CCA token.

18. A method comprising: generating a Client Credentials Assertion, CCA, token and signing the CCA token using a private key of an apparatus; sending a service request for a first API Exposing Function, AEF, including the signed CCA token and an access token of the apparatus for the first AEF; receiving a service from the first AEF, wherein the first AEF invokes a service from a second AEF to provide the service from the first AEF to the apparatus.

19. A computer program comprising instructions stored thereon for performing at least the following: generating a Client Credentials Assertion, CCA, token and signing the CCA token using a private key of an apparatus; sending a service request for a first API Exposing Function, AEF, including the signed CCA token and an access token of the apparatus for the first AEF; receiving a service from the first AEF, wherein the first AEF invokes a service from a second AEF to provide the service from the first AEF to the apparatus.

20. An apparatus comprising means for:receiving, from an Application Programming Interface, API, invoker a service request for a first API Exposure Function, AEF, wherein the request comprises a Client Credentials Assertion, CCA, token signed by the API invoker and a first access token of the API invoker for the apparatus; sending, to a Common API Framework Core Function, CCF, a request to access a second AEF, wherein the request comprises the CCA token signed by the API invoker and the first access token.

21. The apparatus according to claim 20, wherein the means are further configured for: receiving, from the CCF, a second access token for the apparatus to access a service of the second AEF.

22. The apparatus according to claim 21, wherein the means are further configured for: sending, to the second AEF, a service request comprising the second access token and the CCA token signed by the API invoker; receiving a service from the second AEF; providing a service to the API invoker using the service of the second AEF.

23. The apparatus according to any of claims 20 to 22, wherein the apparatus comprises a first AEF.

24. The apparatus according to any of claims 20 to 23, wherein the signed CCA token includes an identifier of the API invoker, a timestamp, an expiration time, and at least one of: an address of the apparatus; and address of the first AEF.

25. The apparatus according to any of claims 20 to 24, wherein the signed CCA token includes an identifier of at least one resource that the API invoker is requesting to access.

26. The apparatus according to any claim 20 to 25, wherein the signed CCA token includes: an X.509 URL (x5u) referring to a resource for the X.509 public key certificate or certificate chain used by the API invoker for signing the CCA token; or an X.509 Certificate Chain (x5c) including the X.509 public key certificate or certificate chain used by the API invoker for signing the CCA token.

27. A method comprising:receiving, from an Application Programming Interface, API, invoker a service request for a first Application Exposure Function, AEF, wherein the request comprises a Client Credentials Assertion, CCA, token signed by the API invoker and a first access token of the API invoker for an apparatus; sending, to a Common API Framework Core Function, CCF, a request to access a second AEF, wherein the request comprises the CCA token signed by the API invoker and the first access token.

28. A computer program comprising instructions stored thereon for performing at least the following: receiving, from an Application Programming Interface, API, invoker a service request for a first Application Exposure Function, AEF, wherein the request comprises a Client Credentials Assertion, CCA, token signed by the API invoker and a first access token of the API invoker for an apparatus; sending, to a Common API Framework Core Function, CCF, a request to access a second AEF, wherein the request comprises the CCA token signed by the API invoker and the first access token.

29. An apparatus comprising means for: receiving, from a first Application Programming Interface, API, Exposing Function, AEF, a service request comprising a Client Credentials Assertion, CCA, token signed by an API invoker and an access token of the API invoker and the first AEF for the apparatus; authenticating the API invoker using the signed CCA token and validating the signed CCA token and access token.

30. The apparatus of claim 29, wherein the validating the signed CCA token and access token comprises validating that an identifier of the API invoker in the signed CCA token and an identifier of the API invoker in the access token are the same.

31. The apparatus of claim 29 or claim 30, wherein the means are further configured for: providing a service to the first AEF.

32. The apparatus according to any of claims 29 to 31, wherein the apparatus comprises a second AEF.

33. The apparatus according to any of claims 29 to 32, wherein the signed CCA token includes an identifier of the API invoker, a timestamp, an expiration time, and at least one of: an address of the apparatus; and address of the first AEF.

34. The apparatus according to any of claims 29 to 33, wherein the signed CCA token includes an identifier of at least one resource that the API invoker is requesting to access.

35. The apparatus according to claim 29 to 34, wherein the signed CCA token includes: an X.509 URL (x5u) referring to a resource for the X.509 public key certificate or certificate chain used by the API invoker for signing the CCA token; or an X.509 Certificate Chain (x5c) including the X.509 public key certificate or certificate chain used by the API invoker for signing the CCA token.

36. A method comprising: receiving, from a first Application Programming Interface, API, Exposing Function, AEF, a service request comprising a Client Credentials Assertion, CCA, token signed by an API invoker and an access token of the first AEF for a second AEF; authenticating the API invoker using the signed CCA token and validating the signed CCA token and access token.

37. A computer program comprising instructions stored thereon for performing at least the following: receiving, from a first Application Programming Interface, API, Exposing Function, AEF, a service request comprising a Client Credentials Assertion, CCA, token signed by an API invoker and an access token of the first AEF for a second AEF; authenticating the API invoker using the signed CCA token and validating the signed CCA token and access token.

Images