java - 如何保护从 OAuth 保护的资源中提取数据的 Android 应用程序

Question

我的公司正在构建一个 RESTful API，它将返回适度敏感的信息(即财务信息，但不包括帐号)。我可以控制 RESTful API 代码/服务器，并且还在构建 Android 应用程序。我已将 API 设置为使用 OAuth 2 和授权代码授予流程(带有客户端 ID 和密码)，并且我自动批准用户而无需他们批准客户端，因为我们同时拥有客户端和提供商。我们将 CAS 用于 SSO，当用户登录以检索 token 时，我将其用于授权服务器作为 OAuth 2 流程的一部分。

我正在考虑各种方法来保护 Android 应用程序上的数据。我得出的结论是，在设备上存储客户端 ID 和密码绝对不会发生，但我认为存储身份验证 token 可能会起作用，因为它只对个人用户构成风险(而且实际上只有当他们碰巧有有根电话)。

这是我想到的两个选项。他们都要求我有一种受 CAS 保护的代理服务器，与 API 服务器共舞，并返回身份验证 token 。这消除了在应用程序代码中存储客户端 ID 和密码的需要。

这是我想出的:

1) 要求用户每次启动应用程序时都需要输入密码才能访问数据。这绝对是最万无一失的方法。如果这样做了，为了方便起见，我可能想保存用户 ID，但在那种情况下无法使用 CAS 登录(因为它是基于 Web 的)。我也许可以在后端使用 headless 浏览器让用户登录 CAS 并根据他们在 Android 表单中输入的内容检索 token ，但这看起来很老套。保存用户 ID 类似于 Chase 应用程序所做的事情(如果您碰巧使用了这个应用程序) - 它会在 session 之间保存用户 ID，但不会保存您的密码。

2) 将授权 token 存储在 Android 设备上。这有点不安全，但几乎是万无一失的。当用户第一次启动应用程序时，打开网页到返回 token 的代理服务器的 CAS 登录(类似于 https://developers.google.com/accounts/docs/MobileApps )。在用户登录并将 token 返回给应用程序后，对其进行加密并将其存储为应用程序专用。此外，使用 ProGuard 混淆代码，使加密算法更难以逆向工程。我也可以在 token 刷新中工作，但我认为这更像是一种错误的安全感。

3) 不要使用 CAS，而是想出另一种方法来获取服务的授权 token 。

关于其他人如何实现类似场景(如果已经完成)的任何建议？

谢谢。

Answer 1

之所以开发像 OAuth 这样的标准，是因为并不是每个人都必须一次又一次地重新考虑相同的攻击 vector 。因此，大多数情况下，坚持使用已有的东西而不是烘焙自己的东西是您的最佳选择。

无法 secret 存储数据的客户端的第一个问题是用户的数据可能会被某些攻击者访问。由于技术上不可能阻止这种情况(代码混淆不会帮助您对抗专家攻击者)，OAuth 2 中的访问 token typically expires在很短的时间之后，并且不给攻击者完全访问权限(受范围限制)。当然，您不应该在这样的设备上存储任何刷新 token 。

第二个问题是client impersonation .攻击者可以窃取您的客户端密码并在他自己的(可能是恶意的)应用程序中访问您的 API。用户仍然必须自己登录。那里的 OAuth 草案要求服务器尽其所能防止这种情况发生，但这真的很难。

The authorization server MUST authenticate the client whenever possible. If the authorization server cannot authenticate the client due to the client's nature, the authorization server MUST require the registration of any redirection URI used for receiving authorization responses, and SHOULD utilize other means to protect resource owners from such potentially malicious clients. For example, the authorization server can engage the resource owner to assist in identifying the client and its origin.

我认为 Google 率先尝试了另一种方法来验证此类设备上的客户端，即检查应用程序的签名，但他们还没有准备好迎接黄金时段。如果您想更深入地了解该方法，请参阅 my answer here .

目前，您最好的选择是继续使用 OAuth 方式，即拥有访问 token 、客户端 ID 和客户端密码(在设备上使用授权代码授予流程时)，并配置您的服务器以执行其他检查。如果您觉得混淆这些更安全，那就去做吧，但始终将其视为这些值是公开可用的。