The OpenID Foundation's final FAPI 2.0 Security Profile describes a high-security OAuth-based process in which a confidential client obtains sender-constrained tokens from an authorization server and uses them at a resource server. The profile was published in February 2025. For a bank or fintech commissioning a penetration test, the practical challenge is to turn that three-party specification into a contract that names which component is owned, which behavior is expected and what evidence proves it.
Quick answer. A FAPI 2.0 open-banking API penetration test should cover the authorization server, confidential client and resource server as separate boundaries. Test core profile behavior such as authenticated pushed authorization requests, PKCE S256, issuer validation and sender-constrained tokens, then prove that the business API returns only the data and actions authorized by a specific consent and user context. Put component ownership, test identities, synthetic data, applicable profile extensions and acceptance evidence in the SOW (OpenID Foundation, FAPI 2.0 Security Profile).
FAPI is a profile a program chooses or an ecosystem specifies for a high-value API. This article does not assume every US or Canadian open-banking interface is legally required to implement it. The buyer should point to the profile version, ecosystem rules and contractual obligations that apply to its implementation. Only then can the tester distinguish a protocol failure from an unimplemented option or a business authorization issue.
Define the system boundary before the protocol test
A FAPI deployment has at least three technical roles. The authorization server handles the authorization flow and issues tokens. The confidential client initiates the flow and calls APIs. The resource server receives a token and serves protected data or actions. These roles may be run by one organization or split among a bank, aggregator, identity provider and API platform. The final profile specifies requirements for each role separately (OpenID Foundation, FAPI 2.0 Security Profile, section 5.3).
That split drives procurement. A tester hired by the API provider may be able to assess the authorization server and resource server but not the third-party client's code. A fintech client may be able to test its own redirect handling and key management but only observe a bank's authorization server at the public interface. The SOW should mark each role as directly tested, externally observed, covered by another party's evidence or excluded. “End-to-end FAPI test” without those designations is not a usable scope.
The API product owner should also list the actual flows. Some programs use a browser authorization-code journey with customer consent. Others have service-to-service access. The FAPI 2.0 profile's authorization-endpoint requirements apply when that flow is used, and the relevant client obligations differ from a generic machine-to-machine request. A test plan should not blindly apply a browser-flow case to a client-credentials endpoint or assume a public mobile client falls inside this confidential-client profile. The specification explicitly limits its scope to confidential clients (OpenID Foundation, FAPI 2.0 Security Profile, sections 5.1 and 5.3).
Figure 1: The authorization server, confidential client and resource server each carry distinct FAPI 2.0 test responsibilities. Source: OpenID Foundation, FAPI 2.0 Security Profile.
This is a narrower question than a generic payment API penetration-testing scope, which covers transaction, business-logic and integration risks regardless of security profile. It is also different from the general API authorization test matrix, which addresses object, function and tenant access for APIs without assigning FAPI-specific protocol obligations. A strong FAPI engagement includes both: the selected profile controls and the business resource decision.
Map protocol requirements to components and evidence
The buyer should ask the tester to build a control-to-owner matrix before executing negative cases. Each protocol finding must identify the responsible role and the evidence it was based on. The table below is a purchasing aid based on the final profile. It does not replace the normative text.
Control boundary | Profile expectation | Primary owner to identify | Evidence to request |
|---|---|---|---|
Authorization request | Client-authenticated pushed authorization request, with direct non-PAR requests rejected for authorization-endpoint flows | Authorization server and client | Configuration, controlled flow trace and rejected unauthorized variation |
Authorization code | Authorization-code flow with PKCE S256 and client issuer check | Authorization server and client | Bound flow correlation and observed rejection of invalid code context |
Client authentication | mTLS or private_key_jwt, as selected by the deployment | Authorization server and confidential client | Registered method, certificate or key handling evidence, safe authentication result |
Access token | Sender-constrained token using mTLS or DPoP | Authorization server, client and resource server | Token method, holder proof validation and rejected wrong-sender result |
Resource access | Valid, unexpired, unrevoked token with sufficient authorization | Resource server | Authorized and unauthorized synthetic account comparisons |
Business consent | User sees enough context to make a decision; client requests least necessary privileges | Product owner, authorization server and client | Consent screen, grant record, resource-level consequence and revocation behavior |
The final profile says authorization servers using an authorization endpoint must support client-authenticated PAR and reject authorization requests sent without PAR. It requires PKCE with S256. For authorization-code clients it requires PAR, a fresh challenge for each request, and issuer checking in the response (OpenID Foundation, FAPI 2.0 Security Profile, sections 5.3.2.2 and 5.3.3.2). A report should show whether these checks were actually observed for the scoped flow, not merely that the product advertises a PAR endpoint.
The profile requires authorization servers to issue sender-constrained access tokens using mTLS or DPoP, and requires resource servers to verify the sender constraint. It also requires resource servers to check token validity, integrity, expiry, revocation status and whether the represented authorization is sufficient for the requested resource. It forbids access tokens in query parameters at FAPI resource endpoints (OpenID Foundation, FAPI 2.0 Security Profile, sections 5.3.2.1 and 5.3.4). The test therefore cannot stop at token issuance. It must follow an authorized token to the API that makes the data decision.
The SOW should name the selected sender-constraining method. A deployment using DPoP has different implementation details from one using mTLS. The final profile allows either method for sender-constrained tokens, and client authentication may use mTLS or private_key_jwt. A buyer should not ask a vendor to certify all permutations when the deployment uses one. The vendor should, however, state which choices were observed and which were out of scope.
Authorization server: inspect the flow's integrity
The authorization server section should answer whether an authorized client can start the right flow and whether the server rejects flow variations it should reject. The tester can validate the registered client, metadata, redirect handling, PAR requirement, PKCE method and code lifecycle using dedicated synthetic accounts. These are defender checks. The report should describe the expected rule and the observed rejection or acceptance without publishing operational bypass instructions.
Client authentication deserves attention because different teams often own the registered keys, certificates and identity infrastructure. The final profile permits mTLS or private_key_jwt for client authentication and requires the server to accept only confidential clients. It also requires discovery metadata for authorization endpoints (OpenID Foundation, FAPI 2.0 Security Profile, section 5.3.2.1). For a buyer, the question is which registry, key-management process and change owner govern that client identity. A test result is much more useful when it points to a specific owner and registration state.
The profile includes limits on authorization-code lifetime and replay, plus response issuer identification. These details matter when a bank and an aggregator rely on a browser redirect. A test should establish that the code is tied to the intended flow and cannot be reused, and that the client recognizes the issuing authorization server. A superficial “OAuth passed” statement cannot tell the buyer which of these controls was checked (OpenID Foundation, FAPI 2.0 Security Profile, section 5.3.2.2).
Do not confuse interface conformance with business consent. The profile says the authorization server should give end users enough information to decide whether to consent, including the client identity and authorization scope; it says clients should ask for least necessary privilege. A buyer needs to decide what that means for its product and data categories. A consent screen that says “account information” may be too broad for a particular journey even if the token exchange is technically valid. The test should compare the text the user saw, the grant recorded, and the resources returned, using synthetic accounts and an approved product rule (OpenID Foundation, FAPI 2.0 Security Profile, sections 5.3.2.2 and 5.3.3.1).
Confidential client: test the implementation you own
The client can be a web service, an aggregator platform or another controlled application. The final profile requires authorization-code clients to use PAR and PKCE S256, bind the PKCE challenge to the initiating client and user agent, check the issuer in the response, and send only client_id and request_uri to the authorization endpoint (OpenID Foundation, FAPI 2.0 Security Profile, section 5.3.3.2). A client assessment should test its actual redirect, session and key-handling code, because an authorization server's conformance evidence cannot prove the caller made the checks.
Give testers a representative client build, a safe account set and source access where possible. The acceptance evidence should state whether the client retrieved authorization-server metadata from an authoritative source, handled the response in the correct session and kept its signing or mTLS material within the approved boundary. A black-box test can observe some of these behaviors; a source-assisted review can explain how a verification rule is implemented. The SOW should say which of those methods is purchased.
Do not assume a partner client is yours to test. Where a bank exposes an API to many registered clients, the bank can assess its own authorization-server and resource-server behavior and require client conformance evidence through onboarding. Testing a partner's application code requires that partner's authorization and a separate named scope. The deliverable should distinguish “bank endpoint rejected an invalid client request” from “partner client securely stores its private key”; those conclusions require different access.
A useful synthetic journey has one customer, one consented account and one unconsented account. The client should request only the privileges needed for the approved use case, and the user-facing permission should correspond to what the resource server allows. This example is a test fixture, not a claim about any real institution's implementation.
Resource server: prove the data decision
The resource server is where a valid-looking token meets valuable data. FAPI 2.0 requires the resource server to validate the token and sender constraint and to verify that its authorization is sufficient for the requested resource (OpenID Foundation, FAPI 2.0 Security Profile, section 5.3.4). A report that stops after “token signature valid” misses the buyer's main risk: the API might still return the wrong account, customer, field or action.
Write an authorization matrix with resource owner, account, data category, operation, grant and client. Test a positive case and a nearby negative case for each high-value endpoint. For an account-information API, compare a synthetic consented account with a synthetic account outside the grant. For a payment-initiation API, compare the authorized payment's details with a different synthetic payment or payee. These are buyer-defined examples; the spec does not itself prescribe a particular banking data model.
The report should state which layer rejected the negative case. Was the token invalid, the sender proof absent, the scope insufficient, the consent missing, or the resource-owner association wrong? An HTTP error by itself does not prove the intended control. A trace that links token context, consent record and selected synthetic resource gives engineers a fixable finding. This is where protocol testing connects to the API authorization matrix.
Revocation and lifecycle also belong in the resource-server scope when the product uses them. The profile requires resource servers to verify token revocation status. The SOW should define a safe test grant, revocation action and expected observation at the API. The buyer should not accept a claim that revocation works because an administrative screen changed; the API response is the evidence. The test must avoid exposing real financial records or performing real transfers.
The resource server may be behind a gateway or a shared API layer. The SOW should identify which component enforces sender proof, which validates tokens, and which performs account-level authorization. A vulnerability may appear at a gateway, service, adapter or data-query layer. The report should name the responsible component if the evidence permits, while explicitly marking uncertainty if the tester only had external access.
Treat Message Signing as a separate scope choice
The OpenID Foundation publishes a separate FAPI 2.0 Message Signing profile that extends the Security Profile with signing and verification of selected messages and a non-repudiation goal. Its text explains distinct methods for signed authorization requests, responses and introspection responses. These are not automatically part of every Security Profile implementation. The SOW should state whether the ecosystem or product contract adopted Message Signing and exactly which methods apply.
If Message Signing is in scope, the tester should inspect the signed message's issuer, audience, key selection and verification behavior for the selected method, using safe fixtures and the applicable specification text. If it is out of scope, do not grade an ordinary Security Profile implementation as missing JARM or another message-signing control simply because an older FAPI variant used it. The FAPI 2.0 Security Profile's own comparison table explains that it uses PAR and a code-only authorization response in place of earlier design choices (OpenID Foundation, FAPI 2.0 Security Profile, section 5.5).
The separate signing profile's page carries a final publication header while retaining an older warning block from its review stage. The buyer should identify the exact version its ecosystem adopted and attach that reference to the SOW. The practical point for a penetration test is version control: every finding must be judged against the adopted text, not a memory of a draft.
Conformance testing and penetration testing have different evidence
The OpenID Foundation announced final FAPI 2.0 conformance tests and certification availability for authorization servers and OAuth clients in July 2025 (OpenID Foundation, Final Tests announcement). Conformance evidence is valuable when a buyer needs to know whether an implementation passes a defined suite for a profile and role. A penetration test asks a different question: whether the deployed integration, business consent and resource authorization expose an actionable path in the buyer's specific environment.
Request both forms of evidence when they matter. Ask for the tested profile and role, version, configuration and date of conformance evidence. Ask the penetration-testing vendor for deployment-specific scope, identities, negative cases, observations, findings and retest. A certified authorization-server component cannot prove that a bank's resource server filters records by the user's active consent, just as one successful pentest cannot replace a protocol conformance result for every branch of the spec.
This distinction helps procurement compare proposals. A vendor offering only an automated OAuth checklist may have useful configuration results, but it may not exercise the resource-owner matrix. A vendor offering only business-logic testing may miss PAR, PKCE or sender-binding defects. The strongest SOW tells both teams what to prove and where their evidence overlaps.
Figure 2: Each protocol boundary needs an owner and a distinct acceptance artifact. Source: OpenID Foundation, FAPI 2.0 Security Profile.
SOW and acceptance criteria for a scoped engagement
A FAPI 2.0 SOW should be precise enough that a product owner can answer whether a defect is a profile failure, a business-authorization failure or an out-of-scope partner behavior. It should also keep sensitive financial data out of the test. Start with synthetic customers, accounts, consent records and transactions in a representative non-production environment, then document which production-specific controls cannot be inferred from that environment.
SOW decision | What to write | Evidence required at acceptance |
|---|---|---|
Adopted standard | FAPI 2.0 Security Profile version and any separately adopted Message Signing methods | Requirement-to-test map with no draft/final ambiguity |
Component ownership | Authorization server, each confidential client, each resource server, gateway and partner boundary | Directly tested, externally observed, third-party evidence or excluded status for each |
Flows | Browser authorization-code, service access and other actual grants | Tests mapped only to applicable profile clauses |
Sender binding | mTLS or DPoP selection, certificate/key owner and resource-server verifier | Authorized holder succeeds; non-holder is rejected in a controlled case |
Consent and resources | Synthetic customer, account, operation, grant and revocation model | Positive and negative account or action comparisons |
Safety | Test environment, identities, request budget, synthetic data and transaction guardrails | No real transfer or broad data retrieval needed for proof |
Report | Protocol finding, business impact, responsible component and reproducible evidence | Each finding links requirement, expected behavior and observed behavior |
Retest | Same role, flow, token context and resource decision after remediation | Original negative case now produces the approved result |
The vendor's plan should also describe its access limits. Some endpoints may only be observable through a partner. Some data may exist only in production. Some controls may be delegated to a managed identity product. The report should state these limits and avoid a blanket “FAPI compliant” or “open-banking secure” verdict based on a narrow test. A buyer can then decide whether it needs a partner assessment, conformance run or production validation.
Stingrai is a CREST-accredited penetration testing provider headquartered in Toronto. Its human-led web and API testing can examine authenticated flows, authorization and business logic across named components that the customer has authority to test. Two named penetration testers work on a human-led engagement, with team-lead and engagement-partner review. The scope and commercial quote should reflect the actual number of clients, APIs, identity components and partner boundaries. Findings and retesting can support the customer's security and audit evidence.
Frequently Asked Questions
What should a FAPI 2.0 penetration test cover?
Cover the authorization server, confidential client and resource server as separate roles, then map the adopted FAPI 2.0 Security Profile clauses to each. Test authenticated PAR, PKCE S256 where an authorization-code flow applies, issuer checking, sender-constrained tokens and resource-server validation. Add synthetic consent and account-level negative cases for the actual business API.
Does FAPI 2.0 require every open-banking API in the United States or Canada?
The OpenID Foundation publishes FAPI 2.0 as a high-security API profile; the specification itself does not impose a universal US or Canadian legal mandate. A buyer should identify the ecosystem, contract or internal policy that adopts it before using it as a test criterion.
Is DPoP mandatory instead of mTLS?
No. The FAPI 2.0 Security Profile allows either mTLS or DPoP for sender-constrained access tokens. The SOW should name the method the deployment uses and test issuance, client use and resource-server verification of that method.
Is FAPI 2.0 Message Signing part of every Security Profile test?
No. Message Signing is a separate FAPI 2.0 profile that extends the core Security Profile. Include its applicable signed-request, signed-response or signed-introspection method only when the ecosystem or product has adopted that extension.
Can conformance certification replace a penetration test?
Conformance evidence can show how an authorization server or client performed against a defined profile test suite. A penetration test examines the deployed integration, consent decisions and resource authorization in the buyer's environment. Request both when those questions matter.
What evidence should a resource-server finding include?
It should identify the synthetic user and resource, grant and token context, expected authorization decision, observed response and component likely responsible. A token-validity result alone cannot prove that the API returned only the account or action authorized by the customer's consent.
Related reading
References
OpenID Foundation, FAPI 2.0 Security Profile, February 2025.
OpenID Foundation, FAPI 2.0 Message Signing, September 2025.
OpenID Foundation, Final Conformance Tests and Certifications announcement, July 2025.
Talk to Stingrai
Stingrai can turn your adopted FAPI profile and API resource rules into a human-led test plan with explicit component boundaries and reproducible findings. Get a Quote or book a free discovery call.
