OAuth2和SSL足以保护API

Question

我试图找出保护API的最佳方法。我只允许SSL，我使用OAuth2进行身份验证，但这似乎不够。

主要关注的我是任何人都可以检查通过合法的客户端正在进行的API请求和窃取的OAuth CLIENT_ID。那时他们将能够构建他们想要模拟合法客户端的任何请求。

有什么办法可以防止这种情况发生？我见过有人使用参数的HMAC哈希值，只使用客户端和服务器已知的密钥，但我发现有两个问题。

1. 防止恶意用户反编译客户端并找出密钥非常困难（不可能？）。
2. 一些参数看起来很奇怪，可以做一个HMAC散列。例如，如果一个参数是文件的字节，你是否将整个事件包含在HMAC哈希中？

Answer 1

您可以部署您的合法客户端与API之间的相互认证的SSL。生成自签名的SSL客户端证书并将其存储在您的客户端中。将您的服务器配置为需要客户端身份验证，并且只接受已部署到客户端的证书。如果某人/某些尝试连接的东西没有该客户端证书，则将无法建立SSL会话并且不会建立连接。假设您控制合法客户端和服务器，则您不需要CA颁发的证书;由于您同时控制客户端和服务器端证书信任，因此只需使用自签名证书即可。现在

，你喊一声，这真的很难防止有人逆向工程客户和恢复证书（属于客户端证书的私钥，在这种情况下）。你说得对。您通常会将该密钥（和证书）存储在某种类型的密钥库中（如果您使用的是Android，则为KeyStore），并且密钥库将被加密。该加密基于密码，因此您需要（1）将密码存储在客户端的某处，或（2）在启动客户端应用程序时询问用户密码。你需要做什么取决于你的用例。如果（2）可以接受，那么你已经保护了你的凭证免受逆向工程，因为它将被加密并且密码将不会被存储在任何地方（但用户需要每次都键入）。如果你做了（1），那么有人能够逆向工程你的客户端，获取密码，获得密钥库，解密私钥和证书，并创建另一个能够连接到服务器的客户端。

没有什么可以做，以防止这种情况;你可以更难地对你的代码进行逆向工程（通过混淆等），但是你不能让它变得不可能。您需要确定您尝试采用这些方法缓解的风险是多少，以及需要做多少工作才能缓解风险。

Answer 2

你运行了SSL本身的OAuth认证的步骤？这样可以防止所有类型的窥探，尽管这意味着您必须小心保持OAuth服务器的证书保持最新。 （注意，OAuth服务器可以有拥有公开的SSL身份;即使模糊合理的努力也无法伪造，只有私钥才需要保密。）

这就是说，你需要更加小心您的防范措施。为什么人们必须使用你的客户端代码？为什么它必须是“秘密”？更轻松地将其传递给服务器，并将智能（包括验证登录身份）放在服务器上。如果有人想写自己的客户，让他们。如果有人想挥动他们的帐户在公众一个愚蠢的方式，向他们收取他们从愚昧发生的成本...