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

"Authorization" -"Bearer accesstokenhere"

为了获取访问令牌，必须提供用户名和密码，以及客户端ID和客户端密钥(它们代表Android应用)。客户机ID和客户机密钥通过授权标头以类似于Spring的指定方式移交给令牌端点：

"Authorization" -"Basic clientId:clientSecret"

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

现在，我的问题是如何安全地将我的clientId和客户机密存储在Android应用程序中，以确保对我的应用程序进行反向工程的人员无法访问它们？

另外，如果我要开发iOS应用程序(第二个客户端)，使用与安全POV不同的clientID和客户端密码是否明智？

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

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 /秘密参数仅提供发出请求的应用程序的身份，因此建议您从安全隔离的角度+为所需的任何分析为iOS应用程序创建其他客户端收集有关您的应用程序使用情况的信息(例如"您通过客户端ID检索了多少次登录尝试？"等)

但是，威胁参与者可能会对您的设置进行反向工程，获取您的客户端ID +机密，然后开始使用用户名/密码组合击中令牌端点，以尝试强行强制应用程序。如果端点接受这些值并返回成功/失败代码，则对于试图破坏您的系统的人来说，这是一个有用的攻击手段。

当前推荐的方法是使用"授权代码流"

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).

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."

有关更多信息，请查看Android版AppAuth，