What is the difference between OAuth 2.0 and OpenID Connect in open banking architectures?

Why This Matters for Security Teams

In open banking, OAuth 2.0 and openid connect are often deployed together, but they solve different problems: delegated API access versus identity assertion. That distinction matters because a payment initiation flow can be technically authorised while still being misbound to the wrong user, tenant, or consent grant. Security teams need to verify both the access token path and the identity layer, not assume one proves the other.

This becomes even more important when third-party apps, aggregators, and embedded finance platforms sit between the bank and the customer. NHIMG research on the Ultimate Guide to NHIs notes that 92% of organisations expose NHIs to third parties, which is a strong warning sign for open banking ecosystems where OAuth apps and service identities are part of the trust boundary. For control expectations, NIST SP 800-53 Rev. 5 remains a useful baseline for access enforcement and auditability.

In practice, many security teams encounter token misuse and identity confusion only after a partner integration has already been approved, rather than through intentional design review.

How It Works in Practice

OAuth 2.0 is the authorisation framework that lets a financial app obtain scoped access to resources without collecting the customer’s banking password. The bank issues an access token after the user consents, and the API uses that token to decide what the client can do. OpenID Connect sits on top of that flow and adds an identity layer through an ID token and user claims, allowing the relying party to confirm who authenticated and how the session should be bound.

In open banking, the practical value is separation of concerns. OAuth answers, “May this app call this API with these scopes?” OpenID Connect answers, “Which user authenticated, and what identity attributes can the client rely on?” That distinction is essential when consent is tied to a customer account, a business role, or delegated authority. Without OIDC, systems may have delegated access but weak user assurance. Without OAuth discipline, identity alone does not constrain what the client can do.

Implementation teams should treat both layers as runtime controls, not paperwork:

• Use OAuth scopes to limit API actions to the minimum consented surface.
• Use OIDC claims to bind the authentication event to the correct user or organisation context.
• Prefer short-lived tokens and strong audience validation so tokens are not reusable across services.
• Review redirect URI handling, token exchange, and consent records as part of the trust model.

For identity governance context, NHIMG’s State of Non-Human Identity Security highlights that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which is exactly where open banking exposure can spread beyond the primary bank customer relationship. For implementation details, OpenID Connect Core 1.0 and the OAuth 2.0 framework remain the canonical references.

These controls tend to break down when multi-hop integrations reuse tokens across partner APIs because audience, consent, and user binding are no longer consistently enforced.

Common Variations and Edge Cases

Tighter identity binding often increases integration complexity, requiring organisations to balance user assurance against partner onboarding friction. In open banking, that tradeoff shows up in several edge cases.

First, some ecosystems use OAuth without OIDC for pure machine-to-machine interactions, especially where no end-user identity is involved. That can be valid, but it should not be confused with user authentication. Second, some banks rely on consent artefacts, mTLS, or FAPI-style profiles to strengthen trust. Those controls complement OAuth and OIDC, but they do not replace the conceptual difference between authorisation and identity.

Third, not every access token should be treated the same. A token obtained through a customer-authorised flow has different risk implications than a service credential used by an aggregation platform. Current guidance suggests explicitly separating customer identity, client identity, and workload identity in policy decisions, but there is no universal standard for this yet. The risk is highest when a team assumes an OIDC login alone proves transaction authority, or assumes an OAuth token alone proves the human behind the request.

NHIMG research on the Salesloft OAuth token breach and the OneLogin API Key Vulnerability shows how quickly trust collapses when token handling and identity assumptions drift apart.

Related resources from NHI Mgmt Group

• What is the difference between SAML, OAuth, and OpenID Connect in federation?
• What is the difference between privilege reduction and secret rotation?
• What is the difference between a rules-based secret scanner and a hybrid scanner?
• What is the difference between code scanning and runtime identity monitoring?