Common FAPI Misconceptions

For some time now, I've been interested in FAPI from both an Identity practitioner's and a developer's perspective. I've written a few posts on this topic on this blog and created a guide to FAPI with the support of colleagues who are much more experienced than I am. Surfing the web and talking to developers, however, I couldn't help but notice some misunderstandings about certain aspects of FAPI.
In this article, I'll summarize the most common and recurring ones.

Misconception 1: FAPI Is a New Protocol

FAPI is a security profile based on OAuth 2.1, it is not a new protocol, intended as an alternative to established standards like OAuth 2.0, SAML, or OpenID Connect (OIDC).

It acts as a prescriptive blueprint that defines exactly which OAuth 2.0 and OIDC extensions must be used and how they must be configured. While the core OAuth 2.0 specification (RFC 6749) is a flexible framework that provides a "toolbox" of flows and leaves security decisions to the implementer, FAPI removes this "dangerous flexibility" to ensure a secure-by-default posture.

Misconception 2: FAPI Is for Banks and Financial Organizations

The "F" in FAPI originally stood for "Financial," reflecting its initial goal to protect banking applications. However, the scope has expanded significantly. Today, FAPI is a general-purpose high-security profile for any industry handling sensitive, high-risk data. Major applications include:

• E-Health: Protecting Patient Health Information (PHI) in standards like HL7 FHIR.
• E-Signing: Securing the underlying API calls for legally binding digital signatures.
• Government Services: Managing Personally Identifiable Information (PII) and government services.

Misconception 3: FAPI 2.0 Is an Incremental Update of FAPI 1.0

Some people mistakenly believe FAPI 2.0 is a minor version bump that maintains backward compatibility. This is incorrect. FAPI 2.0 is a complete redesign based on lessons learned from FAPI 1.0, specifically aimed at simplifying the developer experience.

A key change is the removal of the OpenID Connect Hybrid Flow used in FAPI 1.0 "Advanced," which required complex front-channel validations of ID Tokens. FAPI 2.0 replaces this with a hardened Authorization Code Flow where all tokens are delivered via the back-channel.

Misconception 4: OAuth 2.1 Makes FAPI Redundant

As OAuth 2.1 incorporates modern best practices like PKCE and the removal of the Implicit Flow, some wonder if FAPI 2.0 remains necessary. However, the difference between the two is significant.

OAuth 2.1 is a "Best Current Practice" consolidation for the general community, while FAPI 2.0 is a "high-security profile" that mandates features OAuth 2.1 only recommends. Crucially, FAPI 2.0 is built on a Formal Attacker Model, providing proof of security against specific threats that OAuth 2.1 does not formally address.

Misconception 5: You Can Use Any Type of Client with FAPI

Standard OAuth 2.0 allows for both public (e.g., mobile, browser-based) and confidential (server-side) clients. However, while FAPI 1.0 Baseline specification allows for public clients, FAPI 1.0 Advanced and FAPI 2.0 explicitly excludes support for them.

FAPI 2.0 focuses on confidential clients because they are capable of protecting a private key. This is the cornerstone of FAPI’s security model; a client cannot perform asymmetric authentication or prove possession of a sender-constrained token if it cannot keep its private key secure.

Learn FAPI to move beyond OAuth bearer tokens and implement top identity security.

DOWNLOAD YOUR FREE EBOOK

Misconception 6: You Can’t Use Public Clients with FAPI

As a consequence of the previous point, you may conclude that you can’t use public clients at all with FAPI. So, you can’t have mobile applications or SPAs in a FAPI-based system.

Actually, this is not entirely true. You can still have public clients in a FAPI context provided that they don’t manage ID and access tokens. For example, you can have a SPA if you are using an architectural pattern like the Backend for Frontend pattern.

Misconception 7: Pushed Authorization Requests Support Simply Shortens URLs

Developers often view Pushed Authorization Requests (PAR) as merely an optional optimization for long URLs. In reality, FAPI 2.0 makes PAR mandatory because it moves the entire authorization request from the risky environment of the browser to the secure back-channel.

Standard GET requests expose sensitive data (scopes, identifiers) to browser history, server logs, and Referer headers. PAR solves this by having the client POST parameters directly to the server, receiving an opaque request_uri in return. This ensures:

• Confidentiality: Sensitive parameters are never in the URL.
• Integrity: The server authenticates the request before the user is ever involved.
• Reliability: It bypasses URL length limits that often break complex authorization requests.

Wrapping Up

The journey through the FAPI landscape often involves navigating a complex mix of technical details and outdated assumptions. As this article has shown, FAPI is far more than an obscure security framework for banks; it is a critical, mature security profile that strips away the risky flexibility of standard OAuth 2.0 to offer a secure foundation for any system handling high-value data.

From understanding that FAPI is a profile, not a new protocol, to recognizing the fundamental changes in FAPI 2.0 and its mandated use of features like Pushed Authorization Requests (PAR), a clear picture emerges. FAPI’s strict reliance on confidential clients and back-channel communications is a pragmatic response to known threat models, ensuring integrity and confidentiality where it matters most.

Embracing FAPI is not about adding unnecessary complexity. It is about adopting a proven security posture necessary for protecting assets in e-Health, e-Signing, government services, and beyond. By moving past these common misconceptions, organizations can leverage FAPI to build truly robust and compliant high-security applications.

Here is an infographic that summarizes the misconceptions discussed in this article. Keep it handy: