1

Let's say Party A has many customers (one of them let's call it Customer X) with data in Party A.

Party A is allowing Customer X to get data from their API. In order to do that:

  • Customer X downloads a client_id and client_secret
  • Customer X uses client_id and client_secret to hit the /auth endpoint
  • /auth endpoint returns a token
  • Customer X now uses the token in an authorization header (Authorization: Bearer YOUR_TOKEN_HERE) to hit API endpoints

Until this point this makes sense to me.

Now, let's say that we include Party B, which wants to access data in Party A in behalf of Customer X. What Party A is suggesting to do is:

  • Customer X downloads a client_id and client_secret
  • Customer X goes to Party B and stores client_id and client_secret there
  • Party B uses client_id and client_secret from Customer X to hit the /auth endpoint
  • /auth endpoint returns a token.
  • Party B now uses the token in an authorization header (Authorization: Bearer YOUR_TOKEN_HERE) to hit API endpoints in behalf of Customer X

To me it seems a little bit not secure that Customer X will give their Party A's client_id and client_secret to Party B. Am I missing something here?

1

To determine if a certain design is "secure", one must refer to the threat model of the application (which should explain the risk appetite of Party A and Customer X).

But yes, depending on the relationship between Customer X & Party B, one can see at least three potential security threats:

  • Spoofing: with the client_id/client_secret pair, Party B can identify as Customer X. This could be totally intended/accepted by Customer X.
  • Repudiation: If Party B makes changes on behalf of Customer X, Customer X can't claim it wasn't them (or at least, for Party A, in theory, there isn't a way to clearly know)
  • Information disclosure: Party B can garner whatever sensitive information Party A keeps on Customer X

Having said that, usually, Party A has no way to restrict who Customer X shares their token with. This would usually be done through the Terms and Conditions of the service. An example that comes to mind are online budgeting apps that require access to bank accounts to track expenses, and that used to require the user's banking credentials. This is obviously against most (all?) banks' T&C, yet many users of said budgeting apps would pass on their credentials anyway.


A bit related, but a common approach that Party A could use, when trying to mitigate the risks above, is to treat Customer X as untrustworthy. This would mean, for example:

  • Not use the client_id/client_secret as the only auth factor, and require an additional 2FA
  • Clear the token as soon as the behavior of Customer X seems to have changed (either because they are connecting with a different IP/user-agent/etc.)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.