Search code examples
oauth-2.0amazon-cognito

Sanity check: OAuth 2 client_credential server-to-server vs. username/pwd

We're having an internal debate over the following issue. We have a server that implements an API that our customers' servers consume/call. Our server is using AWS Cognito. We've implemented client_credential authentication. So when we on-board a new client, we register a new app for them (in Cognito/UserPool) and give them the corresponding app id and app secret (created by Cognito). We've also set up scopes, etc. So now, when the customer's server makes an API call, it 1) gets auth tokens from Cognito using the app id and password, and 2) passes in the token with the API call.

One engineer thinks that we shouldn't trust our customers to protect the app secret. Instead, he suggests we keep hold of the app id and secret. Then, we give our new customer a username/pwd. When the customer's server makes an API call, instead of the "usual" approach described above (Oauth 2), the customer's server will 1) send the username/pwd along with the API call, 2) our server validates those, 3) pulls out the customer's app id and secret from an internal db, and 4) passes these to Cognito to get the auth tokens.

Phew! That seems a problem in several areas:

  1. If we don't trust them with the app secret, why should we trust them with the username/pwd we create for them?
  2. The suggested alternative (username/pwd) introduces yet another layer. Now we need to manage the username and pwd, storing it, etc.
  3. The existing implementation (OAuth 2) is mature, tested, etc.

I'm fairly new to the OpenAuth way of doing things, so I wanted to ask for your thoughts before telling the engineer, "Thanks for your input, but we're not going to introduce the username/pwd; instead we're going to trust our customers to protect the app secret."

Thoughts? TIA.

Solution

  • The only thing that changes when you add another layer of username/passwords is that, when a password becomes compromised, then you only need to change the password in your system, not in Cognito.

    The proposed approach could be useful if you wanted to give your clients ability to change or reset their passwords on their own, and you don't want to give them access to Cognito (either via a GUI or through some proxy created by you). Otherwise there is completely no additional value of having that second layer of username/password.