OAuth2 客户端 ID 和客户端密钥的安全性 [英] Security of OAuth2 Client Id and Client Secret

问题描述

我正在使用 Spring 开发一个通过 OAuth2 保护的 REST API，它将在 Android 应用程序(客户端)中使用.为了访问我的 API 的任何端点，需要一个 OAuth2 访问令牌并通过授权标头以类似于以下的方式移交给端点:

I am developing a REST API secured via OAuth2 with Spring that will be used from an Android application (the client). In order to access any endpoint of my API, a OAuth2 access token is required and handed over to the endpoint via Authorization Header in a way similar to this:

授权"-此处不记名访问令牌"

"Authorization" - "Bearer accesstokenhere"

要获取访问令牌，必须提供用户名和密码，以及客户端 ID 和客户端密码(它们代表 Android 应用).clientID 和 client secret 通过 Authorization Header 以类似这样的方式交给 token 端点，由 Spring 指定:

In order to acquire an access token, a username and password must be provided, as well as a client ID and client secret (they represent the Android app). The clientID and client secret are handed over to the token endpoint via Authorization Header in a way similar to this, which is specified by Spring:

授权"-基本clientId:clientSecret"

"Authorization" - "Basic clientId:clientSecret"

如果客户端 ID 和客户端密钥与服务器上定义的客户端匹配，并且用户存在且密码正确，则返回访问令牌和刷新令牌.

If the client ID and client secret match a client defined on the server and if the user exists and the password is correct, access token and refresh token are returned.

现在我的问题是如何在 Android 应用程序中安全地存储我的 clientId 和客户端密钥，确保对我的应用程序进行逆向工程的人无法访问它们?

Now my question is how I can securely store my clientId and client secret inside the Android application, making sure someone who reverse engineers my app does not get access to them?

此外，如果我要开发 iOS 应用程序(第二个客户端)，使用来自安全 POV 的不同客户端 ID 和客户端密码是否明智?

Also, if I were to develop an iOS application (a second client), would it be wise to use a different clientID and client secret from a security POV?

推荐答案

你不能 - 即使有办法，我仍然可以只检查线路上的有效载荷来确定值.请参阅 OAuth 2.0 for Native Apps 的第 8.5 节

You can't - even if there was a way, I could still just inspect the payload on the wire to determine the values. See section 8.5 of the OAuth 2.0 for Native Apps

作为分发给多个用户的应用程序的一部分静态包含的机密不应被视为机密机密，因为一个用户可能会检查其副本并了解共享机密.出于这个原因，以及 [RFC6819] 的第 5.3.1 节中所述的那些，不建议授权服务器要求使用共享密钥对公共本机应用程序客户端进行客户端身份验证，因为除了客户端识别之外，这几乎没有什么价值
已由client_id"请求参数提供.

Secrets that are statically included as part of an app distributed to multiple users should not be treated as confidential secrets, as one user may inspect their copy and learn the shared secret. For this reason, and those stated in Section 5.3.1 of [RFC6819], it is NOT RECOMMENDED for authorization servers to require client authentication of public native apps clients using a shared secret, as this serves little value beyond client identification which is
already provided by the "client_id" request parameter.

您的客户端 id/secret 参数仅提供发出请求的应用程序的身份，因此建议您为 iOS 应用程序创建不同的客户端，无论是从安全隔离的角度还是任何您想要收集的有关应用使用情况的分析数据(例如您通过客户端 ID 检索了多少次登录尝试?"等)

Your client id/secret parameters are just providing the identity of application making the request, as such it is recommended you'd want to create a different client for your iOS application, both from a security isolation point of view + for any analytics you want to gather about use of your application (e.g. 'how many sign in attempts are you retrieving by client id?' etc)

但是，威胁行为者可以对您的设置进行逆向工程，获取您的客户端 ID + 机密，然后开始使用用户名/密码组合攻击您的令牌端点，以尝试暴力破解您的应用程序.如果端点接受这些值并返回成功/失败代码，这对于试图破坏您系统的人来说是一个有用的攻击媒介.

However, a threat actor could reverse engineer your settings, take your client id + secret and then start hitting your token endpoint with a username/password combo to attempt to brute force your application. If an endpoint accepts these values and returns a success/failure code, this is a useful attack vector for someone trying to compromise your system.

目前推荐的方法是使用授权码流程"

The current recommended approach is to use the 'Authorization code flow'

当前在原​​生应用中授权用户的最佳做法是在外部用户代理(通常是浏览器)中执行 OAuth 授权请求，而不是在嵌入式用户代理(例如使用网络视图实现的用户代理)中执行.

The best current practice for authorizing users in native apps is to perform the OAuth authorization request in an external user-agent (typically the browser), rather than an embedded user-agent (such as one implemented with web-views).

以前，本机应用程序通常使用嵌入式用于 OAuth 的用户代理(通常使用 Web 视图实现)授权请求.这种方法有很多缺点，包括主机应用程序能够复制用户凭据和cookie，并且用户需要在每个应用程序.有关使用嵌入式的更深入分析，请参见第 8.12 节OAuth 的用户代理."

Previously it was common for native apps to use embedded user-agents (commonly implemented with web-views) for OAuth authorization requests. That approach has many drawbacks, including the host app being able to copy user credentials and cookies, and the user needing to authenticate from scratch in each app. See Section 8.12 for a deeper analysis of using embedded user-agents for OAuth."

查看 AppAuth for Android 了解更多信息，

Have a look at AppAuth for Android for more information,

这篇关于OAuth2 客户端 ID 和客户端密钥的安全性的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！