为什么我不应该在OAuth 2.0的移动应用中保留client_secret（授权代码授予流程）

Question

我们有一个应用程序，该应用程序应通过作为授权服务器的第三方OAuth 2.0服务器使用身份验证。

据我了解，有两种可能性。

“正确”的是：

1. 移动应用程序商店client_id
2. 移动应用以GET / auth开头以接收authorization_code
3. 授权服务器返回带有重定向到redirect_uri和附加授权代码的响应。 我们假设redirect_uri是我们自己服务器上的端点。
4. 移动应用遵循重定向
5. 我们的服务器接收请求，从查询中获取授权代码，然后使用POST / token方法和client_secret（存储在服务器上）将其交换为access_token。
6. 服务器对具有access_token的移动应用程序的响应
7. 移动应用获取access_token并在以后的请求中使用它。

“坏”的是：

1. 移动应用程序存储client_id 和client_secret
2. 移动应用以GET / auth开头以接收authorization_code
3. 授权服务器返回带有重定向到redirect_uri和附加授权代码的响应。 我们假设该应用程序拦截了它并采用了授权代码（我们可以简单地要求重定向到本地主机）。
4. 移动应用使用POST / token方法和client_secret将其交换为access_token。
5. 移动应用接受access_token并在以后的所有请求中使用它。

所以我看不到这两种选择之间的真正区别。 在这两种情况下，我们最终都会获得访问令牌。 在这两种情况下，我们都需要真实用户在相当安全的Web视图中输入其登录名和密码。

即使某些坏蛋会散布伪造的应用程序……又是什么禁止他们使用我们服务器的回调函数为access_token交换授权代码呢？ 我们的服务器无法区分“不良”和“良好”应用程序-它仅接收请求GET \\ callback？code = blablabla并使用access_token进行回复。

那么，为什么我们要对服务器保密呢？ 假冒应用程序欺诈的情况如何？

Answer 1

使用OAuth，您可以根据需要/设置使用不同的流程。 根据不同的流程，OAuth角色的行为也将有所不同。

从您的描述中，我不确定要在客户角色中扮演什么角色。 但是选项是：

1. 后端服务器是客户端
2. 移动应用是客户

对于情况1，您不需要在应用程序中存储客户端ID或客户端密钥，因为它将是您自己的后端服务器，可以与授权服务器和资源服务器进行通信。 如果是这种情况，那么您可以遵循授权码流程。

对于情况2，将是与授权和资源服务器通信的应用程序本身。 在这种情况下，建议使用“隐式流”。 它不被视为安全流程，移动设备或Web应用也不被视为存储客户端密钥的安全场所，因为您必须以某种方式将它们存储在应用的代码中。 下面是一个（有点费解的）方案来解释为什么这种方法不安全：客户端机密由授权服务器或服务注册表发布，任何黑客攻击都需要您对其进行更改，这可能意味着更改代码。 对于移动应用程序，这意味着您的用户将更新到新版本。 普遍认为，作为安全性的额外步骤（而不是客户端机密）的一种建议是，使用“状态”或“随机数”字段来确保授权请求来自向其颁发令牌的同一应用程序。 从RFC第4.1.1节（ http://tools.ietf.org/html/rfc6749#section-4.1.1 ）：

州

  RECOMMENDED. An opaque value used by the client to maintain state between the request and callback. The authorization server includes this value when redirecting the user-agent back to the client. The parameter SHOULD be used for preventing cross-site request forgery as described in Section 10.12. 

要在状态字段中传递的值取决于提出请求的人。 您可以生成一个随机（或伪随机）数字。 授权服务器发回的答复将完全填充客户端发送状态字段的状态字段。 然后，您可以将收到的状态字段与发送的字段匹配，以查看它们是否匹配。

您可以采取的另一步骤是让客户端发送带有令牌请求的重定向URI。 这很有用，以便授权服务器可以验证请求中的重定向URI是否与它与客户端ID关联的重定向URI匹配。 如果您使用的是第三方授权服务器，则应检查它是否具有此行为。

作为最终的安全建议， 与授权服务器或资源服务器进行通信时 ，请始终与HTTPS一起使用 。

这篇文章很好地解释了OAuth的不同流程： https : //www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2

Answer 2

We assume, that redirect_uri is an endpoint on our own server.

我相信您在这里混淆了客户端和资源服务器的角色。 当然，资源服务器（托管API的服务器）永远不要将令牌返回给移动应用程序（客户端），因为它首先需要该令牌对客户端进行身份验证。

在OAuth2中，客户端应在与资源服务器进行通信之前从授权服务器获取令牌。

它可以使用隐式授予或授权代码授予 。 在后一种情况下，它应在不提供客户机密的情况下使用授权，因为移动客户端被视为无法安全存储机密的公共客户端。