Welcoming the Finalization of FAPI 1.0

A standardized, certified approach for financial APIs is necessary to further open banking initiatives throughout the globe. Without one, it’s difficult to deliver the reliability, repeatability and security required to adhere to open banking rollout schedules worldwide.

That’s why it’s welcome news that the OpenID Foundation’s Financial-grade API (FAPI) Working Group recently announced the publication of final versions of their 1.0 security profiles. This marks an important milestone in the ongoing journey of codifying implementation and deployment guidelines for open API access with enhanced security utilizing the OAuth family of specifications.

Nat Sakimura, co-chair of the FAPI WG, after accepting an industry award for related work at 2018 Identiverse.

I first heard about FAPI in 2015 or 2016 at an OpenID Foundation Workshop hosted somewhere between San Jose and San Francisco in a nondescript conference room on some huge corporate campus. I listened to Nat Sakimura introduce the working group and its lofty goals of replacing user password replay and screen scraping in the financial sector with standardized, secure, delegated API access. My reaction at the time was twofold: I thought the name was pretty terrible, and I was skeptical (my default stance on most things) that the whole effort would gain much traction. 

I still think I was right about the name—it is shorthand for “Financial API” but the sound of “FAPI” when said out loud is simultaneously silly and unseemly. To this day, I still cringe a little bit whenever I hear or say it. But the acronym is here to stay, and even survived a rename of the group from “Financial API” to “Financial-grade API.” 

It turns out, however, that my skepticism about the future interest and applicability of the work was unfounded. Things didn’t play out exactly as anticipated, as the financial API standards themselves never materialized. Instead, the working group’s efforts focused on producing security profiles, which were suitable not only for financial transactions but also applicable to higher-value API security in other industries and ecosystems. (Hence the “-grade” part being added to the name.)

And although it didn’t unfold quite like predicted, I’m still struck by Nat’s foresight in convening the FAPI work ahead of a latent need that would be borne out in the years to come by open banking and other open API initiatives emerging around the world.

OpenID Foundation Workshops typically feature this kind of red carpet welcome, although this may not have been the particular meeting where I first learned of FAPI.

There’s a lot going on in the FAPI working group, including a CIBA security profile, the often overlooked JARM draft and some forward-looking work. The finalized 1.0 security profile, however, is particularly impactful right now and has already seen substantial adoption around the globe. 

The security profile is made up of two parts, Baseline and Advanced, where the latter builds on the former with successive requirements. The split is unfortunate because the baseline is rarely, if ever, used on its own. So, for the most part, you can think about them as a single thing: FAPI 1.0. 

In essence, it adds these security requirements to classic OAuth:

• JWT signed authorization requests, with additional requirements on the presence of some claims  

• Asymmetric key-based client authentication using MTLS or client JWT

• A detached signature over the authorization response utilizing the OpenID Connect “code id_token" hybrid flow

• MTLS sender-constrained access tokens

Despite looking pretty simple when broken down to a few bullet points like that, FAPI 1.0 has some very rough edges. Signed authorization requests are complicated by having been historically specified in both the IETF and OpenID Foundation, with some missing pieces and differences between the two. Mutual-TLS is useful but can be quite cumbersome (to put it politely). And while using the ID token as a detached signature to secure the authorization response makes some pragmatic sense, it is really a misuse of the ID token. 

The ID token is intended to convey identity for sign-on for the security profile that is otherwise only about API access—a layering violation that has been cause for confusion and complexity. Although there’s a lot of value in FAPI 1.0, it is somewhat inaccessible to organizations without significant resources and specific expertise. 

Aiming to make things more accessible, work on FAPI 2.0 was well underway before 1.0 went final. It’s still in draft and will take some time, as these things do. Furthermore, there’s little doubt the competing versions will cause some confusion, which this FAQ endeavors to mitigate. But I view the general direction of FAPI 2.0 as a major positive overall. With the benefit of hindsight, experience and some new specs and best practices to work with, FAPI 2.0 and its Baseline profile in particular look poised to be a significant improvement over the predecessor. 

The FAPI 2.0 Baseline profile provides roughly equivalent security properties to the Advanced profile of FAPI 1.0, but achieves it in a simpler, more straightforward way. Notably, PAR and PKCE obviate the need for signatures on the authorization request and response, a major simplification that allows OpenID Connect to step out of the picture entirely. The option of DPoP for sender-constrained access tokens allows for the profile requirements to be met with application layer constructs, removing another big barrier to deployment accessibility. 

There’s more work under the FAPI 2.0 umbrella, including a detailed threat model, an advanced profile that aims to provide nonrepudiation by adding a signature to just about everything, and a grant management draft that endeavors to give the client more predictable interoperable control over and visibility into its grants at the authorization server. But for now, the relative simplicity and value of the FAPI 2.0 Baseline security profile is the most exciting development, and I look forward to this next stage of the working group’s efforts.

Interested in learning more about API security as applied to financial services? Please read our whitepaper, “Strengthen Your Financial API Security.”