我们有许多相互通信的应用程序。一个应用程序提供给客户，它必须与中央服务器进行通信以获取某些信息。我们使用OAuth2身份验证，并且已经使用用户名和密码来验证对中央服务器应用程序的访问。
我们将OAuth2客户ID和客户机密硬连线到客户应用程序中，以便服务器应用程序知道它是与其通信的应用程序实例。最近，我们被要求由客户配置客户端ID和客户端密钥，以便每个客户将拥有不同的OAuth客户端ID和客户端密钥。服务器将生成ID和密钥，客户将在安装应用程序时设置ID和密钥。
特别欢迎引用有名的出版物来解决此问题。
编辑：我们正在使用“资源所有者密码流”，其中用户名和密码以及clientId和secret存储（加密）在客户端应用中。安装该应用程序的客户将获得提供给他们的用户名/密码/ clientid / clientsecret，并且该组合始终用于从客户端应用程序连接到服务器应用程序，无论最终用户是否登录到客户端应用程序。 （如果id / secret / username / password组合遭到破坏，则可以更改，但更改的可能性很小。）这实际上使客户端应用程序的安装成为资源所有者。 （我没有设计这个）
答案 0 :(得分：2)
恐怕您的系统使用资源所有者密码流的方式不是正常的做法（Resource Owner Password Flow）。当客户端ID，客户端机密，用户名和密码在客户端应用中被硬连线时，您也可以使用Client Credentials Flow。
在硬线身份验证中添加可配置部件，给以安全方式向客户提供此新部件带来了挑战。另一方面，它可以让您撤消单个客户的身份验证，以防其受到损害。在使客户端ID和密码可配置中进行此操作不是正常做法。如果更改客户端应用程序，以便用户配置用户名和密码，您将更接近标准的“资源所有者密码流”。该流程为deprecated，但对于您的情况（when to use）来说可以。
通过执行此步骤，资源不再由客户端拥有，而是由一组客户拥有，并且可以从此组中排除客户。
另一种方法是更改为“客户端凭证流”，并使客户端ID和密码可配置。这样，客户客户将显示为不同的客户。效果几乎相同。
总结起来，您有两组凭据（客户端ID：秘密和用户名：password）。今天，两者都可以识别客户。您可以使用一种方法添加识别客户的功能。
答案 1 :(得分：0)
将秘密密码硬编码到应用程序中并不是最佳实践，对这些密码进行加密只会将问题转移到加密密钥上。有一个解决您的“动态客户端”用例的规范，称为OAuth 2.0动态客户端注册https://tools.ietf.org/html/rfc7591