为什么我不应该在OAuth 2.0的移动应用程序中保留client_secret(授权代码授予流程) [英] Why I shouldn't keep client_secret in mobile app in OAuth 2.0 (authorization code grant flow)

问题描述

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

We've got an app, which should use authentification through 3-rd party OAuth 2.0 server, which acts as an authorization server.

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

As i understand there are two possibilities.

正确"的是:

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

1. Mobile app stores client_id
2. Mobile app starts with GET /auth to receive authorization_code
3. Authorization server returns response with redirect to redirect_uri and attached authorization code. We assume, that redirect_uri is an endpoint on our own server.
4. Mobile app follows redirect
5. Our server receives request, takes authorization_code from query and exchanges it for access_token using POST /token method and client_secret (stored on server).
6. Server responses to mobile app with access_token
7. Mobile app takes access_token and uses it in future requests.

不好"的是:

1. 移动应用程序存储client_id 和client_secret
2. 移动应用程序以GET/auth开头以接收授权码
3. 授权服务器返回带有重定向的响应到redirect_uri 以及随附的授权码.我们假设那个应用 拦截它并获取authorization_code(我们可以简单地要求 重定向到本地主机).
4. 移动应用程序使用POST/token方法将其交换为access_token 和client_secret.
5. 移动应用会获取access_token并将其用于以后的所有请求中.

1. Mobile app stores client_id and client_secret
2. Mobile app starts with GET /auth to receive authorization_code
3. Authorization server returns response with redirect to redirect_uri and attached authorization code. We assume, that application intercept it and takes authorization_code (we can simply ask to redirect to localhost).
4. Mobile app exchanges it for access_token using POST /token method and client_secret.
5. Mobile app takes access_token and uses it in all future requests.

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

So i can't see real difference between this two alternatives. In both cases we end up with access token. In both cases we need real user to enter his login and password in rather secure webview.

即使某些坏蛋会分发伪造的应用程序……又是什么禁止他们使用我们的服务器回调来交换访问代码的授权代码呢?我们的服务器无法区分不良"和良好"应用程序-它仅接收请求GET \ callback?code = blablabla并使用access_token进行回复.

Even if some bad guys will distribute fake application... what do prohibit them from using our server's callback to exchange authorisation code for access_token? Our server can't distinguish "bad" and "good" application - it just receives request GET \callback?code=blablabla and replies with access_token.

那我们为什么要在服务器上保密呢?假冒应用程序的欺诈行为是什么情况?

So why should we keep secret on server? What is the case of fraud with faked applications?

推荐答案

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

With OAuth you have different flows that you can use according to your needs/setup. Depending of the different flows, the OAuth roles will also behave differently.

根据您的描述，我不完全确定客户端将扮演什么角色.但是选项是:

From your description I was not entirely sure what will take on the role of the Client. But the options are:

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

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

For case 1, you don't need to store client ID or client secret on your app, as it will be your own backend server to communicate with the Authorisation Server and the Resource Server. If that is the case, then you can follow the Authorisation Code flow.

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

For case 2, it will be the app itself that communicates with Authorisation and Resource Server. In this case, the Implicit Flow is the recommended one. It is not considered a safe flow, and mobile devices or webapps are not considered a safe place to store the client secret, as you would have to store them in your app's code, somehow. A (bit convoluted) scenario to explain why this isn't safe is the following: The client secret is issued by the Authorisation Server, or Service Registry, and any hack would require you to change it, which might mean changing the code. And in the case of a mobile app this would mean your users updating to a new version. What seems to be widely suggested as an extra step of security (instead of the client secret) is to use the 'state' or 'nonce' fields to ensure that authorisation requests came from the same app to which the token was issued to. From the RFC section 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.

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

The value to be passed in the state field is up to whoever makes the request. You can generate a random (or pseudo-random) number. The reply that the Authorisation Server sends back will have the state field filled exactly the way it was sent by the Client. You can then match the state field you received with the one you sent to see if they match.

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

Another step you can take is to have the Client send the redirect URI with the token request. This is useful so that the Authorisation Server can validate if the redirect URI in the request matches the one it has associated with the client ID. If you're using a 3rd party Authorisation Server you should check if it has this behaviour.

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

As a final security recommendation, always use with HTTPS when communicating with the Authorisation Server or the Resource Server.

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

This post explains well the different flows of OAuth: https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2

这篇关于为什么我不应该在OAuth 2.0的移动应用程序中保留client_secret(授权代码授予流程)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！