我正在努力找出确保API安全的最佳方法。我只允许SSL，并且使用OAuth2进行身份验证，但这似乎还不够。
我主要担心的是，任何人都可能检查合法客户端对API的请求，并窃取OAuth client_id。在这一点上，他们将能够构造任何他们想要模拟合法客户端的请求。
有什么办法可以防止这种情况发生吗？我见过人们使用只有客户端和服务器才知道的密钥来使用参数的HMAC哈希，但我看到了两个问题。
- 很难（不可能？）阻止恶意用户反编译您的客户端并找出密钥
- 对于HMAC散列来说，有些参数似乎很奇怪。例如，如果一个参数是一个文件的字节，你会在你的HMAC哈希中包括整个参数吗
您可以在合法客户端和API之间部署相互验证的SSL。生成自签名SSL客户端证书并将其存储在客户端中。将服务器配置为要求客户端身份验证，并且只接受已部署到客户端的证书。如果尝试连接的人/物没有该客户端证书，则无法建立SSL会话，也无法进行连接。假设您控制合法的客户端和服务器，那么您不需要CA颁发的证书；只需使用自签名证书，因为您可以控制客户端和服务器端的证书信任。
现在，你确实指出，很难阻止某人对你的客户端进行反向工程并恢复你的凭据（在这种情况下，是属于客户端证书的私钥）。你是对的。您通常会将该密钥（和证书）存储在某种类型的密钥库中（如果您使用的是Android，则为KeyStore），并且该密钥库将被加密。加密是基于密码的，因此您需要（1）将密码存储在客户端的某个位置，或者（2）在用户启动客户端应用程序时向用户询问密码。你需要做什么取决于你的用例。如果（2）是可以接受的，那么您已经保护您的凭据不受反向工程的影响，因为它将被加密，密码不会存储在任何地方（但用户每次都需要键入）。如果你做到了（1），那么某人将能够对你的客户端进行反向工程，获取密码，获取密钥库，解密私钥和证书，并创建另一个能够连接到服务器的客户端。
你无法阻止这种情况的发生；您可以（通过模糊处理等）使代码的反向工程更加困难，但不能使其成为不可能。你需要确定你试图用这些方法减轻的风险是什么，以及需要做多少工作来减轻它。
您是否通过SSL本身运行OAuth身份验证步骤？这可以防止各种窥探，尽管这确实意味着你必须小心保持OAuth服务器的证书是最新的。（注意，OAuth服务器可以具有公共SSL身份；即使付出了合理的努力，也不可能伪造。这只是需要保密的私钥。）
也就是说，你需要更加小心你要保护的东西。为什么人们必须使用你的客户端代码？为什么它必须是"秘密"？更容易泄露并将智能（包括登录身份验证）放在服务器上。如果有人想写自己的客户，就让他们写吧。如果有人想以一种愚蠢的方式在公众面前炫耀他们的账户，就向他们收取他们愚蠢行为所产生的成本…