Understanding and Implementing FAPI: From 1.0 to 2.0

FAPI, developed by the OpenID Foundation’s FAPI Working Group, is a set of security profiles built on OAuth 2.0 and OpenID Connect (OIDC) and designed to provide a consistent, high-assurance framework for API security.

FAPI tells you: “If you’re going to issue tokens for valuable data or high-impact operations, here’s how to do it safely and consistently across different systems.”

Originally created to support Open Banking initiatives and known as simply the “Financial API,” FAPI has evolved quickly. With the release of FAPI 2.0, the specification now addresses not just financial use cases but also secure API auth for a wide variety of use cases and industries, including healthcare, digital ID, and government data exchange systems. 

FAPI 2.0 has become a general-purpose security profile for building high-assurance OAuth 2.0 and OpenID Connect systems.

If you’re a developer diving into the implementation details of FAPI, it can be challenging to understand the FAPI landscape and how to best implement what’s needed for your specific use case. 

In this article, we’ll try to help. We’ll explore the major versions of FAPI and their differences. We’ll look at which version is right for your use case. And we’ll explore how you can use Authlete to help streamline your implementation. 

‍

FAPI 1.0 vs FAPI 2.0: What’s the Difference? 

There are two major FAPI versions: FAPI 1.0 and FAPI 2.0. Both versions are actively supported and in use. 

The 1.0 FAPI specification was finalized in March 2021 and has been widely adopted, including by many organizations that have certified FAPI conformance to specific profiles for use cases such as Open Banking, Australia Consumer Data Right (CDR), and Open Insurance. FAPI 1.0 introduced “Baseline” and “Advanced” security profiles and standardized request signing, client authentication, and token handling.

But 1.0 has limits. It was designed with financial APIs in mind, and it left each ecosystem to pick its subsets of requirements. The flexibility was useful, but the lack of newer primitives like Pushed Authorization Requests (PAR) or Demonstrating Proof-of-Possession (DPoP) meant FAPI 1.0 leaned heavily on specific validation/processing logic, which quickly became complex.

As a result, FAPI 2.0 was created.

With 2.0, FAPI is a general “FAPI Security Profile,” not just a financial API specification. FAPI 2.0 fixes the problems of FAPI 1.0, improves usability, and adopts the OAuth 2.0 Security Best Current Practice. The 2.0 specs include an Attacker Model and a Security Profile, plus additional profiles that cover more specialized needs.

FAPI 1.0 isn’t going away. The FAPI Working Group has said it will be supported for the foreseeable future. But it’s essentially feature-complete. 

If you’re starting a new project and have no restrictions, FAPI 2.0 is generally the better release to use.

When Should You Use FAPI 2.0 vs FAPI 1.0?

FAPI 2.0 builds on lessons learned from FAPI 1.0, is easier to use, and is broader in scope than 1.0. It provides a high-assurance framework built on OAuth 2.0 and OIDC to ensure consistent authentication and authorization across different ecosystems. 

Specific benefits of FAPI 2.0 include:

• Stronger security that is simpler to implement: FAPI 2.0 follows OAuth 2.0 Authorization Framework and OAuth 2.0 Security Best Current Practice (BCP 240/RFC 9700), mandates Proof Key for Code Exchange (PKCE), PAR, and sender-constrained tokens via Mutual TLS (mTLS) or DPoP, optionally adds JWT Secured Authorization Requests (JAR)/JWT Secured Authorization Response Mode for OAuth 2.0 (JARM) for further protection, and formally defines an Attacker Model that describes security goals the implementation will mitigate. 
• Robust interoperability: Improving interoperability between the client and authorization server, as well as the client and resource server (e.g., an API) was a primary goal of FAPI 2.0. FAPI 2.0 eliminates much of the variability of the “pick and choose” options in FAPI 1.0. 
• Improved developer experience: FAPI 2.0 provides developers with a much cleaner implementation path. It eliminates complexities such as choosing between “Baseline” and “Advanced” profiles and provides clear guidance on required and optional parameters. 
• Scope extended beyond finance: The 2.0 specifications are explicitly intended to address use cases beyond just finance and Open Banking. For example, the FAPI 2.0 security profile has been implemented across the entire Norwegian Health Network (NHN). 

So when would you still use FAPI 1.0? When your systems force you to: an existing Open Banking implementation, a vendor that only supports 1.0, or a legacy system that is too expensive to migrate. 

What’s Inside FAPI 2.0? Attacker Model + Security Profile Explained

Let’s next look in more detail at the FAPI 2.0 specifications.

FAPI 2.0 is built around two core documents: the Attacker Model and the Security Profile. Everything else (message signing, grant management, Client-Initiated Backchannel Authentication [CIBA]) is layered on top of these.

The Attacker Model

The Attacker Model defines the bad actors you should assume exist. It’s not a full threat model, but it gives you the raw material to build one. 

The Attacker Model specification defines six different types of attackers:

• Web attacker can send arbitrary requests from client browsers and send users malicious links.
• Web attacker (participating as authorization server) is a variation of the web attacker that also acts as an authorization server within the environment that can reuse or replay messages from legitimate authorization servers. 
• Network attacker controls an entire network and can tamper with messages intended for other recipients. Typically, attacks from this attacker can be mitigated by proper transport layer controls such as TLS 1.3 implementations. 
• Attacker at the authorization endpoint (reads authorization requests) has the same capabilities as the web attacker but can also read authorization requests.
• Attacker at the token endpoint (reads and tampers with token requests and responses) is an attacker that can force a client to use a token that is not from a legitimate authorization server. 
• Attacker at the resource server (reads resource requests) has the same capabilities as the web attacker and can also read requests the resource server has processed.

The point of the Attacker Model is to make the Security Profile concrete. Instead of a generic “be secure” language, the profile must defend against these specific attackers.

Security Profile

The FAPI 2.0 Security Profile defines the “you must” and the “you must not” statements. 

At a high level, the Security Profile defines requirements for:

• Network layer protections including minimum TLS versions, requirements for endpoints used by web browsers, and server-to-server network communication requirements. 
• Authorization servers such as the need to specific discovery metadata as defined in OIDC 1.0 and OAuth 2.0 Authorization Server Metadata (RFC 8414), mTLS or DPoP for sender-constrained access tokens. 
• Clients like the need to support mTLS and/or DPoP, not exposing open redirectors, and ensuring refresh token support. 
• Resource servers such as disallowing the use of query parameters for OAuth 2.0 Bearer Tokens and verifying the revocation status, integrity, validity, and expiration of access tokens.
• Cryptography and secrets such as how duplicate key identifiers are to be handled and specific requirements for the use of JSON Web Key Sets (JWKS).

FAPI 2.0 makes several changes to FAPI 1.0’s “Part 2: Advanced” specification. It uses DPoP as a first-class option for sender-constrained tokens, uses PAR (rather than pure JAR) to protect authorization requests and make them more interoperable, removes some front-channel ID token patterns, and streamlines redirect URI and client authentication handling.

Optional FAPI 2.0 Profiles: Message Signing, CIBA, and Grant Management

In addition to the Attacker Model and Security Profile, FAPI 2.0 supports several optional profiles that can help developers address specific use cases. These aren’t required for basic FAPI 2.0 compliance, but they’re powerful options when your needs go beyond standard flows.

‍

How to implement FAPI with Authlete

FAPI sounds great in theory, but implementation can be difficult and a lot of work.

To be successful, you need to understand OAuth and OIDC in depth, keep track of the evolving specs, implement PAR, JARM, JWK and JWKS handling, mTLS and/or DPoP, dynamic client registration, robust token validation, and the FAPI-specific rules. Then you need to pass conformance tests and remember to keep the implementation up to date.

Authlete makes this all easy.

Authlete is a developer-centric, headless OAuth 2.0/OIDC engine. You don’t deploy Authlete as a full “login page” or standalone Identity Provider (IdP). Instead, you integrate it into your services and gateways. Your applications, gateways, or API management layers call Authlete’s APIs to:

• Start and complete authorization flows.
• Issue and introspect tokens.
• Validate client authentication methods and configuration.
• Enforce FAPI-related rules around PAR, token binding, and more.

You keep control of the user experience: login UIs, consent screens, branding, and API behavior. Authlete handles the protocol-heavy work and the details of FAPI compliance.

• Authlete supports both major versions of FAPI and abstracts away the need for developers to become FAPI experts. If you need to integrate with an existing Open Banking scheme that mandates FAPI 1.0, Authlete lets you do that. At the same time, you can launch new services against FAPI 2.0 within the same environment and gradually move clients over as they’re ready.
• Authlete also has building blocks for the architecture FAPI expects: PAR, JAR/JARM, mTLS, DPoP, dynamic client registration, and sender-constrained access tokens. Instead of implementing each of these pieces yourself, you configure Authlete and integrate its APIs into your authorization server.
• Authlete also makes it easier to layer on optional profiles like CIBA, message signing, and grant management. It gives you primitives you can orchestrate from your own apps and gateways.

The end result is an architecture where:

• Your backend or API gateway remains the entry point for clients and resource requests.
• Authlete acts as the security and protocol engine, enforcing FAPI constraints and issuing tokens that comply with the relevant profiles.
• You can evolve your ecosystem from FAPI 1.0 to 2.0 (and beyond) without throwing away your existing infrastructure.

FAPI Made Easy

FAPI has grown from the niche “financial API” into a general-purpose security framework. The Attacker Model makes the threat landscape explicit. The Security Profile turns those threats into concrete requirements on TLS, authorization servers, clients, and resource servers. 

Implementing FAPI by hand is possible, but costly. Authlete gives you a way to offload that work to a dedicated engine while keeping control over your UX, APIs, and infrastructure. For many teams, that may be the difference between “looking at FAPI someday” and “we’re running a FAPI 2.0-compliant system in production.”

Next Steps:

If you’re an existing Authlete user and want to get started using FAPI, check out the FAPI 2.0 overview. If you’re new to Authlete and want to see how simple FAPI-compliant auth implementations can be, sign up for a free (no credit card required) trial.