Strengthening OAuth 2.0 with FAPI 2.0

Source: Dev.to

OAuth 2.0 has long been the cornerstone of modern authorization, powering everything from social logins to complex enterprise integrations. Its flexibility allows developers to adapt the framework to various scenarios such as traditional web applications, single‑page applications, desktop, and mobile environments.

The Challenge with Vanilla OAuth 2.0

Because OAuth 2.0 is a framework rather than a rigid protocol, it offers a collection of optional features. In high‑risk and regulated sectors—banking, healthcare, insurance—this freedom creates a large surface area for configuration errors and interoperability issues. Security vulnerabilities often arise not from flaws in individual specifications but from how they are combined (e.g., using the Authorization Code Flow without PKCE or with insecure redirect URIs).

Introducing the FAPI 2.0 Profile

FAPI 2.0 is a security profile developed by the OpenID Foundation. Unlike its predecessor, it emphasizes simplicity and robust interoperability. It is not a new protocol; rather, it is a prescriptive profile that defines exactly which OAuth 2.0 and OpenID Connect extensions must be used and how they must be configured.

Key characteristics

• Built on a formal attacker model that assumes a high‑threat environment (network control, front‑channel interception).
• Enforces a “secure by default” posture, removing optional security best practices.
• Provides a standardized level of resistance against modern attack vectors such as session injection, token theft, and authorization request tampering.

Core Security Enhancements

FAPI 2.0 strengthens OAuth 2.0 in three main areas: hardening the authorization request, eliminating bearer token risks, and improving client authentication.

Pushed Authorization Requests (PAR)

Mandated by FAPI 2.0.
The client sends authorization parameters (scopes, PKCE challenge, etc.) via a secure back‑channel POST request before redirection. The server returns a short‑lived request_uri used in the subsequent browser redirect, ensuring sensitive data never appears in browser history or logs.

Sender‑Constrained Tokens

FAPI 2.0 replaces vulnerable bearer tokens with tokens cryptographically bound to the client:

• Mutual TLS (mTLS): Binds the token to the client’s X.509 certificate.
• Demonstration of Proof‑of‑Possession (DPoP): An application‑level solution where the client signs a JWT with a private key for each request.

These mechanisms prevent token misuse even if the token is stolen.

Asymmetric Client Authentication

Shared client secrets are replaced with asymmetric authentication, typically Private Key JWT:

1. The client signs a JWT with its private key.
2. The authorization server verifies the signature using the client’s registered public key.

This eliminates the risk of client secrets being leaked during transmission.

The Role of FAPI Certification

The OpenID Foundation’s certification program provides automated tests to verify compliance with the FAPI profile. Certified components:

• Reduce the burden of security auditing.
• Ensure interoperability—a FAPI‑compliant client can work seamlessly with a FAPI‑compliant authorization server from any vendor.

Choosing certified implementations gives assurance that the system adheres to industry‑leading security standards.

Further Reading

• OpenID FAPI 2.0 Security Profile – Final Specification
• OAuth 2.0 Pushed Authorization Requests (RFC 9126)
• OAuth 2.0 Demonstration of Proof‑of‑Possession (RFC 9449)
• FAPI 2.0 Attacker Model

For a developer‑focused overview, see the free ebook A Developer’s Guide to FAPI, which details the security measures needed to make your application FAPI‑ready.