Authentication
Authentication options for the Core Exchange API
The Core Exchange API accepts an access token as a bearer token, for example curl -H 'Authorization: Bearer <ACCESS_TOKEN>'. Plaid obtains that token through an OAuth 2.0 authorization code flow, with OpenID Connect (OIDC) strongly recommended.
As the Data Provider, you implement the authorization server and Plaid acts as the OAuth client. Plaid discovers your endpoints from your /.well-known/openid-configuration document rather than using fixed URLs, so the values below are whatever you advertise there. See OAuth server setup for the full list of required properties.
| Discovery property | Purpose |
|---|---|
authorization_endpoint | Hosts your login page, where the consumer authenticates. |
token_endpoint | Exchanges an authorization code for an access token, ID token, and refresh token. |
userinfo_endpoint | Returns the user identifier. Required for OIDC; plain OAuth 2.0 implementations supply it via /customers/current instead. |
jwks_uri | Publishes the public keys Plaid uses to verify the id_token signature. |
Scopes
OIDC implementations must support openid and offline_access at a minimum; plain OAuth 2.0 implementations require offline_access. Plaid may additionally request FDX data scopes such as fdx:accountbasic:read or fdx:transactions:read to describe the categories of data it's accessing. Your OAuth server does not need to enforce access control per FDX scope.
Related guides
- Authentication overview — concepts, terminology, and the token model
- OAuth server setup — well-known configuration, credentials, and JWKS
- Implementing the OAuth flow — step-by-step parameters, responses, and error codes