Skip to content

FAPI 2.0 In Released ProAuth: Enforce A Coherent Client Policy

Apply ProAuth's opt-in FAPI 2.0 profile with PAR, S256 PKCE, asymmetric client authentication and sender-constrained access tokens.

Security guide3 min readMarc Müller
Back to blog
On this page

A platform can support strong OAuth controls while individual clients still use a weaker combination. A security profile makes the required combination enforceable.

ProAuth released opt-in FAPI 2.0 Security Profile enforcement in 3.0.0. This article replaces preview-based evaluation guidance with a released-product explanation, while retaining the original preview as historical context.

The profile requires a complete integration

For interactive authorization, ProAuth’s FAPI mode requires authorization code flow, PAR, S256 PKCE, a confidential client, approved asymmetric client authentication, and sender-constrained access tokens.

flowchart TD
    Client[Confidential client] --> PAR[Push authorization request]
    PAR --> Login[Browser continues with stored request]
    Login --> Code[Issue authorization code]
    Code --> Redeem[Authenticate client and verify S256 verifier]
    Redeem --> Bind[Require DPoP or certificate binding]
    Bind --> API[API validates token and sender constraint]

The ProAuth FAPI guide lists the supported authentication methods: private_key_jwt, tls_client_auth and self_signed_tls_client_auth. Selecting the profile does not create keys, provision certificates or teach a client to generate proofs. Those remain integration tasks.

The FAPI 2.0 Security Profile is a published OpenID Foundation specification. ProAuth 3.0 ships profile enforcement; that product capability is distinct from certification. Do not treat a profile setting or a successful integration test as a certification claim.

Know which policy wins

FAPI mode is disabled by default. Effective policy follows this order:

  1. Tenant RequireFapi2SecurityProfile=true forces FAPI for every client.
  2. Otherwise the client’s SecurityProfile applies.
  3. A client value of null inherits DefaultClientSecurityProfile from the tenant.

None selects ordinary OIDC/OAuth behavior; Fapi2Security selects enforcement. Existing migrated clients receive explicit None for compatibility. Setting a tenant default therefore differs from forcing the tenant-wide requirement.

Start with a client whose owners can test the complete flow. Move to tenant-wide enforcement after reviewing every affected integration. This is particularly important where the tenant also serves public browser or native applications: the FAPI client contract is confidential, and existing applications may need a different architecture.

Check request and token behavior together

The FAPI browser request carries only client_id and the pushed request_uri. The stored PAR values remain authoritative through login and consent. The token request still needs the matching S256 verifier and registered client authentication.

DPoP and certificate binding are alternatives for access-token sender constraint. The receiving API must enforce the chosen proof. Enabling a profile at the authorization server cannot compensate for an API that accepts the token as an ordinary bearer credential.

Refresh handling also deserves a client test. The ProAuth guide documents stable sender-constrained refresh tokens for FAPI clients: successful refresh does not return a replacement refresh token. Do not apply a client assumption that every successful refresh must rotate it.

Treat enforcement as a release decision

Test compliant requests, direct requests that bypass PAR, missing PKCE, unsupported authentication methods and absent sender proofs. Check discovery under the effective tenant policy rather than copying metadata from another tenant.

Treat profile activation as a change to the application contract. Rehearse it with the client and API owners, including refresh and failed proofs, before enforcing it across a tenant. The practical benefit is a policy that rejects an incomplete integration before tokens are issued.

Image detail