API regulations are at three levels to be followed by the respective entities and implementers. One is at the level of regions or countries. In Europe, there are PSD2 regulations that are predominantly for the European market. The last is a market-driven approach to open banking, and they are still emerging and working on regulations or regulatory bodies.
When we talk about traditional banking, there are fewer actors than in open banking. When there are more actors, there are more chances of risk and threats associated with each actor and the entry points.
Consider a user who wants to carry out some payments through his mobile app. To complete the transaction or use the app’s services, the user has to prove their identity. So for that purpose, there is another actor, which is the identity server. It could be an internal or external, or federated identity server. On top of that, there could be other partners. All these actors talk to the APIs of the financial institution. Today, most of the APIs use a token-based approach.
Thus, there are different actors, risk factors, and ways of securing all those aspects, starting with the user, because none of the APIs you will be exposing for this bank system will be non-user agnostic. That means a user can access the API only after proper authentication. No API should be invoked directly by the client app. Protecting the user’s identity and maintaining privacy and consent while using the APIs and its services through a third-party app is very important. Clients or apps should be authenticated securely while communicating with or consuming APIs. Banks must ensure that requests accessing the APIs have appropriate security measures. They must ensure that the presented tokens are authorized, authenticated, and checked with the issuing party. The identity server must ensure that trusted tokens are presented to access APIs. Thus, there is a big ecosystem that is based on trust, and the trust is checked at every point. So, to check trust at each point of interaction, we need to have security controls.
Introduction to FAPI – Financial Grade API
OAuth and OpenID Connect (OIDC) are the protocols for interacting with the identity provider and consuming the APIs. FAPI is a technical specification built on top of these two protocols.
OAuth and OIDC have certain ways of authentication. FAPI has introduced additional security controls, providing higher security for the APIs that need to be exposed through these channels.
There are two FAPI profiles –
Baseline – provides baseline security controls for APIs. They are mainly used for read-only APIs.
Advanced – usually used for transactions, e.g., initiation, addition, or deletion of beneficiaries.
Introduction to CIBA – Client-Initiated Backchannel Authentication
There are scenarios where smart devices interact with the end user to do certain actions or provide certain services through the service providers. For example, a user uses a smart system to get some information using a smart speaker. The smart speaker will talk to the end system after ensuring the user is authorized to get the information. In such cases, you usually don’t have anything to interact with the concept. A consumption device is consuming the service. So that’s why the client will initiate a backend channel authentication request. Once the request is placed, it will send a decoupled request to the user’s other smart device or authentication device to get the authentication approval. Once it is received, it will complete the audit cycle, where you will issue the access token used to access those APIs or services. There are three flavors – POLL, PING, and PUSH.
There are different ways to obtain the token, where the backend can keep polling until the user completes the authentication. This is called a POLL. Once the authentication is completed, the identity server will PING the backend system that the authentication is completed, and then the backend will retry to get the access token. Finally, the PUSH mechanism is where once the user approves or completes authentication, the identity server or authorization server directly sends the access token to the backend system without asking the backend system to retry or reinitiate an API to get the access token.
Why is FAPI Important?
FAPI specification provides some major security controls that must be followed to make your product FAPI compliant. These security controls are put in to ensure that any actor interacting with the other actor has been trusted, with authentication or credentials required for that transaction’s security control.
FAPI has added one more security layer, which says that the client should be secured with more controls. To authenticate the client, the ID server needs to ask clients to sign the JWT using the client’s secret or private key, which is exchanged between the identity server and the client app.
FAPI also asks for Mutual TLS, where you ensure that both the client and server verify each other’s SSL certificates. This handshake happens by having those certificates pre-exchanged or having publicly trusted certificates.
There could be issues with tokens being leaked or hijacked to invoke APIs. FAPI has introduced a certificate-bound access token. This ensures that the resource server or API management layer checks that the token is not hijacked or leaked.
FAPI protects request parameters in the URL from being exposed. OAuth has a Pushed Authorization Request (PAR). FAPI recommends using PAR for at least advanced profile API invocations.
When you are interacting with an identity server, ensure that these identities are always the same and trusted. It is not a fake identity provider proxying your request and taking your credentials or using the code or access tokens. To protect that, FAPI has placed security controls that can take care of APIs to ensure that the code and state are also attached and signed by the JWT issued by the identity server.
Finally, FAPI also talks about non-repudiation, where the ID token is used as a detached signature, where the actual content and the signature are not in the same packet. The requester knows the parameters which are presented while taking the token. Once the token is issued, it has the signature of all those parameters where the requester can validate that it is coming from the intended identity server.