FAPI 2.0 or Baseline OAuth: Which Security Profile Does the Bank API Request Actually Name?
Compare protocol claim, security property and conformance evidence before scoping a bank API request that says only OAuth or FAPI 2.0.
Signals to watch
- The relying party names the exact FAPI or OAuth profile and deployment role instead of saying only OAuth compliant
- The authorization server and client agree on PAR, PKCE and the sender-constrained token method
- A conformance result or endpoint-level test is tied to the release environment and owner
“OAuth compliant” and “FAPI 2.0 required” are not two interchangeable labels for the same bank API. OAuth 2.0 supplies an authorization framework; the FAPI 2.0 Security Profile selects and tightens OAuth-related mechanisms for high-value APIs, including authenticated pushed authorization requests, PKCE and sender-constrained access tokens. The project must name the exact profile and evidence, not just prove that a token endpoint responds.
This distinction matters to a financial-API identity sales engineer reviewing authorised open-banking, bank-developer and identity Telegram groups. A day-late response can miss a certification slot or integration release. A quote based on the word “OAuth” can also omit the authorization-server, client and resource-server changes the relying party expects.
Here is an illustrative composite exchange, not a bank request or test result:
“Sandbox login works with OAuth. Partner says production must be FAPI 2.0. Do we just change scopes?”
The exchange omits the API role, authorization server, client type, profile version, current flow, client authentication, token-binding method, conformance suite, failed test and production owner.
The comparison is framework versus constrained profile—not old versus new branding
RFC 6749 defines OAuth 2.0 roles and authorization grants. It intentionally leaves many choices to deployments. Saying “we use OAuth” can describe a legitimate authorization-code flow without identifying the security properties required by a high-value ecosystem.
The OpenID Foundation FAPI 2.0 Security Profile builds on OAuth and related standards. Its introduction says it covers clients obtaining sender-constrained tokens and using them with resource servers, and that it was designed for high-value application programming interfaces (APIs). A bank or open-banking ecosystem may add further rules; “FAPI 2.0” still needs an exact document, version and local profile.
| Evidence question | Baseline OAuth claim can establish | FAPI 2.0 Security Profile expects |
|---|---|---|
| Authorization request | A supported OAuth authorization flow | Authorization code flow with client-authenticated Pushed Authorization Requests (PAR) |
| Code interception defense | Deployment-dependent OAuth choice | Proof Key for Code Exchange (PKCE) with the S256 challenge method |
| Access-token theft | Bearer-token handling may be used | Sender-constrained tokens using mutual TLS or Demonstrating Proof of Possession (DPoP) |
| Client authentication | Depends on the client and deployment | Confidential clients and specified authentication choices |
| Evidence | A successful endpoint or integration test | Profile-specific behavior plus the ecosystem’s required conformance evidence |
The table does not say baseline OAuth is “insecure.” It says a generic OAuth claim cannot prove a narrower profile.
Profile evidence is also role-specific. A client test cannot establish the authorization server’s complete behavior, and an authorization-server trace cannot prove that the resource server rejects a stolen token lacking the required key or certificate. Record the client, authorization server and resource server separately, even when one vendor operates more than one role.
Follow one authorization request through four checkpoints
The shortest useful gap test follows a single request rather than comparing product feature lists.
Checkpoint 1: request submission
The FAPI 2.0 authorization server must support client-authenticated Pushed Authorization Requests under RFC 9126 and reject authorization requests sent without PAR. The client sends the authorization parameters over the authenticated back channel, then uses the returned request_uri at the authorization endpoint.
Checkpoint 2: authorization code
The profile requires PKCE with S256. It also sets a maximum authorization-code lifetime of 60 seconds. A sandbox redirect that returns a code does not show that either rule was enforced.
Checkpoint 3: client and access token
The authorization server issues only sender-constrained access tokens and uses either mutual Transport Layer Security under RFC 8705 or DPoP under RFC 9449. Client authentication and token binding are different questions: for example, the profile lists mutual TLS or private_key_jwt for client authentication, while token sender constraint uses mutual TLS or DPoP.
Checkpoint 4: resource request and evidence
The resource server must validate the token and its sender constraint through the chosen method. Then the team needs the evidence object the partner accepts: a conformance-suite result, endpoint trace, certification record or ecosystem-specific test. Do not call a local smoke test a certification.
The passkey fallback workflow addresses authentication recovery rather than API authorization. The SOC 2 onboarding evidence article shows how to keep an assurance request tied to the exact accepted record.
Scope the migration by the first checkpoint that fails
If PAR is absent, the project may require authorization-server metadata, PAR endpoint, client authentication and client request changes. If PKCE is present but access tokens are bearer-only, the main work may be key or certificate lifecycle and resource-server validation. If all runtime behavior passes but the partner rejects the evidence, the project may be test and conformance packaging rather than protocol redesign.
TOP Prospect can combine incomplete fragments from Telegram groups the user deliberately connects and is authorised to access, preserve original text, source and time, remove obvious duplicates and rank a candidate for human review. It cannot inspect endpoints, hold client keys, run a bank’s conformance suite, certify FAPI or choose the ecosystem profile. The pricing page describes the discovery boundary. The payment BD guide covers commercial merchant demand rather than protocol evidence.
Return to the sandbox exchange. “Change the scopes” is plausible only after the request, code, token and resource-server checkpoints already meet the named production profile. If one fails, scope that object and its owner. The useful comparison is not OAuth versus FAPI as rival products; it is the current endpoint evidence versus the security properties the relying party actually requires.
FAQ
Is FAPI 2.0 a replacement for OAuth 2.0?
No. It builds on OAuth 2.0 and related standards while narrowing choices and adding requirements for high-value APIs.
Does an OAuth access token prove FAPI 2.0 conformance?
No. It does not prove PAR, PKCE with S256, sender-constrained tokens, issuer checking or other profile behavior.
Must FAPI 2.0 use mutual TLS rather than DPoP?
No. The profile permits sender constraint with mutual TLS or DPoP, subject to its detailed requirements.
What makes the request ready for an implementation proposal?
Name the roles, profile version, sender-constraining method, evidence, environment, failed test and release owner.
Frequently asked questions
Is FAPI 2.0 a replacement for OAuth 2.0?
No. The FAPI 2.0 Security Profile builds on OAuth 2.0 and related standards, narrowing choices and adding requirements for high-value API scenarios.
Does an OAuth access token prove FAPI 2.0 conformance?
No. A successful token response does not prove client-authenticated pushed authorization requests, PKCE with S256, sender-constrained tokens, issuer checking or the rest of the selected profile.
Must FAPI 2.0 use mutual TLS rather than DPoP?
No. The Security Profile permits sender-constrained access tokens using mutual TLS under RFC 8705 or Demonstrating Proof of Possession under RFC 9449, subject to its specific server and client requirements.
What makes the request ready for an implementation proposal?
Name the API role, authorization server, client type, exact profile and version, sender-constraining method, required conformance evidence, environment, failing test and accountable release owner.
Sources and further reading
How a Signal worth attention is found
See how Top Prospect finds and organizes Signals worth checking, keeps the original Telegram context, removes duplicates, and helps you decide what to review first. You decide whether to follow up and what to do next.
