Oauth 2.0 健全性检查：OAuth 2客户端\u凭证服务器到服务器与用户名/pwd

我们正在就以下问题进行内部辩论。我们有一个服务器，它实现了客户服务器使用/调用的API。我们的服务器正在使用AWS Cognito。我们已经实现了客户端凭据身份验证。因此，当我们登上一个新客户端时，我们为他们注册一个新的应用程序（在Cognito/UserPool中），并给他们相应的应用程序id和应用程序机密（由Cognito创建）。我们还设置了作用域等。因此，现在，当客户的服务器进行API调用时，它1）使用应用程序id和密码从Cognito获取身份验证令牌，2）通过API调用传入令牌

一位工程师认为，我们不应该相信我们的客户会保护应用程序的秘密。相反，他建议我们保留应用程序id和机密。然后，我们给新客户一个用户名/pwd。当客户的服务器进行API调用时，客户的服务器将1）发送用户名/pwd以及API调用，2）我们的服务器验证这些，3）从内部数据库中提取客户的应用程序id和机密，4）将它们传递给Cognito以获取身份验证令牌，而不是上述“常规”方法（Oauth 2）

呸！这似乎是几个方面的问题：

如果我们不信任他们的应用程序机密，为什么我们要信任他们的用户名/密码我们为他们创建

建议的备选方案（用户名/pwd）引入了另一层。现在我们需要管理用户名和pwd，存储它，等等

现有的实现（OAuth2）已经成熟、经过测试等

我对OpenAuth的工作方式还比较陌生，所以在告诉工程师之前，我想问问你的想法，“谢谢你的输入，但我们不会引入用户名/pwd；相反，我们会信任我们的客户来保护应用程序的秘密。”

---

想法？TIA.

当您添加另一层用户名/密码时，唯一需要更改的是，当密码被泄露时，您只需要在系统中更改密码，而不需要在Cognito中更改密码

如果您想让您的客户能够自行更改或重置密码，并且您不想让他们访问Cognito（通过GUI或通过您创建的代理），那么建议的方法可能很有用。否则，拥有第二层用户名/密码完全没有额外的价值