Financial-grade API Security Profile (FAPI) 1.0 has been final for a while, and many implementations have been based on its profiles and specifications. While finalizing 1.0, work was already started on designing FAPI 2.0. FAPI 2.0 changes the format slightly from what we are used to in 1.0. Instead of having levels of compliance with the baseline and advanced profile, FAPI 2.0 creates an Attacker Model that defines potential attackers and security goals.

To protect against those attackers, a Security Profile is designed to achieve the security goals identified in the model. A Message Signing profile is defined for implementations that need a higher level of security. To implement this, an Implementation Advice document has been created with tips on implementing your platform to have complete protection in place.

Attacker Model Sets the Security Goals of FAPI 2.0

The Attacker Model aims to clearly define security goals and identify the potential attacker types FAPI 2.0 needs to protect against. The document is written so the other profiles can easily reference the attackers and goals to ensure the documents fulfill them. The other purpose is to use the Attacker Model within a formal security analysis of an API platform.

The Baseline Security

The Security Profile can be seen as the baseline of FAPI 2.0. It is a profile that recommends using different OAuth and OpenID specifications to protect against the attacks defined in the Attacker Model. The profile brings up topics like role requirements, security considerations, network layer protections, cryptographic algorithms, and others.

Considering security, we can read about known sensitive areas and how to protect them. The cases and mitigations all reference the Attacker Model and use the attackers it defines to clearly state the problem and how to mitigate it. In the requirements for the different roles, we find what flows the servers and clients need to implement to adhere to the profile. Some things are kept as in FAPI 1.0, but many requirements have been switched to newer technologies. Grant management and Rich Authorization Requests (RAR) were expected to be in the FAPI 2.0 profile but are not in the requirements section. Instead, both are mentioned as recommendations.

Let's look at some of the key differences between the two versions.

Code Flow Only

In FAPI 2.0, hybrid flow is removed, and only response_type=code is allowed. This means that all tokens are delivered in the back channel, removing the need for encrypted id_tokens. This eliminates much complexity for clients, since getting the id_token in the front channel requires validation to be sure the data can be trusted. All validation like nonce, s_hash, and at_hash can now be removed.

PAR and PKCE

Since there are no longer tokens in the front channel, the need for message integrity lessens. This removes the need for JWT Secured Authorization Request (JAR) and JWT Secured Authorization Response Mode (JARM). Instead, Pushed Authorization Requests (PAR) and Proof Key for Code Exchange (PKCE) are mandatory. 

In FAPI 1.0, the id_token acts as a detached signature, making it possible to validate that the response is for the correct request and that the parameters received belong together. Using PKCE and the Code Flow means that tokens are delivered in the backchannel over TLS, so we know where the response comes from. Only the code is in the response, and using PKCE means it's possible to verify that the two requests come from the same source, giving some CSRF protection. However, if the message integrity is important for your use case, JAR/JARM has moved to the Message Signing profile instead.

Sender-Constrained Tokens

Sender-constrained tokens are mandatory, and FAPI 2.0 allows for the use of Demonstration of Proof-of-Possession (DPoP) in addition to mutual TLS (mTLS). Worthy of note is that the use of the server nonce functionality of DPoP is encouraged. This functionality introduced in the specification quite recently protects against clock drift between client and server, and is something Curity implemented early on within the Hypermedia Authentication API (HAAPI) attestation protocol.

Non-Repudiation for FAPI

Message signing is a new profile that can be seen as the Advanced profile of FAPI 2.0. It aims to solve all the security goals of the Attacker Model, with the addition of achieving non-repudiation for all message types in FAPI. The profile is standalone, not an add-on to the Security Profile, so implementers must decide if they need the Security or Message Signing profile.

The profile describes ways to achieve the goals using existing specifications, some known from FAPI 1.0. For instance, the authorization requests and responses are signed using the PAR/JAR/JARM family.

One specification worth noting, the HTTP Message Signing specification, is used for signing resource requests/responses. This is a specification developed outside of the OpenID Foundation. The profile describes how to use it to achieve non-repudiation in requests and responses between the client and the resource server.

Implementation Advice

Work on the Implementation Advice document has only just begun, and we can expect it to grow. Currently, it only consists of a few pieces of advice, for instance, adding an x-fapi-interaction-id header to requests to track the same interaction across services. This is something that has been removed from the Security Profile since it's more advice than a baseline requirement.

Summary

A lot has happened in restructuring the FAPI 2.0 documents recently, and some goals are coming close to completion. The open issues list is shrinking, and much effort is being put into making FAPI 2.0 closer to being finished with each commit.

At Curity, we follow what's happening and try to participate where needed. As usual, we are also quick on implementing support for the profiles, and the latest 8.0 release makes the Identity Server fully compliant with the current draft of the Security Profile. Some work is left for the Message Signing profile, but most is already supported!

If you want to learn more, check out this webinar available on-demand - Next Generation OAuth and OpenID Connect. It provides an overview of the most important revisions and enhancements for the OAuth and OpenID Connect protocols, including OAuth 2.1, FAPI 2.0, SIOPv2 and verifiable credentials. Watch the webinar.