Technical
Updated January 18, 2026
14 min read
OAuth 2.0 is the industry-standard protocol for authorization in open banking and financial data APIs. Combined with OpenID Connect for authentication, OAuth enables secure, consent-based data sharing without exposing user credentials. This guide covers OAuth implementation for CDR, Section 1033, and other financial API frameworks.
OAuth 2.0 is an authorization framework that enables third-party applications to obtain limited access to user accounts without exposing user credentials. Instead of sharing passwords, users authenticate with the service provider (bank) directly and authorize specific access for the third-party application. OAuth separates authentication (proving identity) from authorization (granting access), creating a more secure and flexible system than traditional credential sharing.
The Authorization Code Flow with Proof Key for Code Exchange (PKCE) is the recommended OAuth flow for mobile and web applications accessing financial data. PKCE adds an extra layer of security preventing authorization code interception attacks. The flow involves: 1) Application generates code verifier and challenge. 2) User redirected to authorization server with challenge. 3) User authenticates and consents. 4) Authorization server returns authorization code. 5) Application exchanges code for access token using verifier. 6) Access token used to call APIs. PKCE is mandatory for CDR and recommended for Section 1033 implementations.
Access tokens are short-lived credentials (typically 10-60 minutes) used to call APIs on behalf of the user. Refresh tokens are long-lived credentials used to obtain new access tokens without user interaction. In financial APIs, refresh tokens are typically valid for the consent duration (e.g., 90 days in Section 1033, up to 12 months in CDR). Applications must securely store refresh tokens and implement automatic token refresh when access tokens expire.
Never store tokens in localStorage or sessionStorage where they're vulnerable to XSS attacks. For web applications, store tokens in httpOnly, secure cookies. For mobile applications, use platform-specific secure storage (iOS Keychain, Android Keystore). Implement token encryption at rest and secure memory handling during processing.
Implement proper token revocation when users log out or revoke consent. Call the authorization server's revocation endpoint to invalidate refresh tokens. Clear all stored tokens from application state. Financial regulations often require immediate revocation when users withdraw consent.
OAuth scopes define the specific data and permissions being requested. Financial APIs define standardized scopes for different data types (e.g., "bank:accounts:read", "bank:transactions:read", "bank:payees:read"). Applications should request only the minimum scopes necessary for their functionality. Consent screens must clearly explain what data is being accessed and for what purpose. Users should be able to grant granular consent for specific data types.
OpenID Connect (OIDC) is an authentication layer built on OAuth 2.0. While OAuth handles authorization, OIDC handles user authentication and identity verification. OIDC provides an ID token (JWT) containing user identity claims alongside the OAuth access token. Financial APIs often use OIDC for Know Your Customer (KYC) and identity verification requirements. The ID token can include verified identity attributes like name, email, and phone number.
Financial-Grade API (FAPI) is an OpenID Foundation security profile providing enhanced protection for high-risk transactions. CDR requires FAPI 2.0 compliance, and other financial APIs are adopting FAPI standards. Key FAPI requirements include: Mutual TLS (mTLS) for client authentication, JWT-secured authorization requests, sender-constrained tokens preventing token theft, and hybrid flow with code and ID token in front channel. FAPI provides bank-grade security protecting against sophisticated attacks.
Follow these OAuth implementation best practices for financial APIs: Always use HTTPS for all OAuth communications. Validate redirect URIs strictly (exact match, no wildcards). Implement PKCE for all flows, even confidential clients. Use short-lived access tokens (15-60 minutes maximum). Rotate refresh tokens on each use. Implement rate limiting on token endpoints. Log all authorization events for audit trails. Use nonces to prevent replay attacks. Validate JWT signatures and claims. Implement proper error handling without leaking security information. Test OAuth flows comprehensively including error cases and revocation scenarios.
OAuth 2.0 is a complete redesign of OAuth 1.0, not backward compatible. OAuth 2.0 is simpler to implement, supports mobile applications better, and separates authentication from authorization through OpenID Connect. OAuth 1.0 is deprecated and should not be used for new implementations.
Yes, OAuth 2.0 (typically with OIDC and FAPI) is the required authentication/authorization standard for most financial API frameworks including CDR, Section 1033, and PSD2. It provides the security and consent management capabilities required by regulations.
Access tokens for financial APIs should be short-lived (10-60 minutes) to limit exposure if tokens are compromised. Use refresh tokens for long-lived sessions. The exact duration should balance security against API call efficiency.
Proof Key for Code Exchange (PKCE) prevents authorization code interception attacks in public clients. It's mandatory for mobile and single-page applications and recommended for all OAuth flows in financial APIs. PKCE is required by CDR and strongly recommended for Section 1033.
No, API keys alone are insufficient for user-delegated access in financial APIs. OAuth provides user consent, scope limitations, and token revocation capabilities that API keys cannot provide. Regulations like CDR and Section 1033 mandate OAuth-based authorization.
Test OAuth flows using authorization server sandbox environments, automated OAuth testing tools, and manual testing of all flows including error cases. Verify PKCE implementation, token validation, scope handling, consent revocation, and security headers. Perform security testing including token theft scenarios and replay attacks.
When a refresh token expires, the user must re-authenticate and re-authorize the application. Applications should handle this gracefully by redirecting users to the authorization flow and explaining that re-authorization is needed. Avoid automatic silent re-authorization for financial APIs due to consent requirements.
Explore our APIs and start building secure, compliant financial data integrations today.
Products
© Fiskil 2026. All rights reserved.