0

I've been suggested an authorization flow between three parties that seems not secure to me, and I would like to know if I'm assuming correctly.

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 weird that Party A will encourage Customer X to bring that client_id and client_secret to another party.

I want to know if this is a normal flow, and if it isn't, suggest what is the most common way for Party B to access Party A data in behalf of Customer X.

Improve this question
6
  • I'm no expert on this subject, but It sounds to me pretty much the same as the way OAuth2 is used by Google to grant 3rd-party access to their APIs - developers.google.com/identity/protocols/oauth2 (Where Party B is effectively just a different application). As far as I can tell, the most important thing would be that Party B is configured as a separate application on the OAuth2 service with its own client_id and client_secret.
    – Ben Cottrell
    May 22, 2021 at 14:43
  • Auth0 docs also seem to suggest that this is a common solution: auth0.com/docs/applications/…
    – Ben Cottrell
    May 22, 2021 at 14:49
  • Interesting. Thank you! It looked weird to me that you would be giving a username and password to a third party... Because in this case client_id and client_secret are not unique for each of these third party applications.
    – Hommer Smith
    May 22, 2021 at 15:43
  • The third party should ideally not be prompting users for their username/password, instead it should be redirecting users to the OAuth2/OIDC provider login screen using their client_id. Upon successful login, the OAuth2 provider should redirect the user back to the 3rd party with an authorisation code which the 3rd party can exchange for an access_token. There's an excellent overview here; developer.okta.com/blog/2019/10/21/…
    – Ben Cottrell
    May 22, 2021 at 16:13
  • As for multiple applications/3rd parties sharing the same client_id and client_secret, this sounds like something to be ideally avoided, especially if the client_id grants privileges that the 3rd party otherwise wouldn't need.
    – Ben Cottrell
    May 22, 2021 at 16:20

0

Reset to default

Your Answer

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

Browse other questions tagged or ask your own question.