Financial Grade APIs v2 (FAPI 2) Certification

I'm proud to announce that Curity has certified that the Curity Identity Server version 8.5.0 conforms to the FAPI 2.0 Security Profile Second Implementer's Draft & Message Signing First Implementer's Draft.

FAPI 2 is an evolution of the FAPI 1 profile for OpenID Connect. These profiles define how to use OpenID Connect in high-security scenarios, focusing on financial systems, but are definitely not limited to such use. The FAPI profiles and specifications come from the FAPI working group in the OpenID Foundation. This was previously known as Financial Grade APIs, but as the scope has broadened beyond financial applications, the name is simply FAPI.

FAPI 2 has taken a different approach from the previous version, looking more at the problem from a threat perspective by defining an attacker model. Based on this, two parts of the specification exist: the FAPI 2 Security Profile and the FAPI 2 Message Signing Profile. The latter is still in the works, but the relevant parts for an OpenID Connect Provider, such as Curity, are fairly complete and already possible to certify.

Building More Robust Security

It's easy to get lost in the standards and the acronyms, especially when dealing with specifications and security. Security is about risk and risk tolerance. There's always a tradeoff between how much security to add and how complicated the use of a system will become.

But as with most problems, it's a good idea to break it down into a few core considerations:

• How sensitive is the data or services we are protecting?

• What is the consequence if we have a breach?

• Where can breaches occur?

• Who is in control of those places?

On the first point, there is an obvious tradeoff. The data may not be sensitive per se — it may consist of user details or information that in and of itself isn't sensitive. But it may still be necessary to protect because of the second question.

In the second point, the consideration is more about what happens if the data is leaked or the service is misused. In the EU, with the General Data Protection Regulation (GDPR), a data leak (even with data that a company may not consider sensitive from a business perspective) may lead to massive fines and a bad reputation. But of course, other parts could expose details about the customer base that could be devastating for the organization. Leaking some data can lead to more sophisticated attacks based on that data that, in turn, can cause more damage.

When considering where breaches occur, especially for systems that expose APIs, it's important to remember that there is a trust between the caller of the API (the client) and the provider of the API. The provider trusts that the client was the one that actually sent the API calls. The client shouldn't be able to say: "I didn't send that." The more certain we need to be that the caller actually made the call, the more we need to think about the mechanisms in place to ensure this. 

This is where FAP 1 and FAPI 2 come in. They define which OAuth extensions should be used for stronger security and how. It should be very hard for a calling party to claim that "no, that wasn't me," and it should be hard to compromise the communication in a way that produces leaks.

FAPI2 Helps Protect API Access

As you can see, one organization cannot be in physical control of all places requiring high-grade security, which is why mechanisms must be in place to ensure that clients are acting correctly. Using FAP 1 and FAPI 2 improves the overall security for API access — both for the organization deploying the APIs and for the clients calling the APIs. This is valuable far beyond financial use cases and should be considered by most organizations when deploying services as APIs.

FAPI 2 has some advantages over FAPI 1 in being slightly easier to use. That's not insignificant, as the developer experience is essential when it comes to getting adoption for security.

At Curity, we strive to make the Internet a safer place, and the standards and profiles that assist in this mission are highly prioritized in our company. We're looking forward to seeing them becoming finalized and widely used.