我们为我们的Web应用程序设置了一个REST API，并且还为多个设备制作了一个应用程序。现在我正在寻找保护它的方法，而OAuth 2似乎是合乎逻辑的方式，特别是因为我们希望以后为我们的用户打开api。然而，对于这个全新的我已经阅读了OAuth 2，并且有一些我无法找到答案。
我们想要使用的解决方案与Googles OAuth 2非常相似。当您第一次打开应用程序时，会显示一个代码。在我们的Web应用程序中，您然后登录到您的帐户，在该帐户中输入代码并将设备添加为可信设备（如果需要，您可以稍后撤消访问权限）。应用程序轮询一个访问令牌，当它被添加到Web应用程序中的用户帐户时，它将收到该令牌。然后，用户应该可以通过应用访问他/她的内容。
到目前为止，似乎带有客户端凭据授权的OAuth 2可能是我们应该使用我们的受信任应用程序，但由于必须识别用户并且还将向系统发送数据我不确定是否我我走在正确的轨道上？
答案 0 :(得分：1)
使用特殊代码的初始流程听起来特定于您的应用程序。换句话说，OAuth 2.0中没有定义这样的流程。
仅当Client Credentials Grant为'机密'时才允许client type。因此，如果您的应用程序要安装到Android和/或iOS上，则不应使用客户端凭据授权。
我认为初始流程应该以特定于您的系统的特殊方式实现（=与OAuth 2.0无关），并且应该基于OAuth 2.0中定义的流程实现涉及用户交互的流程（{{3 }}或Authorization Code Grant）。
如果在第一次调用应用程序时向用户显示的特殊代码是唯一生成并分配给用户的，并且如果您打算将代码用作“client_id”，则可以使用“response_type = none”在Implicit Grant，OAuth 2.0 Multiple Response Type Encoding Practices中定义。在本节中，将以下面的场景作为示例进行描述。
一种情况是用户希望从市场购买应用程序，并希望授权应用程序安装并在一个步骤中授予应用程序对受保护资源的访问权限。但是，由于用户当前没有与（尚未激活的）应用程序交互，因此在授权步骤中同时返回访问凭证是不合适的。