API Invoker invoking an API with OAuth2 token exposed by AEF

Hi, When API Invoker try to invoke the API exposed by AEF, do we need to have authorization on all APIs with its separate logic? Let's say API Invoker wants to invoke a 5G API to create a new subscription on service at URI https://[BASE:URI]/3gpp-chargeable-party/v1/{AF_ID}/transactions with OAuth2 token. How does AEF verifies OAuth2 token [on its own or by using CCF ] and Do AEF need to write its own logic to handle claims and scope represented by OAuth2 token ?

I could not find any reference in specifications related to procedure of API invoker invoking the APIs.

Hello @gaurav23! Below is my explanation/quick reference guide based on my experience with implementing the Network Exposure Function (NEF), mainly from the perspective of the API Provider.

API Invocation and Security Methods in CAPIF

When an API Invoker attempts to invoke an API exposed by an API Exposure Function (AEF) within a 5G network (e.g., 3GPP NEF), there are three security methods supported by CAPIF:

• TLS-PSK (Pre-Shared Key):
  A secure session is established between the API Invoker and AEF using a PSK. The PSK is bootstrapped using CAPIF-1e authentication and is obtained by the AEF from the CAPIF Core Function (CCF) via the CAPIF-3/3e interface.

• TLS-PKI (Public Key Infrastructure):
  In this method, the API Invoker and AEF establish a secure session using certificates for mutual authentication.

• TLS with OAuth2:
  This method utilizes OAuth2 for authorization. The API Invoker authenticates to the AEF by establishing a TLS session, with either server-side certificate authentication or mutual certificate authentication. OAuth2 is then used to authorize API invocations, where the AEF verifies the access token issued by the CCF.

---

OAuth2 Authorization Flow

When using OAuth2 for securing API invocations (as implemented in our open-source NEF 3GPP Function, see NEF):

• Token Issuance:
  The API Invoker interacts with the CCF to obtain an OAuth2 access token. This token is typically a JWT containing claims and scopes that represent the permissions granted to the Invoker.

  After completing Step 10, the Invoker retrieves this JWT token from OpenCAPIF (CCF), which can then be used for API invocations.

• Token Verification by AEF:

  • AEF's Role:
    The AEF is responsible for verifying the OAuth2 token when an API invocation request is received. The AEF does not need to communicate with the CCF for each token verification; instead, it uses the public key provided during the onboarding process (e.g., the CAPIF public certificate in .pem format) to verify the JWT token's signature using the RS256 algorithm.

    Note: When an API Provider (e.g., NEF) publishes an API, it negotiates the security method with the CCF. This information can be found in the request body of the publish API post request.

  • Verification:
    The AEF must implement its own logic to validate the claims and scopes within the token to ensure that the API Invoker has the necessary permissions to access the requested API. In Python, this can be easily done using the _jose_ module. This is implemented in NEF, as shown here.

---

Concluding, this is the process flow and the implementation that we follow on open-source NEF project, thus AEF verifies the token.

Hope this helps!

Thanks @dfragkos for helping out. I was confused with the last step of token verification by AEF. Even the process is not mentioned in specifications clearly.

closed