Why can you trust Open Banking?
Do you wonder how Open Banking is made possible? It requires trust among the ecosystem participants. This article provides a basic understanding of FAPI (Financial Grade API) and its underlying constructs, which makes open banking secure.
We will not be going into detail about the specification. It needs a background in all the underlying specifications to understand fully. However, we want to cover critical features of the FAPI profile.
FAPI profile is a layer on top of OAuth 2.0 and OpenID Connect, which "hardens" OAuth / OpenID Connect by specifying a set of constraints — called a profile — that limit or enforce the alternatives provided by OAuth / OIDC. FAPI is now being used as the basis for almost all open banking and finance standards worldwide.
The Open Banking initiative started in 2016, with the first draft of the specification published in 2017 and the final specification published in March 2021. Currently, FAPI 2.0 is under development and expected to be published in 2023. Many OpenID providers support FAPI 1.0, and some have support for FAPI 2.0.
Critical features of FAPI
1. Using secure Cryptography Algorithms
2. Transport Security using certificates
3. Constraint Token (token binding)
4. Advanced client authentication method
5. Secure parameter passing
6. Response validation
FAPI 1.0 has two specifications
1. Basic- Auth0 security profile for moderate-risk API
2. Advanced — Auth0 security profile for high-risk API
The basic profile broadly provides guidelines on cryptographic algorithms, clients-authentication methods, redirect Uri, nonce, state, and scope variables. This profile still supports public clients, which can expose authorization requests and responses to a potential attacker.
The advanced profile is designed for high-risk API, so this profile does not support public clients. In the rest of the article, we will elaborate on the critical features of FAPI to provide a degree of assurance for giving access to protected APIs.
1.Client Authentication
One of the critical security requirements is to authenticate clients using PKI infrastructure. The two most secure methods are client_secret_jwt and private_key_jwt; in client_secret_jwt method client signs a JWT with the client secret using a symmetric algorithm. On the other hand, in private_key_jwt, the figure below illustrates authenticating clients using private_key_jwt — passing a JWT signed by a private key with an asymmetric algorithm.
Apart from the above methods, the Mutual TLS method is recommended for additional security. In mutual TLS authentication token issued by the token end is bound to the TLS certificate. TLS metadata is registered during the client registration process and used for validating the TLS certificate. This reduces the risk of token attack vectors.
2.Secure Authorization Response
Authorization response typically returns data in the URL, e.g., state, code. This response could be miss used and prone to attacks. To prevent these attacks, FAPI 2.0 proposed JARM (JWT Secured Authorization Response Mode for OAuth 2.0). In this scheme, a new values for response_mode are proposed as query.jwt,fragment.jwt,form_post.jwt, jwt. All the data returned by the authorization endpoint is returned in this mode as a jwt token. This response type ensures that a malicious attack does not manipulate data.
1.Client Initiated Backchannel Authentication (CIBA)
In the traditional authorization code flow and implicit, a client application starts the flow by sending an authorization request to the authorization endpoint of the authorization server via a web browser. This results in redirecting the user to the login page in the same browser. The whole process happens within the browser, and finally, the user is directed to the destination page
https://medium.com/@vijay_751/openid-connect-part-2-20083b6fdade
In CIBA, authentication is initiated by the client (without a browser), and a new endpoint has been defined in the specification. This endpoint routes the request to the user for authentication. Below is the workflow for CIBA; it is also called a decoupled flow as it does not make assumptions about the authentication process, which can happen on a user's mobile device via notification.
CIBA (Client Initiated Backchannel Authentication) and FAPI are used together. The specification is called FAPI-CIBA Profile.
In addition to the above mechanisms, new specifications for securing the authorization request using OAuth 2.0 Pushed Authorization Requests (PAR) and OAuth 2.0 Rich Authorization Requests (RAR) are also recommended. We will cover them later in subsequent articles.
OkularID OpenID Connect is built on top of FAPI-compliant infrastructure. Currently, we support password-less login using Okular ID OpenID Connect. We would like to hear your use case.
OkularID is a unique digital identity management platform to authenticate and validate user credentials in the digital space. It is promoted by Aikaki Limited, focused on developing a user-centric digital identity wallet enabling users to share their credentials and digital assets and securely sign documents.