The OFP provides a variety of methods for authenticating the interface between LFIs and OFP at the application layer.

This document provides an overview of the options available, the configurations that have to be agreed and the implementation that LFIs would have to carry out for the selected option.

1. Application Layer Authentication Switched Off

In its simplest implementation, Application Layer Authentication can be switched off.

This is the “do nothing” alternative and hence the easiest to implement.

API calls are not authenticated and the integration relies on the integrity of the underlying mutual TLS mechanism in and by itself.

The main drawback of this approach is the lack of defense-in-depth by relying on a single layer mechanism for authentication.

This setting can be applied in both directions

2. API Key

API Keys are the most rudimentary form of access tokens. This is a shared secret that is used between the LFI and the OFP.

Generally, shared secrets are not a strong security mechanism and provide limited security benefit. However, this may be appropriate to use as a starting point for LFIs or for LFIs that use a pre-existing API Gateway that enforces the use of an API Key.

The use of an API Key is only supported for Ozone Connect (ie in calls made from the OFP to the LFI)

The Consent Manager and Authorisation Server APIs do not support the use of API keys.

Operationally, the OFP supports the use of API Keys with a validity of 12 months or more. Key rotation is supported annually.

3. Client Credentials Grant

The OFP supports the use of an access token obtained through an OIDC client credentials grant

The OFP acts as a relying party (client) to an authorisation server managed by the LFI.

This is a fairly secure mechanism in general, and its strength can be increased by using the measures specified by implementing a FAPI profile.

The downside of this mechanism is that it would require the LFI to maintain its own authorisation server. Additionally, this may result in a small drop in performance as the OFP has to make an additional API call to the LFI

The use of Client Credentials Grant is only supported for Ozone Connect (ie in calls made from the OFP to the LFI)

The Consent Manager and Authorisation Server APIs do not support the use of a Client Credentials Grant.

Where a client_secret is used to obtain the access token, the client_secret must have a validity of 12 months or more. Secret rotation is supported annually.

4. JWT Auth

JWT based Authentication or JWT Auth as we often call it is a Ozone standard for secure and efficient application layer authentication.

In this approach, the requestor creates a token using a private key and a set of well-defined claims. The receiver verifies the token by verifying the signature using the corresponding public key.

The approach offers the advantages that:

• the tokens are generated using PS256 - a secure assymetric algorithm that does not rely on shared secrets

• Additiona infrastructure setup is not required

• The keys utilise standard JWS and JWKS which is widely supported in many programming languages

• In the CBUAE context, the signing keys that are used are generated and managed by the OFTF

• Key rotation is managed by the sending party. The receiving party uses a JWKS for verifying the JWS. The sender can rotate keys as often as they please!

• The sender can decide on the validity period of the token based on their security posture

• The standard specifies claims that bind the token to certificates with a specific OU and DN in the underlying mutual TLS layer.

The disadvantage of the approach is that this is based on a proprietry standard and LFIs have to develop their own implementation for creating and validating jwt auth tokens.

The use of jwt auth is supported by Ozone Connect, Consent Manager and Authorisation Server APIs

5. Service Initiation Token

As a further security mechanism, the OFH allows the use of a service initiation access token.

The LFI may set an access token for each service initiation consent. When the OFP calls Ozone Connect to initiate the service (e.g. to make a payment), the OFP will include the specified service initiation token in the authorization header for that specific API call.

The LFI may chose to rotate the token by patching the consent at any point of time.

The use of a Service Initiation Token is only supported on service initiation calls to Ozone Connect.

This feature may be used in conjunction with any of the other mechanisms listed above as an override.