Standard OAuth can authenticate and authorise access, but it does not automatically prove that every third-party client, consent decision, and delegation step meets a financial-grade assurance requirement. In regulated settings, the weakness is usually trust governance, not the protocol itself.
Why This Matters for Security Teams
Open banking and PSD2 raise the assurance bar beyond ordinary OAuth deployments because the risk is not just token issuance, but whether the delegated relationship is trustworthy end to end. Standard OAuth can express consent and scope, yet it does not on its own prove strong customer authentication, regulated third-party status, or secure handling of delegated credentials. That gap is why financial APIs are often governed through additional policy, certificates, and onboarding controls, not protocol mechanics alone.
Regulators and implementers increasingly treat OAuth as a transport for permission, not a complete trust model. NIST SP 800-63 Digital Identity Guidelines help explain why identity assurance, authentication strength, and federation trust are separate concerns, while the Ultimate Guide to NHIs shows how weak lifecycle control and over-privileged access are common failure points in delegated access systems. In practice, teams often discover OAuth weaknesses only after a third-party app has already been over-scoped or a consent chain has been abused, rather than through intentional assurance design.
How It Works in Practice
In open banking, a compliant implementation usually layers OAuth with financial-grade controls. The authorization server may still issue access tokens, but the ecosystem also needs client authentication, certificate-based trust, redirect URI discipline, consent traceability, and strong binding between the app, the customer, and the regulated institution. Current guidance suggests treating OAuth as one component inside a broader trust framework, not as the trust framework itself.
A practical model typically includes:
- Strong client registration and verification for every third-party provider.
- Fine-grained consent tied to explicit account access and purpose.
- Short-lived tokens and refresh controls to reduce replay exposure.
- Audit logging that can reconstruct who approved what, when, and under which assurance level.
- Revocation paths that work immediately when a consent or third-party relationship changes.
This is where OAuth patterns often fall short operationally. A token can be valid while the underlying third-party assurance has changed, the app has been compromised, or the original customer consent no longer reflects current risk. The Salesloft OAuth token breach illustrates how delegated access can be abused once token trust is broken, and NIST SP 800-63 reinforces that authentication and federation events still need assurance validation at each step. These controls tend to break down in partner ecosystems with many APIs, inconsistent consent UX, and limited real-time visibility into downstream token use.
Common Variations and Edge Cases
Tighter third-party assurance often increases onboarding friction and operational overhead, requiring organisations to balance user experience against regulatory confidence. That tradeoff is unavoidable in PSD2-style environments because a “simple” OAuth flow may be too weak for high-risk transactions, while a heavier trust model can slow partner integration.
Best practice is evolving around how much extra control is enough. Some ecosystems rely on certificate-bound clients and signed requests, while others add dynamic risk checks, step-up authentication, or transaction-level consent. There is no universal standard for this yet, so implementation details depend on the regulator, the account service provider, and the service type. In addition, third-party visibility remains a major problem: the State of Non-Human Identity Security reports that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which makes governance harder even when the protocol is technically correct. OAuth works best where trust is already strong; it struggles when the ecosystem expects the protocol to prove trust that was never engineered into the delegation model.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-63 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | IAL/AAL/FAL | PSD2 needs assurance beyond protocol-level OAuth. |
| NIST CSF 2.0 | PR.AA | Open banking requires strong access assurance and ongoing validation. |
| OWASP Non-Human Identity Top 10 | NHI-05 | OAuth tokens and third-party apps are non-human identities that need governance. |
Map client and user onboarding to identity, auth, and federation assurance levels before allowing delegated access.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
