Why FAPI 2.0
FAPI 1.0 and FAPI Advanced have been adopted by many financial ecosystems including Open Banking initiatives which often require elevated security standards and interoperability. Its widespread adoption has helped to improve the security and interoperability of financial APIs, making it easier and safer for consumers to access and share their financial information across different platforms and services. You may ask - why the new FAPI standard is being introduced. Should it not provide enough security?
While work on FAPI 1.0 and FAPI advanced profiles was being finalized, work on FAPI 2.0 already started. The FAPI 2.0 suite of standards builds on this insight and wider learnings from the OAuth ecosystem including the latest OAuth Security Best Current Practice. FAPI 2.0 aims to meet and exceed the security characteristics as FAPI 1.0 while reducing the overall complexity and the optionality in the core security profile making FAPI 2.0 easier and more cost-efficient to implement. FAPI 2.0 differs from FAPI 1.0 by not introducing levels of compliance (baseline and advanced in the latter), but, instead, introducing the Baseline Profile and the Attacker Model that expresses the security requirements through security goals and attacker models.
FAPI 2.0 Baseline Profile
FAPI 2.0 Baseline Profile is a security profile created to safeguard APIs in important scenarios using the OAuth 2.0 Authorization Framework and other relevant specifications. Although the profile was primarily made for financial applications, it is adaptable to any situation where APIs with sensitive data, like e-health and e-government apps, need protection.
The Baseline Profile contains information crucial to reaching out security goals laid out in the FAPI 2.0 Attacker Model. It defines required/recommended technologies (OAuth standards), requirements for authorization and resource servers, and client applications.
FAPI 2.0 Attacker Model
During the work on first drafts of the FAPI 2.0 Baseline Profile, both FAPI 2.0 profile and FAPI 1.0 profiles underwent a formal security analysis by a team of researchers at the University of Stuttgart. As a result of those analysis, the Attacker Model was created. The FAPI 2.0 Attacker Model defines security requirements for the OIDF FAPI 2.0 API protection profile through security goals and attacker models. These requirements are used to derive the security mechanisms utilized in the Baseline Profile. The document helps implementers and users to understand which threats are considered by the Security Profile and which are not. The aim is to provide systematic proofs of security, but until then, the attacker model informs design decisions, although it cannot guarantee that all attacks by all types of attackers are excluded. The security requirements in the document can be transferred to a formal representation for analysis of FAPI security.
Example Attack Vectors Presented in the Attacker Model
Certain attacks cannot be completely prevented with current technology and are inherent to all redirect-based authentication and authorization protocols. These attacks were already known from previous protocols, including FAPI 1.0, and were expected to be identified during the detailed analysis of FAPI 2.0. Some examples of these attacks are:
-
Injection Of Stolen Access Tokens (Cuckoo’s Token Attack)
Involves an attacker stealing a valid access token and gaining control of an authorization server that is trusted by a client and a target resource server. While this is a theoretical possibility, it is a very difficult attack to execute. FAPI 2.0 requires sender-constrained access tokens which greatly reduces the likelihood of this attack occurring compared to most live OAuth 2.0 deployments. However, if tokens are not sender-constrained, this attack becomes much simpler. Even with sender-constrained access tokens, the formal model has shown that there are some scenarios where the attacker could use a sender-constrained token if they control the authorization server trusted by the client. This attack is unlikely to occur in many FAPI ecosystems due to the preconditions required. The FAPI 2.0 Security Profile provides three possible mitigations for this attack, should an ecosystem feel the need to defend against it.
-
Authorization Request Leaks that lead to CSRF (Cross-Site Request Forgery)
An attacker can use a CSRF vulnerability to deceive a user into believing they are accessing their own account, when in reality they are accessing the attacker’s account. This can be dangerous in certain situations, such as when a user mistakenly uploads sensitive data to the attacker’s account. All redirect-based flows are susceptible to this attack, and the FAPI 2.0 Security Profile lists three potential solutions for preventing this type of attack.
-
Browser-Swapping Attacks
All redirect-based flows are vulnerable to this particular attack. Again, it has unlikely preconditions: the attacker has to trick a user into following a link, and then be able to capture the authorization code issued to that user following successful authentication. FAPI 2.0 details possible mitigation strategies for this attack.
What’s New In FAPI 2.0
Find out the most notable changes that come with FAPI 2.0 Baseline Profile. For more information, explore the Baseline Profile.
No Hybrid Flow Supported, Only Authorization Code Flow
In FAPI 1.0, authorization servers could allow client applications to use the response type
parameter set to code id_token to get the ID token along with the authorization code. In FAPI 2.0
Baseline Profile, this requirement is changed and the client applications may request only the
authorization code (response type parameter set to code) to prevent ID tokens (containing
information about the authenticated user) from being exposed in the front-channel.
PAR and PKCE Mandatory, JAR and JARM Optional
FAPI 1.0 used ID tokens as a detached signature. Although the name “ID Token” implies that it identifies the resource owner, it may only contain an ephemeral subject identifier. The ID Token served as a detached signature of the issuer to the authorization response in this case, which was an intentional design choice in OpenID Connect Core.
Getting rid of the ID tokens in the front-channel lessens the need for the authorization request integrity. JWT Secured Authorization Request (JAR) and JWT Secured Authorization Response Mode (JARM) are no longer needed as much as they were to have a maximized security level. Instead, sending Pushed Authorization Requests (PAR) and using Proof Key of Code Exchange (PKCE) become mandatory.
Both JAR and JARM are still available to be used in cases when the request integrity is of utmost importance.
mTLS or DPoP for Sender-Constraint Tokens
In addition to mutual Transport Layer Security (mTLS), FAPI 2.0 allows the use of Demonstration of Proof-of-Possession (DPoP) to constraint access and refresh tokens only to the sender. DPoP enables client applications to prove the possession of a public/private key pair. Authorization servers can then bind issued tokens to the public part of the client’s key pair. Where mTLS is not available or desirable, DPoP is the way to go.
Message Signing Profile - Is This FAPI 2.0 Advanced
OIDF FAPI 2.0 Message Signing Profile is part of the FAPI 2.0 family of specifications with a focus on providing interoperable support for non-repudiation across OAuth 2.0 based requests and responses. It aims to reach the security goals laid out in the Attacker Model plus the non-repudiation goals.
Beyond what is captured by the security goals and the attacker model, parties could try to deny having sent a particular message, for example, a payment request. For this purpose, non-repudiation is needed.
In the context of this specification, non-repudiation refers to the assurance that the owner of a signature key pair that was capable of generating an existing signature corresponding to certain data cannot convincingly deny having signed the data (NIST.SP.800-133). This is usually achieved by providing application-level signatures that can be stored together with the payload and meaningful metadata of a request or response.
Summary
FAPI 2.0 is coming and you should prepare yourself! At the moment, all FAPI 2.0 documents are still in the draft phase, but it is certainly the time to watch out for it being ready.
At Cloudentity, we know what’s going on, where it is going, and more. We already have support for all the technologies listed in the Baseline Profile and the Attacker Model. You can use, for example, PAR, PKCE, or JAR and JARM if needed. We have both mTLS and DPoP available! Don’t wait!