2

The Plaid Link API documentation states that the result of a successful Plaid link returns a public_token with the following properties:

Once a user has successfully onboarded via Plaid Link, the module will provide a public_token. This is in contrast to typical Plaid API requests, which return an access_token.

Is safe to expose in an app or browser

Cannot be used to retrieve account and routing numbers (for auth) or transactions (for connect) directly

Can be exchanged for a Plaid access_token via the /exchange_token endpoint.

Presumably, this is in contrast to the access_token, which implies that the access_token is a secret. However, as far as I can tell, every Plaid endpoint that takes an access_token also requires the client's ID and secret value.

Assuming the secret is in fact kept secret, is it theoretically safe to expose the access tokens? If not, what am I missing? If so, what's the point of the public tokens?

Troy
  • 1,599
  • 14
  • 28

1 Answers1

6

Your assumption is correct, the access_token should be kept secret.

The only reason to expose the access_token is to either show that information to the user (no reason to do this), or to give the client the information so it can send it back later (such as with an OAuth token for authentication).

But if you expose the access_token, that means your API is expecting the user to send their own access token when requesting information. Your API is trusting that user input. If the user gains access to another user's access_token, they could send that to your API, and get access to a different user's account.

To defend against that sort of unauthorized access, you need to track which user has access to which tokens, and you must validate that on ever request to ensure no unauthorized access.

And at that point, you need to ask yourself, why expose the access_token in the first place? The Client ID is public information, so you're relying on the fact that your secret won't be exposed. And if your secret is ever exposed and your access_tokens are already being treated as public, then all bank info for all users will be exposed.

To ensure your user data is kept as secure as possible, the access_token should never be given to the end user.

Ethan Mick
  • 9,517
  • 14
  • 58
  • 74
  • 1
    I don't work at Square anymore so II don't have access to my emails on this subject, but I recall getting the exact opposite response from a Plaid engineer, so I'd be curious to understand where the confusion lies. I think we were both operating under the assumption that access tokens are tied to a specific client (and thus secret). Your comment suggests that's not the case. Does that mean I can use an access token created by my client with someone else's client secret? – Troy Jun 14 '17 at 20:58
  • 1
    Plaid provides an API endpoint specifically for revoking compromised access tokens. ["By default, the access_token associated with an Item does not expire and should be stored in a persistent, secure manner"](https://plaid.com/docs/api/tokens/#itemaccess_tokeninvalidate) – Nexus Sep 22 '22 at 18:37
  • This just adds another login. State of the art might not be *having an authentication identity provider to call a database through backend after linking*; rather, it could be ***using the `access_token` upon mount** in client state, preferably **without showing them***, still, and if you do, have the revoke `/item/access_token/invalidate`. – Nick Carducci for Carface Bank Dec 10 '22 at 05:30