Open banking continues to be a subject of keen interest in financial services, reaching “buzz word” status over the last few years. We’ve covered the growth of the ecosystem on the blog several times before, but haven’t yet studied the standards emerging both within and across open banking markets. It comes as no surprise open banking initiatives have spurred several notable advancements in standards. In this post, we’ll look at a suite of standards that focus on improving API security: The Financial-grade API (FAPI) Profile.

What is FAPI?

FAPI is a working group of the OpenID Foundation, the body responsible for the development and maintenance of a family of protocol standards centered around OpenID Connect. FAPI was initiated in 2017 and sought to bring enhanced security to the new API standards being created to deliver PSD2 regulations across Europe, one of the key drivers in the buzz around open banking.

The scope, however, is not limited to PSD2 and the regulatory aspect of open banking. According to FAPI, its goal is to provide a “higher level of security than provided by standard OAuth or OpenID Connect.” The standards also frequently refer to screen-scraping and the purpose of replacing this method with “an API model with structured data and a token model, such as OAuth.”

To existing adopters of OAuth and OpenID Connect the benefits might seem obvious, but for the uninitiated:

• One of the primary goals of OAuth is to ensure that the End User – a real human being – does not have to give their confidential credentials when sharing data with another app.
• By offering a delegated access model, OAuth ensures that the Client app – the “Relying Party” never sees those credentials but instead uses an access token.
• OpenID Connect adds to this model by providing proofs-of-authentication that the app both has delegated access to an API on behalf of the End User and proof that the real human being actually authenticated. As we covered in our introduction to OpenID Connect, not having proofs-of-authentication may be fine for Tweeting your best score on Wordscapes, but it’s not so great when accepting a payment instruction from an app that may or may not be acting on behalf of an authenticated End User.

OAuth has its detractors, especially in how the redirection mechanism for authenticating the End User introduces friction. However, arguments for the security benefits are sound. FAPI, therefore, uses OAuth as its base profile for a good reason. FAPI currently incorporates four standards, all currently specified as Implementer’s Drafts (in the parlance of standards an Implementer’s Draft means “stable enough to implement, but not quite formally approved”). These are:

• Part 1: Read Only API Security Profile
• Part 2: Read & Write API Security Profile
• JWT Secured Authorization Response Mode for OAuth 2.0 (JARM)
• Client-Initiated Backchannel Authentication (CIBA) Profile

Generally speaking, Parts 1 and 2 and JARM are concerned with hardening the implementation of OAuth 2.0 and OpenID Connect, while CIBA provides a new means of requesting the authentication of an End User. Each profile has implications for both the API Provider and Consumer, which we’ll discuss below.

The Read-Only and Read-Write Profiles are effectively the “base” specifications for organizations wanting to attest to the level of security perceived as being required for operating financial services APIs. The entry criteria is OpenID Connect 1.0; both these standards use this as its core building block.

Adding Resilience: The Read-Only Profile

The Read-Only Profile is aimed at read-only access to an End User’s account and introduces features that are carried into the other profiles. The goal is to specify behaviors that the actors will adopt when interacting to provide account-based data. These include:

• Enforcing strong levels of authentication for Clients, including Mutual Transport Layer Security (TLS) and a JSON Web Token (JWT) based mechanism for authenticating the Client at an application level.
• Enforcing levels of authentication for the End User, specifically at Level 2 from the ISO specified Entity authentication assurance framework. This is important for providing the Client application with certainty on how the End User authenticated.
• Implementing levels of cryptography strong enough to protect the parties involved, such as enforcing minimum key lengths of 2048 bits for RSA algorithms.
• Tightening up on other behaviors allowed inside the core OAuth 2.0 specification, such as requiring that all redirect_uri settings are pre-registered at the Authorization Server.
• Ensuring that short lifetimes are used for Access Tokens that are bearer tokens, given the number of different endpoints they may be exposed to in an account-access scenario.

At a very practical level, the Read-Only Profile also mandates the use of JSON in request/response payloads. It introduces several headers that allow consistent identification and tracking of events, with the subjects being fairly typical in financial services APIs:

• x-fapi-interaction-id: A UUID that provides a unique reference to be created for each request/response.
• x-fapi-auth-date: The date and time that the End User was last authenticated by the Client application.
• x-fapi-customer-ip-address: The IP address of the End User, if available.

The Read-Only Profile, therefore, provides standards for tightening the operating parameters to a degree deemed suitable for the sharing of account access.

Bullet-Proofing: The Read-Write Profile

The Read and Write Profile adds further constraints that are considered applicable for creating or updating account data through – for example – initiating a payment. Arguably the most important additional constraints introduced by the Read-Write Profile are:

• Enforcing the use of a signed-JWT (JWS) to encapsulate Request parameters when a Client application sends an End User to the Authorization Server to be authenticated (the request parameter). We touched on this in our OpenID Connect introduction. This is important as it adds cryptographic proofs of the identity of the Client application, meaning the Authorization Server can verify it. This is an optional aspect of OpenID Connect that becomes mandatory with the Read and Write Profile. The standard also specifies a REST API that can be used to send parameters securely to the Authorization Server and then reference them using the request_uri parameter.
• Mandating that Client applications are proved to be a “holder of key.” Key-based authentication mechanisms (for the Client) are permitted, through either Mutual TLS for OAuth or a JWS minted from a private key. This improves security as direct access to the private key must be sought by the miscreant in order to impersonate a valid Client and is enforced at both the Authorization Server and the Token Endpoint.
• Increasing the End User authentication assurance level to Level 3, enforcing multi-factor authentication which – in the context of PSD2 – means multiple things the user knows, possesses, or is part of them (“Inherence”), such as a biometric gesture.
• Restricting the cipher suites that can be used for Mutual TLS to reduce the risk of a compromised transport layer.

The Read-Only and Read and Write Profiles, therefore, provide important general additional protections to both the API Consumer and Provider. The JARM Profile looks to complement this by protecting one of the more vulnerable areas of OAuth, namely the exchange of authorization codes.

Improving OAuth 2.0: JWT-Secured Authorization Codes

The JWT Secured Authorization Response Mode (JARM) Profile does – largely speaking – what it says on the tin; it aims to secure authorization response parameters through the use of a signed and optionally encrypted JWT. In this mode, a secured authorization code is requested by the Client application, with the Authorization Server providing the response signed using a private key it owns. The Client application has access to the public certificate corresponding to this key so it can verify the signature (if the JWT is signed and encrypted, the Client will require access to both the signing and encryption public certificates).

The signing and optional encryption of the authorization code delivers additional protections for the Client against code replay style attacks in an OAuth-only implementation, similar to the benefits of the Request parameter in the Read/Write profile. Arguably it is the least pervasive standard within the suite, with Client-Initiated Backchannel Authentication breaking the newest ground.

Decoupling Authentication: Client-Initiated Backchannel Authentication

Client-Initiated Backchannel Authentication (CIBA) is the latest – and arguably most complex – of the FAPI profiles. It attempts to address two of the primary sticking points in the Open Banking ecosystem at the moment, namely:

• To allow a user to authenticate and authorize an operation on a different device to the one they are using. For example, if an End User is using a desktop application but can only authenticate via a biometric stored on a mobile device, which is tied to the mobile operating system (rather than an open standard like Webauthn.)
• To allow for multiple real human beings to authorize the sharing of data or initiation of payment. This is important as the majority of corporate internet banking implementations adopt an “x-eyes” approach to authorizing sensitive operations, with associated workflows, queues, and notifications for the participants involved.

Both these needs are at odds with the majority of Open Banking implementations. Most processes expect to redirect a single user to perform the acts of authentication and authorization either within the browser or via a claimed URL to a mobile banking app. Some standards have loosely addressed some aspects of this; for example, the UK standards exposes a “MultiAuthorization” property in their Consent resource. However, the authorization workflow in this scenario is a facet of the API standards rather than the security protocol, which seems somewhat orthogonal and relies on the client polling an API to discover changes in the authorization state.

CIBA provides the flexibility to address these needs elegantly. Rather than expecting a synchronous or semi-synchronous response, CIBA anticipates an entirely asynchronous workflow:

• The Client application makes an Authentication request to the Authorization Server, using a hint to indicate the user they would like authenticated. The hint is provided through knowledge known to both parties – an email address, a shared identifier, or proofs-of-authentication previously offered, such as an ID Token.
• If the Authentication request is successful, the Authorization Server initiates backend workflows – either directly or through other components – to ask one or more End Users to authenticate themselves and authorize the request, through whatever means (mobile, desktop, etc.) are required by their internal application infrastructure.
• When all required End Users have completed authentication and authorization, the Authorization Server calls the Client application at a known webhook to indicate authorization is complete.
• The Client application can then visit the Token endpoint to retrieve a new token that allows them to access a protected resource.

The workflow for Client-Initiated Backchannel Authentication (CIBA), the latest FAPI profile.

There are permutations to this flow. For example, the Client application can poll the Authorization Server if no webhooks can be made available. But, the specification can offer Relying Parties a completely decoupled means to request user authentication and authorization. This massively increases usability and gives Clients many different options as to how they design their user experience with redirection no longer being a fundamental requirement.

Final Thoughts

The prevalence of the FAPI is, of course, only as good as its adoption. There will be a lag between Implementers Drafts becoming available and their inclusion in supporting open source and vendor solutions. Hopefully, adoption will continue to increase as the suite of standards can only serve to provide more secure implementation in Open Banking ecosystems.

Developers cannot view security as a static notion that, once dealt with, can simply be marked “Done” and forgotten. Open Banking ecosystems will continue to evolve, especially as we move from solely banking-focussed APIs into the realms of Open Finance. As such, how we define and apply appropriate security protocols must also evolve. This is especially true when we consider the role of digital identity and its relationship with the OpenID Connect stack. The union of identity and “open everything” ecosystems means security profiles such as FAPI will only become more critical.