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

Question

我们有一个应用程序，它应该通过第三方OAuth 2.0服务器进行身份验证，该服务器充当授权服务器。

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

＆＃34;对＆＃34;一个是：

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

＆＃34;坏＆＃34;一个是：

1. 移动应用商店client_id 和client_secret
2. 移动应用以GET / auth开头接收authorization_code
3. 授权服务器返回响应，重定向到redirect_uri 和附加的授权码。我们假设，该申请 拦截它并获取authorization_code（我们可以简单地要求 重定向到localhost）。
4. 移动应用使用POST /令牌方法为access_token交换它 和client_secret。
5. 移动应用会使用access_token并在以后的所有请求中使用它。

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

即使有些坏人会分发假应用程序......有什么禁止他们使用我们服务器的回调来交换access_token的授权代码？我们的服务器无法区分＆＃34;坏＆＃34;和＃34;好＆＃34;应用程序 - 它只接收请求GET \ callback？code = blablabla并使用access_token回复。

那么我们为什么要在服务器上保密呢？伪造申请欺诈的情况如何？

Answer 1

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

根据您的描述，我不完全确定将对客户的角色采取什么措施。但选项是：

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

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

对于案例2，应用程序本身将与授权和资源服务器进行通信。在这种情况下，推荐使用Implicit Flow。它不被认为是一种安全的流程，移动设备或webapps不被视为存储客户机密的安全场所，因为您必须以某种方式将它们存储在应用程序的代码中。 一个（有点复杂的）场景解释了为什么这不安全如下：客户端密钥由授权服务器或服务注册表发出，任何黑客都需要您更改它，这可能意味着更改代码。对于移动应用程序，这意味着您的用户将更新为新版本。 似乎被广泛建议作为安全的额外步骤（而不是客户机密）是使用＆＃39;状态＆＃39;或者＆＃39; nonce＆＃39;字段，以确保授权请求来自发出令牌的同一个应用程序。 来自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。这很有用，因此Authorization Server可以验证请求中的重定向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中，客户端应在与资源服务器通信之前从授权服务器获取令牌。

它可以使用implicit grant或authorization code grant。在后一种情况下，它应该使用授权而不提供客户机密，因为移动客户端被认为是无法安全存储机密的公共客户端。