WO2026033364A1

WO2026033364A1 - Single sign-on authentication for api invokers in capif

Info

Publication number: WO2026033364A1
Application number: PCT/IB2025/057881
Authority: WO
Inventors: Sireesha Bommisetty; Niranth Amogh; Mallikarjunudu Makham; Topuri BRAHMAIAH; Saurabh Khare; Anja Jerichow
Original assignee: Nokia Technologies Oy
Current assignee: Nokia Technologies Oy
Priority date: 2024-08-08
Filing date: 2025-08-01
Publication date: 2026-02-12
Anticipated expiration: 2027-02-08
Also published as: GB202411704D0; GB2643263A

Abstract

Example embodiments are disclosed that enable single sign-on authentication of API invokers in a CAPIF system. The embodiments include methods with operations performed by API invokers, a Resource Owner Function (ROF), and an API Exposing Function. The methods allow an API invoker to invoke one or more Service APIs accessible via an API Exposing Function (AEF) for a time period without re-authentication. The embodiments may include an expiry time feature in which the API invoker may invoke one or more Service APIs for a time period without re-authentication until the expiry time is expired.

Description

SINGLE SIGN-ON AUTHENTICATION FOR API INVOKERS IN CAPIF

FIELD

[0001] Various example embodiments relate generally to communication networks and, more particularly, relating to a common API framework (CAPIF) in such communication networks.

BACKGROUND

[0002] Common API framework (CAPIF) is a 3GPP architecture that enables interactions between northbound entities and various application programming interfaces (APIs), for example, interactions between API invokers and service APIs to invoke various services. An API invoker is an entity, such as a user equipment (UE), that invokes the CAPIF or service APIs. A service API is an interface through which a component of the system exposes its services to API invokers. In one non-limiting example, a UE may invoke a service API to obtain services relating to the UE location. The CAPIF applies to both EPS and 5GS, can be hosted within a PLMN or SNPN, and is independent of the underlying 3GPP access (e.g., E-UTRA, NR).

[0003] Authentication of API invokers is one component of CAPIF functionality wherein an API invoker must be authenticated before it is allowed to access the service APIs. Authentication in a CAPIF system with multiple API invokers and multiple service APIs is a technical challenge.

SUMMARY

[0004] In an aspect of the present disclosure, a method in a Resource Owner Function (ROF) of a Common API Framework (CAPIF) includes: obtaining an ROF certificate; obtaining a private key associated with the ROF certificate; receiving from an API invoker, a first message including an API invoker ID; signing the API invoker ID using the private key, yielding an ROF-signed API invoker ID; and sending to the API invoker, a second message including the ROF-signed API invoker ID and the ROF certificate; the ROF-signed API invoker ID and the ROF certificate usable to support single sign-on authentication between the API invoker and an API Exposing Function (AEF) to invoke one or more Service APIs. [0005] In an aspect of the method, obtaining an ROF certificate may comprise obtaining the ROF certificate from a CAPIF Core Function (CCF) following an authentication procedure with the CCF.

[0006] In an aspect of the method, the ROF may be a part of a user equipment (UE).

[0007] In an aspect of the method, the second message may be further usable to support authorization between the API invoker and the AEF.

[0008] In an aspect of the method, signing the API invoker ID may comprise signing the API invoker ID and an expiry time using the private key, yielding an ROF-signed API invoker ID with expiry time; sending the second message may comprise sending a message including the ROF- signed API invoker ID with expiry time, the expiry time, and the ROF certificate; the ROF-signed API invoker ID with expiry time and the ROF certificate usable to support single sign-on authentication between the API invoker and an API Exposing Function (AEF) to invoke one or more Service APIs until the expiry time is expired.

[0009] In an aspect of the present disclosure, a method in an API invoker of a Common API Framework (CAPIF) includes: sending to a Resource Owner Function (ROF) ROF, a first message including an API invoker ID; receiving from the ROF, a second message including an ROF-signed API invoker ID, an ROF certificate, the ROF-signed API invoker ID and the ROF certificate usable to support single sign-on authentication between the API invoker and an API Exposing Function (AEF) to invoke one or more Service APIs; and using single sign-on authentication between the API invoker and the AEF to enable the invocation of one or more Service APIs.

[0010] In an aspect of the method, using single sign-on authentication may comprise: sending, to the AEF, an authentication request including a plain-text API invoker ID, the ROF- signed API invoker ID and the ROF certificate usable to support single sign-on authentication between the API invoker and the AEF; receiving, from the AEF, a response indicating successful authentication; and following successful authentication, invoking one or more Service APIs accessible via the AEF for a time period without re-authentication.

[0011] In an aspect of the method, the API invoker may be a part of a user equipment (UE).

[0012] In an aspect of the method, receiving the second message may comprise receiving a message including the ROF-signed API invoker ID with expiry time.

[0013] In an aspect of the method, receiving the second message may comprise receiving a message including an expiry time, and the ROF-signed API invoker ID with expiry time. [0014] In an aspect of the method, using single sign-on authentication may comprise: sending, to the AEF, an authentication request including a plain-text API invoker ID, the expiry time, the ROF-signed API invoker ID with expiry time, and the ROF certificate usable to support single sign-on authentication between the API invoker and the AEF; receiving, from the AEF, a response indicating successful authentication; and following successful authentication, invoking one or more Service APIs accessible via the AEF for a time period without re-authentication until the expiry time is expired.

[0015] In an aspect of the present disclosure, a method in an API Exposing Function (AEF) of a Common API Framework (CAPIF) includes: receiving, from an API invoker via a TLS connection, an authentication request including a plain-text API invoker ID, an ROF-signed API invoker ID and an ROF certificate usable to support single sign-on authentication between the API invoker and the AEF; validating the ROF certificate; verifying the ROF signature on the ROF- signed API invoker ID using the ROF certificate; determining whether the authentication is successful by comparing the ROF-signed API invoker ID with the plain-text API invoker ID; and following successful authentication and authorization, enabling the API invoker to invoke one or more Service APIs accessible via the AEF for a time period without re-authentication.

[0016] In an aspect of the method, the authentication request may include a plain-text API invoker ID, an expiry time, and a ROF-signed API invoker ID with expiry time, the method may further comprise verifying the expiry time; and following successful authentication, enabling the API invoker to invoke one or more Service APIs accessible via the AEF for a time period without re-authentication until the expiry time is expired.

[0017] In an aspect of the present disclosure, a method in a Resource Owner Function (ROF) of a Common API Framework (CAPIF) includes: obtaining a public/private key pair; obtaining a token including a public key; receiving from an API invoker, a first message including an API invoker ID; signing the API invoker ID using the private key, yielding an ROF-signed API invoker ID; sending to the API invoker, a second message including the ROF-signed API invoker ID and the token; the ROF-signed API invoker ID and the token usable to support single sign-on authentication between the API invoker and an API Exposing Function (AEF) to invoke one or more Service APIs.

[0018] In an aspect of the method, obtaining the token may comprise obtaining the token from a CAPIF Core Function (CCF) following an authentication procedure with the CCF. [0019] In an aspect of the method, the ROF may be a part of a user equipment (UE).

[0020] In an aspect of the method, the second message may be further usable to support authorization between the API invoker and the AEF.

[0021] In an aspect of the method, signing the API invoker ID may comprise signing the API invoker ID and an expiry time using the private key, yielding an ROF-signed API invoker ID with expiry time; sending the second message may comprise sending a message including the ROF-signed API invoker ID with expiry time, the expiry time, and the token; the ROF-signed API invoker ID with expiry time and the token usable to support single sign-on authentication between the API invoker and an API Exposing Function (AEF) to invoke one or more Service APIs for a time period without re-authentication until the expiry time is expired.

[0022] In an aspect of the present disclosure, a method in an API invoker of a Common API Framework (CAPIF) includes: sending, to a Resource Owner Function (ROF), a first message including an API invoker ID; receiving from the ROF, a second message including an ROF- signed API invoker ID and a token usable to support single sign-on authentication between the API invoker and the API Exposing Function (AEF) to invoke one or more Service APIs; and using single sign-on authentication between the API invoker and the AEF to enable the invocation of one or more Service APIs.

[0023] In an aspect of the method, using single sign-on authentication may comprise: sending, to the AEF, an authentication request including a plain-text API invoker ID, the ROF- signed API invoker ID and the token usable to support single sign-on authentication between the API invoker and the AEF; receiving, from the AEF, a response indicating successful authentication; and following successful authentication, invoking one or more Service APIs accessible via the AEF for a time period without re-authentication.

[0024] In an aspect of the method, the API invoker may be a part of a user equipment (UE).

[0025] In an aspect of the method, receiving the second message may comprise receiving a message including the ROF-signed API invoker ID with expiry time.

[0026] In an aspect of the method, receiving the second message may comprise receiving a message including an expiry time, and the ROF-signed API invoker ID with expiry time.

[0027] In an aspect of the method, using single sign-on authentication may comprise: sending, to the AEF, an authentication request including a plain-text API invoker ID, the expiry time, the ROF-signed API invoker ID with expiry time, and the token usable to support single sign-on authentication between the API invoker and the AEF; receiving, from the AEF, a response indicating successful authentication; and following successful authentication, invoking one or more Service APIs accessible via the AEF for a time period without re-authentication until the expiry time is expired.

[0028] In an aspect of the present disclosure, a method in an API Exposing Function (AEF) of a Common API Framework (CAPIF) includes: receiving, from an API invoker via a TLS connection, an authentication request including a plain-text API invoker ID, an ROF-signed API invoker ID and a token usable to support single sign-on authentication between the API invoker and the AEF; validating the token; extracting a public key of the token; verifying the signature applied to the ROF-signed API invoker ID using the public key of the token, yielding an AEF- verified API invoker ID signature; determining whether the authentication is successful by comparing the AEF-verified API invoker ID to the plain-text API invoker ID, the authentication being deemed successful if the AEF-verified API invoker ID matches the plain-text API invoker ID; and following successful authentication, sending an authentication response indicating successful authentication and enabling the API invoker to invoke one or more Service APIs accessible via the AEF for a time period without re-authentication.

[0029] In an aspect of the method, the authentication request may include a plain-text API invoker ID, an expiry time, and a ROF-signed API invoker ID with expiry time, the method further comprising verifying the expiry time; and following successful authentication, enabling the API invoker to invoke one or more Service APIs accessible via the AEF for a time period without reauthentication until the expiry time is expired.

[0030] In an aspect of the present disclosure, a method in a Resource Owner Function (ROF) of a Common API Framework (CAPIF) includes: obtaining an ROF token; sending the ROF token to an API invoker, the ROF token usable to support single sign-on authentication between the API invoker and an API Exposing Function (AEF) to invoke one or more Service APIs for a time period without re-authentication.

[0031] In an aspect of the method, obtaining the ROF token may comprise obtaining the token from a CAPIF Core Function (CCF) following an authentication procedure with the CCF.

[0032] In an aspect of the method, the ROF may be a part of a user equipment (UE).

[0033] In an aspect of the method, the ROF token may be further usable to support authorization between the API invoker and the AEF. [0034] In an aspect of the method, sending the ROF token may comprise sending the ROF token and an expiry time to the API invoker, the ROF token and expiry time usable to support single sign-on authentication between the API invoker and an API Exposing Function (AEF) to invoke one or more Service APIs for a time period without re- authentication until the expiry time expires.

[0035] In an aspect of the present disclosure, a method in an API invoker of a Common API Framework (CAPIF) includes: obtaining from a Resource Owner Function (ROF), an ROF token usable to support single sign-on authentication between the API invoker and an API Exposing Function (AEF) to invoke one or more Service APIs; sending, to the AEF, an authentication request including the ROF token; receiving, from the AEF, a response indicating successful authentication; and following successful authentication, invoking one or more Service APIs accessible via the AEF for a time period without re-authentication.

[0036] In an aspect of the method, the API invoker may be a part of a user equipment (UE).

[0037] In an aspect of the method, obtaining the ROF token may comprise obtaining the ROF token and an expiry time from the ROF, and sending an authentication request may comprise sending the ROF token and expiry time to the AEF, the ROF token and expiry time usable to support single sign-on authentication between the API invoker and an API Exposing Function (AEF) to invoke one or more Service APIs for a time period without re-authentication until the expiry time expires.

[0038] In an aspect of the present disclosure, a method in an API Exposing Function (AEF) of a Common API Framework (CAPIF) includes: receiving, from an API invoker via a TLS connection, an authentication request including an ROF token usable to support single sign-on authentication between the API invoker and the AEF; validating the ROF token; following successful validation of the ROF token, enabling the API invoker to invoke one or more Service APIs accessible via the AEF for a time period without re-authentication.

[0039] In an aspect of the method, receiving an authentication request may comprise receiving the ROF token and an expiry time from the API invoker, and the method may further comprise: following successful validation of the ROF token, enabling the API invoker to invoke one or more Service APIs accessible via the AEF for a time period without re-authentication until the expiry time is expired. [0040] In accordance with aspects of the present disclosure, an apparatus includes at least one processor and at least one memory storing instructions. The instructions, when executed by the at least one processor, cause the apparatus to perform any of the methods and aspects described above.

[0041] In accordance with aspects of the present disclosure, a processor readable medium stores instructions which, when executed by at least one processor of an apparatus, cause the apparatus to perform any of the methods and aspects described above.

[0042] According to some aspects, there is provided the subject matter of the independent claims. Some further aspects are defined in the dependent claims.

BRIEF DESCRIPTION OF THE DRAWINGS

[0043] Some example embodiments will now be described with reference to the accompanying drawings.

[0044] FIG. 1 illustrates a Common API framework (CAPIF) architecture with which one or more illustrative embodiments may be implemented;

[0045] FIG. 2 illustrates an example procedure to support single sign-on of API invokers in a CAPIF architecture, according to an illustrative embodiment;

[0046] FIG. 3 illustrates another example procedure to support single sign-on of API invokers in a CAPIF architecture, according to an illustrative embodiment; and

[0047] FIG. 4 illustrates another example procedure to support single sign-on of API invokers in a CAPIF architecture, according to an illustrative embodiment; and

[0048] FIG. 5 illustrates user equipment and network entities of a CAPIF architecture with which one or more illustrative embodiments may be implemented.

DETAILED DESCRIPTION

[0049] In the following description, certain specific details are set forth in order to provide a thorough understanding of disclosed aspects. However, one skilled in the relevant art will recognize that aspects may be practiced without one or more of these specific details or with other methods, components, materials, etc. In other instances, well-known structures associated with transmitters, receivers, or transceivers have not been shown or described in detail to avoid unnecessarily obscuring descriptions of the aspects. [0050] Reference throughout this specification to “one aspect” or “an aspect” means that a particular feature, structure, or characteristic described in connection with the aspect is included in at least one aspect. Thus, the appearances of the phrases “in one aspect” or “in an aspect” in various places throughout this specification are not necessarily all referring to the same aspect. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more aspects.

[0051] Embodiments are described in the present disclosure in conjunction with an example Common API framework (CAPIF) architecture and associated processes for supporting single sign-on of API invokers in the CAPIF architecture. It should be understood, however, that the scope of the claims is not limited to particular types of communication systems and/or processes disclosed.

[0052] In accordance with illustrative embodiments implemented in a 5G communication system environment, one or more 3 GPP technical specifications (TS) and technical reports (TR) may provide further explanation of network elements, functions and/or operations that may interact with parts of the inventive solutions. For example, 3GPP Technical Specifications TS 23.222, TS 33.122 and TS 29.222, the disclosures of which are incorporated by reference in their entirety, describe various details of CAPIF architecture, elements, functions and/or operations. However, while well-suited for 5G-related 3GPP standards, embodiments are not necessarily intended to be limited to any particular standards.

[0053] As used herein, the terms “send to,” “send towards,” “receive from,” “communicate with,” (and their variations) include communications that may or may not involve communications through one or more intermediate devices or nodes. The term “acquire” (and its variations) includes acquiring in the first instance or reacquiring after the first instance. The term “connection” may mean a physical connection or a logical connection.

[0054] Prior to describing illustrative embodiments, a general description of certain main components of a CAPIF architecture will be described below in the context of FIG. 1.

[0055] FIG. 1 is a diagram depicting a Common API framework (CAPIF) architecture 100 as set forth in 3GPP Technical Specification TS 23.222. In one aspect, the CAPIF architecture 100 is a representation of resource owner aware northbound API access (RNAA) and includes network elements and interfaces to support interactions between API invokers 102 and one or more northbound APIs, including service APIs 104 and CAPIF APIs 106. The CAPIF architecture 100 can be implemented in a 3GPP 4G or 5G communication system, can be hosted within a PLMN or SNPN, and is independent of the underlying 3GPP access (e.g., E-UTRA, NR).

[0056] An API invoker 102 defines an entity that invokes the service APIs 104 or CAPIF APIs 106. An API defines means by which an API invoker 102 can access the service APIs 104 or CAPIF APIs 106. An API invoker 102 supports the following capabilities: triggering API invoker onboarding or offboarding; support authentication by providing the API invoker identity and other information required for authentication of the API invoker; support mutual authentication with CAPIF; obtaining authorization prior to accessing the service or CAPIF APIs; discovering service or CAPIF APIs information; and invoking the service or CAPIF APIs. An API invoker profile defines the set of information associated with an API invoker 102 that allows that API invoker to utilize the service APIs 104 or CAPIF APIs 106. The API invoker 102 can be an application residing on a user equipment (UE) or on a server. API invokers 102 may access the APIs 104, 106 from within a PEMN 120 trust domain or from outside of the PLMN 120 trust domain.

[0057] The interface between an API invoker 102 within the PLMN 120 trust domain and CAPIF APIs 106 is denoted as CAPIF- 1; and the interface between an API invoker 102 within the PLMN 120 trust domain and service APIs 104 is denoted as CAPIF-2. The interface between an API invoker 102 outside of the PLMN 120 trust domain and CAPIF APIs 106 is denoted as CAPIF- le; and the interface between an API invoker 102 outside of the PLMN 120 trust domain and service APIs 104 is denoted as CAPIF-2e.

[0058] A resource owner is an entity (for example, a UE user or a MNO subscriber) capable of granting authorization to access a protected resource related to an invoked API. In the CAPIF architecture, this is enabled by interactions between a resource owner function (ROF) 108 and an Authorization Function (AF) 110. The ROF 108 can be an application residing on a user equipment (UE) or on a server. As shown, the AF 110 is an internal entity of a CAPIF Core Function (CCF) 112. The interface between the ROF 108 and AF 110 and CCF 112 is denoted as CAPIF-8.

[0059] The CCF 112 supports the following capabilities: authenticating the API invoker based on the identity and other information required for authentication of the API invoker; supporting mutual authentication with the API invoker; providing authorization for the API invoker prior to accessing the service API; publishing, storing and supporting the discovery of service APIs information; controlling service API access based on PLMN operator configured policies; storing logs for service API invocations and providing service API invocation logs to authorized entities; charging based on the logs of service API invocations; monitoring the service API invocations; onboarding new API invokers and offboarding an API invoker; storing policy configurations related to CAPIF and service APIs; support access the logs for auditing (e.g., detecting abuse); and support publishing, discover of service API information with another CAPIF core function in a CAPIF interconnection.

[0060] The ROF 108 supports the following capabilities: enable authorization from the resource owner for resource access; and managing and revoking authorization for resource access. In one example, the ROF 108 may provide authorization to access personal information resources (e.g., location, network activity of a UE). Under some jurisdictions, sharing personal information resources with an API invoker requires explicit opt-in by the resource owner (also referred to as subscriber) to authorize access to its personal information resources. This process is called consent capture. Consent capture may be achieved with a client application, such as the ROF, on or implemented at least in part by the resource owner's UE, and the resource owner (e.g., user) allowing or denying access by the API invoker to the personal information resources via the ROF.

[0061] While capturing the consent, the ROF 108 may be provided with a purpose of data processing, indicating what the API invoker intends to do with the personal information resources of the resource owner. The resource owner may grant access to personal information resources based on the purpose (e.g., fraud detection) but deny access for other purposes (e.g., advertising).

[0062] The authorization function (AF) 110 is a functional entity which, among other things, captures the consent (also referred to as authorization) through the ROF 108 to allow an API invoker 102 accessing services that require personal information processing. The AF 110 supports the following capabilities: receiving authorization from the resource owner; and providing the API invoker with authorization information that is needed to access the resource owner’s resources. In one example, when receiving consent from the ROF 108, the AF 110 may provide the API invoker 102 with the authorization information (also referred to as an access token), which is used to access the resource owner's resources. Once consent is received from a resource owner (e.g., user), an access token is granted to the API Invoker 102 to utilize the service from an API exposing function (AEF) 114.

[0063] An AEF 114 is the entity that provides the service communication entry point of the service APIs 104 to the API invokers 102. The AEF 114 resides within an API Provider Domain 122. The AEF 114 supports the following capabilities: authenticating the API invoker based on the identity and other information required for authentication of the API invoker provided by the CCF 112; validating the authorization provided by the CCF 112; and logging service API invocations at the CCF 112.

[0064] Other functions within the API Provider Domain 122 include an API Publishing Function 116 and an API Management Function 118.

[0065] Examples described herein allow API invoker access to one or more Service APIs (potentially multiple APIs) in a CAPIF system using a single authentication procedure for a time period without re-authentication, defining a single sign-on (SSO) procedure.

[0066] Single sign-on (SSO) is an authentication method that enables a single authentication to gain access to services, applications and/or resources with the same set of credentials. In one example in a CAPIF RNAA context, SSO can be used by the user (resource owner) to enable several of its API invokers (e.g. game 1 and game 2, or facebook and instagram) to securely authenticate to use one application service (e.g. location).

[0067] SSO can also be used to enable one API invoker (e.g. a car manufacturer) to securely authenticate with multiple applications (diagnostics, flood management, etc) by using just one set of credentials.

[0068] Hence, Single Sign-On (SSO) can enable a Resource Owner to use one authentication procedure to authenticate multiple API invokers to use one or more AEFs exposing resources related to the resource owner.

[0069] FIG. 2 is a message sequence showing example procedure 200 to support single sign-on authentication in a CAPIF architecture, according to one illustrative embodiment. The operations are performed by the components shown at the top of FIG. 2, which include a user equipment (UE) including one or more API invokers 102 and a Resource Owner Function (ROF) 108; a CAPIF Core Function (CCF) 112; and an API Exposing Function (AEF) 114. Such components may be, for example, the same components described in connection with FIG. 1 or otherwise described above.

[0070] At operation 201, the ROF in the UE is authenticated with the CCF and has a valid ROF certificate provided by the CCF. In one example, a certificate authority generates a public/private key pair for the ROF, provides a certificate including the public key to the ROF, and provides the private key separately to the ROF. The ROF obtains the ROF certificate and the private key associated with the ROF certificate from the CCF. In another example, the ROF generates a public/private key pair and the CCF generates the certificate by signing the public key. [0071] At operation 202, the API invoker in the UE sends a first message including an API invoker ID to the ROF. In one example, the first message defines a request to the ROF to sign/encrypt the API invoker ID.

[0072] At operation 203, the ROF uses the private key associated with its ROF certificate to sign/encrypt the API invoker ID, yielding an ROF-signed API invoker ID. In one embodiment including an expiry time feature, at operation 203, the ROF uses the private key to sign/encrypt the API invoker ID with an expiry time, yielding an ROF-signed API invoker ID with expiry time.

[0073] At operation 204, the ROF sends to the API invoker, a second message including the ROF-signed API invoker ID and the ROF certificate and related certificate chain information. In one example, the ROF-signed API invoker ID and the ROF certificate are usable to support single sign-on authentication between the API invoker and an API Exposing Function (AEF) to invoke one or more Service APIs for a time period without re-authentication. In one embodiment including an expiry time feature, the second message includes the ROF-signed API invoker ID with expiry time, the ROF certificate and the expiry time; and the ROF-signed API invoker ID with expiry time and the ROF certificate are usable to support single sign-on authentication between the API invoker and an API Exposing Function (AEF) to invoke one or more Service APIs for a time period without re-authentication until the expiry time is expired.

[0074] At operation 205, a server based TLS connection is established between the API invoker and the AEF, in which the AEF is authenticated by the API invoker.

[0075] At operation 206, the API invoker sends an authentication request to the AEF including a plain-text API invoker ID, the ROF-signed API invoker ID and the ROF certificate usable to support single sign-on authentication between the API invoker and the AEF for a time period without re-authentication. In one embodiment including an expiry time feature, the authentication request includes a plain-text API invoker ID and expiry time, the ROF-signed API invoker ID with expiry time, and the ROF certificate. The ROF-signed API invoker ID with expiry time and the ROF certificate are usable to support single sign-on authentication between the API invoker and the AEF to invoke one or more Service APIs for a time period without re-authentication until the expiry time is expired.

[0076] At operation 207, the AEF validates the received ROF certificate using the pre- configured root CA certificate of the CCF.

[0077] At operation 208, the AEF decrypts the ROF-signed API invoker ID using the certificate and verifies if it is the same as the plain-text API invoker ID. In one embodiment including an expiry time feature, the AEF decrypts the ROF-signed API invoker ID with expiry time using the certificate and verifies the signature of the API invoker ID and expiry time, and verifies that the expiry time is valid and not expired.

[0078] At operation 210, the AEF sends an Authentication response to the API invoker, indicating success or failure of the authentication. If the authentication is successful, the API invoker may invoke one or more Service APIs accessible via the AEF for a time period without re-authentication. In one embodiment including an expiry time feature, following successful authentication, the API invoker may invoke one or more Service APIs accessible via the AEF for a time period without re-authentication until the expiry time is expired.

[0079] FIG. 3 is a message sequence showing an example procedure 300 to support single signauthentication in a CAPIF architecture, according to another illustrative embodiment. The operations are performed by the components shown at the top of FIG. 3, which include a user equipment (UE) including one or more API invokers 102 and a Resource Owner Function (ROF) 108; and an API Exposing Function (AEF) 114. Such components may be, for example, the same components described in connection with FIG. 1 or otherwise described above.

[0080] At operation 301, the ROF in the UE has obtained a public/private key pair from a certificate authority.

[0081] At operation 302, the ROF has successfully authenticated with the CCF and has a valid OpenlD token provided by the CCF. In one example, the OpenlD token includes a public key present in the token.

[0082] At operation 303, the API invoker in the UE sends a first message including an API invoker ID to the ROF. In one example, the first message defines a request to the ROF to sign/encrypt the API invoker ID.

[0083] At operation 304, the ROF uses its private key to sign/encrypt the API invoker ID, yielding an ROF-signed API invoker ID. In one embodiment including an expiry time feature, at operation 304, the ROF uses the private key to sign/encrypt the API invoker ID with an expiry time, yielding an ROF-signed API invoker ID with expiry time.

[0084] At operation 305, the ROF sends to the API invoker, a second message including the ROF-signed API invoker ID and the OpenlD token. In one example, the ROF-signed API invoker ID and the OpenlD token are usable to support single sign-on authentication between the API invoker and an API Exposing Function (AEF) to invoke one or more Service APIs for a time period without re-authentication. In one embodiment including an expiry time feature, the second message includes the ROF-signed API invoker ID with expiry time, the OpenlD token and the expiry time; and the ROF-signed API invoker ID with expiry time and the OpenlD token are usable to support single sign-on authentication between the API invoker and an API Exposing Function (AEF) to invoke one or more Service APIs for a time period without re-authentication until the expiry time is expired.

[0085] At operation 306, the API invoker obtains from the CCF, AEF endpoint details and its root CA certificate.

[0086] At operation 307, a server based TLS connection is established between the API invoker and the AEF, in which the AEF is authenticated by the API invoker.

[0087] At operation 308, the API invoker sends an authentication request to the AEF including a plain-text API invoker ID, the ROF-signed API invoker ID and the OpenlD token usable to support single sign-on authentication for a time period without re-authentication between the API invoker and the AEF. In one embodiment including an expiry time feature, the authentication request includes a plain-text API invoker ID and expiry time, and an ROF- signed API invoker ID with expiry time, and the OpenlD token. The ROF-signed API invoker ID with expiry time and the OpenlD token are usable to support single sign-on authentication between the API invoker and the AEF to invoke one or more Service APIs for a time period without re-authentication until the expiry time is expired.

[0088] At operation 309, the AEF validates the OpenlD token, extracts a public key present in the token, and verifies the signature of the ROF-signed API invoker ID, yielding an AEF- verified API invoker ID signature. In one example, the AEF verifies the signature by comparing the AEF- verified API invoker ID to the plain- text API invoker ID, the authentication being deemed successful if the AEF-verified API invoker ID matches the plain- text API invoker ID. In one embodiment including an expiry time feature, the AEF validates the OpenlD token, extracts a public key present in the token, and verifies the signature of the ROF-signed API invoker ID with expiry time, yielding an AEF-verified API invoker ID signature with expiry time. The AEF also verifies that the expiry time is valid and not expired. In one example, the AEF verifies the signature by comparing the AEF-verified API invoker ID with expiry time to the plain-text API invoker ID with expiry time, the authentication being deemed successful if the AEF-verified API invoker ID with expiry time matches the plain-text API invoker ID with expiry time.

[0089] At operation 310, the AEF sends an Authentication response to the API invoker, indicating success or failure of the authentication. If the authentication is successful, the API invoker may invoke one or more Service APIs accessible via the AEF for a time period without re-authentication. In one embodiment including an expiry time feature, following successful authentication, the API invoker may invoke one or more Service APIs accessible via the AEF for a time period without re-authentication until the expiry time is expired.

[0090] FIG. 4 is a message sequence showing an example procedure 400 to support single signauthentication in a CAPIF architecture, according to another illustrative embodiment. The operations are performed by the components shown at the top of FIG. 4, which include a user equipment (UE) including one or more API invokers 102 and a Resource Owner Function (ROF) 108; a CAPIF Core Function (CCF) 112; and an API Exposing Function (AEF) 114. Such components may be, for example, the same components described in connection with FIG. 1 or otherwise described above.

[0091] At operation 401, the ROF has successfully authenticated with the CCF using an OpenlD Connect (OIDC) protocol.

[0092] At operation 402, the ROF sends an OIDC Token Request to the CCF; and at operation 403, the CCF sends an OIDC Token Response to the ROF. In one example, the OIDC Token Response includes an ROF token (e.g., ID token, signed by the CCF).

[0093] At operation 404, the API invoker sends a Get Token request to the ROF to request the ROF token. At operation 405, the ROF validates if the API invoker can be given the ROF token. If the ROF determines that the API invoker can be given the ROF token, it sends the ROF token to the API invoker at operation 406. In one embodiment including an expiry time feature, the ROF may send the ROF token and an expiry time to the API invoker at operation 406.

[0094] At operation 407, a server based TLS connection is established between the API invoker and the AEF, in which the AEF is authenticated by the API invoker.

[0095] At operation 408, the API invoker sends an authentication request to the AEF including the ROF token. The ROF token is usable to support single sign-on authentication between the API invoker and the AEF to invoke one or more Service APIs for a time period without re-authentication. In one embodiment including an expiry time feature, the authentication request may include the ROF token and an expiry time.

[0096] At operation 409, the AEF validates the received ROF token. In one embodiment including an expiry time feature, the AEF validates the ROF token and verifies that the expiry time is valid and not expired.

[0097] At operation 410, the AEF sends an Authentication response to the API invoker, indicating success or failure of the authentication. If the authentication is successful, the API invoker may invoke one or more Service APIs accessible via the AEF for a time period without re-authentication. In one embodiment including an expiry time feature, following successful authentication, the API invoker may invoke one or more Service APIs accessible via the AEF for a time period without re-authentication until the expiry time is expired.

[0098] FIG. 5 is a block diagram illustrating user equipment and network entities of a CAPIF architecture according to illustrative embodiments. More particularly, system 500 is shown comprising user equipment (UE) 502 and a plurality of network entities 504-1, . . . . , 504-N. For example, in illustrative embodiments and with reference back to FIG. 1 , UE 502 can represent API Invoker 102, while network entities 504-1, . . . , 504-N can represent Resource Owner Function 108, Authorization Function 110, CAPIF Core Function 112, and API Exposing Function 114. It is to be appreciated that the UE 502 and network entities 504-1, . . . . , 504-N are configured to interact to provide CAPIF functionality, including without limitation, the operations described herein in FIG. 2, FIG. 3 and FIG. 4.

[0099] The user equipment 502 comprises a processor 512 coupled to a memory 516 and interface circuitry 510. The processor 512 of the user equipment 502 includes a CAPIF processing module 514 that may be implemented at least in part in the form of software executed by the processor. The processing module 514 performs CAPIF operations described in conjunction with figures and example embodiments described herein. The memory 516 of the user equipment 502 includes a storage module 518 that stores data generated or otherwise used during CAPIF operations.

[00100] Each of the network entities (individually or collectively referred to herein as 504) comprises a processor 522 (522-1, . . . , 522-N) coupled to a memory 526 (526-1, . . . , 526-N) and interface circuitry 520 (520-1, . . . , 520-N). Each processor 522 of each network entity 504 includes a CAPIF processing module 524 (524- 1 , . . . , 524-N) that may be implemented at least in part in the form of software executed by the processor 522. The processing module 524 performs CAPIF operations described in conjunction with figures and example embodiments described herein. Each memory 526 of each network entity 504 includes a storage module 528 (528-1, . . . , 528-N) that stores data generated or otherwise used during CAPIF operations.

[00101] The processors 512 and 522 may comprise, for example, microprocessors such as central processing units (CPUs), application-specific integrated circuits (ASICs), digital signal processors (DSPs) or other types of processing devices, as well as portions or combinations of such elements.

[00102] The memories 516 and 526 may be used to store one or more software programs that are executed by the respective processors 512 and 522 to implement at least a portion of the functionality described herein. For example, CAPIF operations and other functionality as described in conjunction with figures and example embodiments herein may be implemented in a straightforward manner using software code executed by processors 512 and 522.

[00103] The memories 516 and 526 may be viewed as an example of what is more generally referred to herein as a computer program product or still more generally as a processor-readable storage medium that has executable program code embodied therein. Other examples of processor-readable storage media may include disks or other types of magnetic or optical media, in any combination. Illustrative embodiments can include articles of manufacture comprising such computer program products or other processor-readable storage media.

[00104] Further, the memories 516 and 526 may more particularly comprise, for example, electronic random-access memory (RAM) such as static RAM (SRAM), dynamic RAM (DRAM) or other types of volatile or non-volatile electronic memory. The latter may include, for example, non-volatile memories such as flash memory, magnetic RAM (MRAM), phase-change RAM (PC- RAM) or ferroelectric RAM (FRAM). The term “memory” as used herein is intended to be broadly construed, and may additionally or alternatively encompass, for example, a read-only memory (ROM), a disk-based memory, or other type of storage device, as well as portions or combinations of such devices. [00105] The interface circuitries 510 and 520 illustratively comprise transceivers or other communication hardware or firmware that allows the associated system elements to communicate with one another in the manner described herein.

[00106] It is apparent from FIG. 5 that user equipment 502 and plurality of network entities 504 are configured to interact for CAPIF operations via their respective interface circuitries 510 and 520. This communication involves each participant sending data to and/or receiving data from one or more of the other participants. The term “data” as used herein is intended to be construed broadly, so as to encompass any type of information that may be sent between participants including, but not limited to, identity data, key pairs, key indicators, tokens, secrets, security management messages, registration request/response messages and data, request/response messages, authentication request/response messages and data, metadata, control data, audio, video, multimedia, consent data, other messages, etc.

[00107] It is to be appreciated that the particular arrangement of components shown in FIG. 5 is an example only, and numerous alternative configurations may be used in other embodiments. For example, any given network element/function can be configured to incorporate additional or alternative components and to support other communication protocols.

[00108] More generally, FIG. 5 can be considered to represent processing devices configured to provide CAPIF operational functionalities and operatively coupled to one another in a CAPIF system.

[00109] Further embodiments of the present disclosure include the following examples.

[00110] Example 1.1. An apparatus comprising: a Resource Owner Function (ROF) of a communication network including a Common API Framework (CAPIF), the CAPIF adapted to support connectivity of one or more API invokers to one or more Service APIs, the ROF 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: obtain an ROF certificate; obtain a private key associated with the ROF certificate; receive from an API invoker, a first message including an API invoker ID; sign the API invoker ID using the private key, yielding an ROF-signed API invoker ID; send to the API invoker, a second message including the ROF-signed API invoker ID and the ROF certificate; the ROF-signed API invoker ID and the ROF certificate usable to support single sign-on authentication between the API invoker and an API Exposing Function (AEF) to invoke one or more Service APIs.

[00111] Example 1.2. An apparatus comprising: an API invoker of a communication network including a Common API Framework (CAPIF), the CAPIF adapted to support connectivity of one or more API invokers to one or more Service APIs, the API invoker 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: send to a Resource Owner Function (ROF), a first message including an API invoker ID; receive from the ROF, a second message including an ROF-signed API invoker ID, an ROF certificate, the ROF-signed API invoker ID and the ROF certificate usable to support single sign-on authentication between the API invoker and the API Exposing Function (AEF) to invoke one or more Service APIs; and use single sign-on authentication between the API invoker and the AEF to enable the invocation of one or more Service APIs.

[00112] Example 1.3. An apparatus comprising: an API Exposing Function (AEF) of a communication network including a Common API Framework (CAPIF), the CAPIF adapted to support connectivity of one or more API invokers to one or more Service APIs, the AEF 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: receive, from an API invoker via a TLS connection, an authentication request including a plain-text API invoker ID, an ROF-signed API invoker ID and an ROF certificate usable to support single sign-on authentication between the API invoker and the AEF; validate the ROF certificate; verify the ROF signature on the ROF-signed API invoker ID using the ROF certificate; determine whether the authentication is successful by comparing the ROF-signed API invoker ID with the plain-text API invoker ID; and following successful authentication and authorization, enable the API invoker to invoke one or more Service APIs accessible via the AEF for a time period without re-authentication. [00113] Example 1.4. An apparatus comprising: a Resource Owner Function (ROF) of a communication network including a Common API Framework (CAPIF), the CAPIF adapted to support connectivity of one or more API invokers to one or more Service APIs, the ROF 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: obtain an ROF certificate; obtain a private key associated with the ROF certificate; receive from an API invoker, a first message including an API invoker ID; sign the API invoker ID and an expiry time using the private key, yielding an ROF- signed API invoker ID with expiry time; send to the API invoker, a second message including the ROF-signed API invoker ID with expiry time and the ROF certificate; the ROF-signed API invoker ID with expiry time and the ROF certificate usable to support single sign-on authentication between the API invoker and an API Exposing Function (AEF) to invoke one or more Service APIs for a time period without re-authentication until the expiry time is expired.

[00114] Example 1.5. An apparatus comprising: an API invoker of a communication network including a Common API Framework (CAPIF), the CAPIF adapted to support connectivity of one or more API invokers to one or more Service APIs, the API invoker 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: send to a Resource Owner Function (ROF), a first message including an API invoker ID; receive from the ROF, a second message including an expiry time, an ROF-signed API invoker ID with expiry time, and an ROF certificate, the ROF-signed API invoker ID and the ROF certificate usable to support single sign-on authentication between the API invoker and an API Exposing Function (AEF) to invoke one or more Service APIs; and use single sign-on authentication between the API invoker and the AEF to enable the invocation of one or more Service APIs for a time period without re-authentication until the expiry time is expired.

[00115] Example 2.1. An apparatus comprising: a Resource Owner Function (ROF) of a communication network including a Common API Framework (CAPIF), the CAPIF adapted to support connectivity of one or more API invokers to one or more Service APIs, the ROF 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: obtain a public/private key pair; obtain a token including a public key; receive from an API invoker, a first message including an API invoker ID; sign the API invoker ID using the private key, yielding an ROF-signed API invoker ID; send to the API invoker, a second message including the ROF-signed API invoker ID and the token; the ROF-signed API invoker ID and the token usable to support single sign-on authentication between the API invoker and an API Exposing Function (AEF) to invoke one or more Service APIs.

[00116] Example 2.2. An apparatus comprising: an API invoker of a communication network including a Common API Framework (CAPIF), the CAPIF adapted to support connectivity of one or more API invokers to one or more Service APIs, the API invoker 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: send to a Resource Owner Function (ROF), a first message including an API invoker ID; receive from the ROF, a second message including an ROF-signed API invoker ID and a token usable to support single sign-on authentication between the API invoker and the API Exposing Function (AEF) to invoke one or more Service APIs; and use single sign-on authentication between the API invoker and the AEF to enable the invocation of one or more Service APIs.

[00117] Example 2.3. An apparatus comprising: an API Exposing Function (AEF) of a communication network including a Common API Framework (CAPIF), the CAPIF adapted to support connectivity of one or more API invokers to one or more Service APIs, the AEF 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: receive, from an API invoker via a TLS connection, an authentication request including a plain-text API invoker ID, an ROF-signed API invoker ID and a token usable to support single sign-on authentication between the API invoker and the AEF; validate the token; extract a public key of the token; verify the signature applied to the ROF-signed API invoker ID using the public key of the token, yielding an AEF-verified API invoker ID signature; determine whether the authentication is successful by comparing the AEF-verified API invoker ID to the plain-text API invoker ID, the authentication being deemed successful if the AEF-verified API invoker ID matches the plain-text API invoker ID; and following successful authentication, send an authentication response indicating successful authentication and enabling the API invoker to invoke one or more Service APIs accessible via the AEF for a time period without re-authentication.

[00118] Example 2.4. An apparatus comprising: a Resource Owner Function (ROF) of a communication network including a Common API Framework (CAPIF), the CAPIF adapted to support connectivity of one or more API invokers to one or more Service APIs, the ROF 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: obtain a public/private key pair; obtain a token including a public key; receive from an API invoker, a first message including an API invoker ID; sign the API invoker ID and an expiry time using the private key, yielding an ROF- signed API invoker ID with expiry time; send to the API invoker, a second message including the ROF-signed API invoker ID with expiry time and the token; the ROF-signed API invoker ID with expiry time and the token usable to support single sign-on authentication between the API invoker and an API Exposing Function (AEF) to invoke one or more Service APIs for a time period without re-authentication until the expiry time is expired.

[00119] Example 2.5. An apparatus comprising: an API invoker of a communication network including a Common API Framework (CAPIF), the CAPIF adapted to support connectivity of one or more API invokers to one or more Service APIs, the API invoker 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: send to the ROF, a first message including an API invoker ID; receive from the ROF, a second message including an expiry time, an ROF-signed API invoker ID with expiry time, and a token, the ROF-signed API invoker ID and the token usable to support single sign-on authentication between the API invoker and an API Exposing Function (AEF) to invoke one or more Service APIs; and use single sign-on authentication between the API invoker and the AEF to enable the invocation of one or more Service APIs for a time period without re-authentication until the expiry time is expired.

[00120] Example 3.1. An apparatus comprising: a Resource Owner Function (ROF) of a communication network including a Common API Framework (CAPIF), the CAPIF adapted to support connectivity of one or more API invokers to one or more Service APIs, the ROF 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: obtain an ROF token; send the ROF token to an API invoker, the ROF token usable to support single sign-on authentication between the API invoker and an API Exposing Function (AEF) to invoke one or more Service APIs for a time period without re-authentication.

[00121] Example 3.2. An apparatus comprising: an API invoker of a communication network including a Common API Framework (CAPIF), the CAPIF adapted to support connectivity of one or more API invokers to one or more Service APIs, the API invoker 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: obtain from a Resource Owner Function (ROF), an ROF token usable to support single sign-on authentication between the API invoker and the API Exposing Function (AEF) to invoke one or more Service APIs; send, to the AEF, an authentication request including the ROF token; receive, from the AEF, a response indicating successful authentication; and following successful authentication, invoking one or more Service APIs accessible via the AEF for a time period without re-authentication.

[00122] Example 3.3. An apparatus comprising: an API Exposing Function (AEF) of a communication network including a Common API Framework (CAPIF), the CAPIF adapted to support connectivity of one or more API invokers to one or more Service APIs, the AEF 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: receive, from an API invoker via a TLS connection, an authentication request including an ROF token usable to support single sign-on authentication between the API invoker and the AEF; validate the ROF token; following successful validation of the ROF token, enabling the API invoker to invoke one or more Service APIs accessible via the AEF for a time period without re-authentication.

[00123] Example 3.4. An apparatus comprising: a Resource Owner Function (ROF) of a communication network including a Common API Framework (CAPIF), the CAPIF adapted to support connectivity of one or more API invokers to one or more Service APIs, the ROF 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: obtain an ROF token; send the ROF token with an expiry time to an API invoker, the ROF token and expiry time usable to support single sign-on authentication between the API invoker and an API Exposing Function (AEF) to invoke one or more Service APIs for a time period without reauthentication until the expiry time expires.

[00124] Example 3.5. An apparatus comprising: an API invoker of a communication network including a Common API Framework (CAPIF), the CAPIF adapted to support connectivity of one or more API invokers to one or more Service APIs, the API invoker 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: obtain from a Resource Owner Function (ROF), an ROF token and expiry time; send, to the AEF, an authentication request including the ROF token and expiry time; receive, from the AEF, a response indicating successful authentication; and following successful authentication, invoking one or more Service APIs accessible via the AEF for a time period without re-authentication until the expiry time expires.

[00125] The embodiments and aspects disclosed herein are examples of the present disclosure and may be embodied in various forms. For instance, although certain embodiments herein are described as separate embodiments, each of the embodiments herein may be combined with one or more of the other embodiments herein. Specific structural and functional details disclosed herein are not to be interpreted as limiting, but as a basis for the claims and as a representative basis for teaching one skilled in the art to variously employ the present disclosure in virtually any appropriately detailed structure. Like reference numerals may refer to similar or identical elements throughout the description of the figures.

[00126] In various embodiments, the terms “first message” and “second message”, as well as any subsequent messages may refer to any messages that are transmitted or received in an order and are not necessarily limited to any particular message.

[00127] The phrases “in an embodiment,” “in embodiments,” “in various embodiments,” “in some embodiments,” or “in other embodiments” may each refer to one or more of the same or different embodiments in accordance with the present disclosure. A phrase in the form “A or B” means “(A), (B), or (A and B).” A phrase in the form “at least one of A, B, or C” means “(A); (B); (C); (A and B); (A and C); (B and C); or (A, B, and C) .”

[00128] Any of the herein described methods, programs, algorithms or codes may be converted to, or expressed in, a programming language or computer program. The terms “programming language” and “computer program,” as used herein, each include any language used to specify instructions to a computer, and include (but is not limited to) the following languages and their derivatives: Assembler, Basic, Batch files, BCPL, C, C+, C++, Delphi, Fortran, Java, JavaScript, machine code, operating system command languages, Pascal, Perl, PL1, Python, scripting languages, Visual Basic, metalanguages which themselves specify programs, and all first, second, third, fourth, fifth, or further generation computer languages. Also included are database and other data schemas, and any other meta-languages. No distinction is made between languages which are interpreted, compiled, or use both compiled and interpreted approaches. No distinction is made between compiled and source versions of a program. Thus, reference to a program, where the programming language could exist in more than one state (such as source, compiled, object, or linked) is a reference to any and all such states. Reference to a program may encompass the actual instructions and/or the intent of those instructions.

[00129] While aspects of the present disclosure have been shown in the drawings, it is not intended that the present disclosure be limited thereto, as it is intended that the present disclosure be as broad in scope as the art will allow and that the specification be read likewise. Therefore, the above description should not be construed as limiting, but merely as exemplifications of particular aspects. Those skilled in the art will envision other modifications within the scope and spirit of the claims appended hereto.

Claims

WHAT IS CLAIMED IS:

1. In a communication network including a Common API Framework (CAPIF) adapted to support connectivity of one or more API invokers to one or more Service APIs, the CAPIF including a Resource Owner Function (ROF), method in the ROF, comprising: obtaining an ROF token; sending the ROF token to an API invoker, the ROF token usable to support single sign-on authentication between the API invoker and an API Exposing Function (AEF) to invoke one or more Service APIs for a time period without re-authentication.

2. The method of claim 1 , wherein obtaining the ROF token comprises obtaining the token from a CAPIF Core Function (CCF) following an authentication procedure with the CCF.

3. The method of claim 1, wherein the ROF is a part of a user equipment (UE).

4. The method of claim 1 , wherein the ROF token is further usable to support authorization between the API invoker and the AEF.

5. The method of claim 1, wherein sending the ROF token comprising sending the ROF token and an expiry time to the API invoker, the ROF token and expiry time usable to support single sign-on authentication between the API invoker and an API Exposing Function (AEF) to invoke one or more Service APIs for a time period without re-authentication until the expiry time expires.

6. In a communication network including a Common API Framework (CAPIF) adapted to support connectivity of one or more API invokers to one or more Service APIs, the CAPIF including a Resource Owner Function (ROF) and an API Exposing Function (AEF), a method in an API invoker, comprising: obtaining from the ROF, an ROF token usable to support single sign-on authentication between the API invoker and the API Exposing Function (AEF) to invoke one or more Service APIs; sending, to the AEF, an authentication request including the ROF token; receiving, from the AEF, a response indicating successful authentication; and following successful authentication, invoking one or more Service APIs accessible via the AEF for a time period without re-authentication.

7. The method of claim 6, wherein the API invoker is a part of a user equipment (UE).

8. The method of claim 6, wherein obtaining the ROF token comprises obtaining the ROF token and an expiry time from the ROF, and wherein sending an authentication request comprises sending the ROF token and expiry time to the AEF, the ROF token and expiry time usable to support single sign-on authentication between the API invoker and an API Exposing Function (AEF) to invoke one or more Service APIs for a time period without re-authentication until the expiry time expires.

9. In a communication network including a Common API Framework (CAPIF) adapted to support connectivity of one or more API invokers to one or more Service APIs, the CAPIF including a Resource Owner Function (ROF) and an API Exposing Function (AEF), a method in the AEF, comprising: receiving, from an API invoker via a TLS connection, an authentication request including an ROF token usable to support single sign-on authentication between the API invoker and the AEF; validating the ROF token; following successful validation of the ROF token, enabling the API invoker to invoke one or more Service APIs accessible via the AEF for a time period without re-authentication.

10. The method of claim 9, wherein receiving an authentication request comprises receiving the ROF token and an expiry time from the API invoker, the method further comprising: following successful validation of the ROF token, enabling the API invoker to invoke one or more Service APIs accessible via the AEF for a time period without re-authentication until the expiry time is expired.

11. An apparatus comprising: a Resource Owner Function (ROF) of a communication network including a Common API Framework (CAPIF), the CAPIF adapted to support connectivity of one or more API invokers to one or more Service APIs, the ROF comprising means for: obtaining an ROF token; sending the ROF token with an expiry time to an API invoker, the ROF token and expiry time usable to support single sign-on authentication between the API invoker and an API Exposing Function (AEF) to invoke one or more Service APIs for a time period without reauthentication until the expiry time expires.

12. The apparatus of claim 11, wherein the ROF is a part of a user equipment (UE).

13. An apparatus comprising: an API invoker of a communication network including a Common API Framework (CAPIF), the CAPIF adapted to support connectivity of one or more API invokers to one or more Service APIs, the CAPIF including a Resource Owner Function (ROF) and an API Exposing Function (AEF), the API invoker comprising means for: obtaining from the ROF, an ROF token and expiry time; sending, to the AEF, an authentication request including the ROF token and expiry time; receiving, from the AEF, a response indicating successful authentication; and following successful authentication, invoking one or more Service APIs accessible via the AEF for a time period without re-authentication until the expiry time expires.

14. The apparatus of claim 13, wherein the API invoker is a part of a user equipment

(UE).