Authentication
Your guide to building a secure, standards-based OAuth integration with Plaid Core Exchange
What you'll learn
- Why OAuth is essential for Core Exchange
- Key concepts and terminology
- FDX version compatibility
- Where to get help and test your integration
Overview
Plaid Core Exchange supports any spec-compliant OAuth 2.0 implementation, and strongly recommends OpenID Connect (OIDC), an identity layer built on OAuth 2.0. OIDC enables critical features like the returning user experience and centralized consent management through the ID token's sub field (your unique/stable user identifier). Consumers authenticate directly with the Data Provider (you), which issues a secure token to Plaid without sharing credentials or compromising security.
Get OAuth right, and you unlock:
- Safe authentication - Consumers log in on your domain, not Plaid's.
- User control - Plaid accesses data only when users explicitly authorize it.
- Industry standards - Your integration supports all FDX versions (4.6+). Build to the latest spec for best results.
- Better UX - Returning users get a seamless experience (phone-verified reconnection across multiple apps).
In the following sections, learn why OAuth matters, how to build an OAuth 2.0 server (with OIDC strongly recommended), how Plaid's token model works, and how to troubleshoot common issues.
Try the interactive demo
See Core Exchange OAuth in action with Plaidypus, a working demo that illustrates the OAuth flow using Plaid's APIs.

What Plaidypus demonstrates:
- Complete the OAuth authorization flow with a simulated Data Provider
- Token exchange and refresh token mechanics
- Real API calls to Core Exchange endpoints
- User consent and account selection flows
The source code is on GitHub (Node.js). Explore the implementation to see how:
- OIDC discovery and JWKS validation work
- Authorization codes are exchanged for tokens
- ID tokens are validated and parsed
- Refresh tokens maintain long-term access
- Error handling catches common OAuth issues
Run the demo locally, change the code, and experiment. Interact directly to see how OAuth works in practice.
Key terms
You'll see these terms throughout this guide.
Parties (the who)
Consumer - The end user who owns the financial accounts.
Authorized Third Party (ATP) - The app requesting access to user data (Venmo, Chime, Copilot, etc.).
Plaid (Data Access Platform / DAP) - The OAuth client and data platform. Plaid acts as the OAuth client that requests access on behalf of apps.
Data Provider (DP) - You, the financial institution that authenticates consumers and issues OAuth tokens to Plaid.
Core Exchange - Plaid's data access platform that connects apps to financial institutions using OAuth 2.0 and OIDC for authentication and FDX specification for data APIs.
Protocols and standards (the framework)
OIDC (OpenID Connect) - An identity layer built on OAuth 2.0. It lets Plaid verify user identity and obtain a stable user identifier through the ID token's sub field, enabling advanced features like returning user experience.
FDX (Financial Data Exchange) - Industry standards for financial data sharing APIs. Core Exchange supports all FDX versions (4.6+). The latest version is recommended for new integrations.
DCR (Dynamic Client Registration) - A protocol for programmatically registering OAuth clients. Traditional DCR creates per-app tokens; single-token-compatible DCR (RFC 0356) preserves the universal token model. Learn more
Token models and types (the what)
Universal token - This user-scoped token is issued to Plaid and enables Plaid to efficiently provision access to multiple third-party apps with a single token. This benefits users by providing a seamless experience for returning users and by reducing the need for repeated authorization steps. It also reduces API requests for consumers connecting multiple apps, streamlining management for Data Providers.
Per-app token - This approach issues a separate token for each app a user connects to. While supported, it is not recommended, as it prevents returning user flows and creates extra work for users who must repeat authorization for each app. It also increases overhead for both users and Data Providers managing connections across multiple apps.
Access token - Short-lived (15 min) token for API access.
Refresh token - Long-lived token used to obtain new access tokens. Should be rotated with each use (preferred) or set to expire after 13+ months to meet reauthorization requirements.
ID token - JWT containing user identity information (OIDC).
Authorization code - Temporary code (<10 min) exchanged for tokens.
Key concepts (the how)
Consistency key - A stable, unique identifier for each consumer (usually the sub field in the ID token). Enables Plaid to recognize returning consumers and show all connections in one place.
JWKS (JSON Web Key Set) - Your public keys published at jwks_uri. Plaid uses these to verify the digital signatures on ID tokens.
Returning consumer experience - Consumers authenticate once with your bank, then quickly connect new apps using phone verification. No repeated OAuth flows. Learn more.
App2App - Mobile authentication flow that redirects consumers from an ATP's app directly to your mobile banking app for authentication, then returns them seamlessly. Provides a native mobile experience without web views.
Management tools (the where)
Permissions Manager - Plaid's system for managing authorization records and consent. Provides APIs and a dashboard for viewing connections, revoking access, and tracking reauthorization.
App Directory - Plaid's catalog of application metadata (app names, logos, scopes, etc.). Gives Data Providers visibility into which apps consumers are connecting to without implementing Dynamic Client Registration.
Why OAuth?
Modern API-based authentication
OAuth delivers secure, consumer-controlled access to financial data. Consumers authenticate directly with their bank, and the Data Provider issues a secure, scoped token to Plaid using industry-standard protocols.
What you get
- Security - Credentials stay with you. Tokens are scoped, revocable, and expire.
- Better UX - Enable returning user flows and App2App authentication.
- Compliance ready - Meet regulatory requirements and align with FDX standards.
- Industry standard - One integration works across multiple DAPs.
How OAuth works with Plaid Core Exchange
Plaid acts as a Data Access Platform (DAP), the registered OAuth client that handles the authorization flow and manages consent across multiple apps (Authorized Third Parties, or ATPs).

FDX version requirements
Core Exchange is built on Financial Data Exchange (FDX) standards and supports all FDX versions 4.6 and above. If you've already built an FDX integration, it will work with Core Exchange out of the box.
What Plaid supports:
- FDX 4.6+ - All versions are supported by Core Exchange
- Latest FDX version - Recommended for new integrations to access the newest features.
For new integrations, build to the latest FDX version to access new features and align with evolving industry standards.
Questions?
Reach out to your Solutions Engineer for more resources.