OAuth2和SSL是否足以保护API

时间:2012-02-21 13:06:23

标签: security api ssl oauth oauth-2.0

我正在努力找出保护API的最佳方法。我只允许使用SSL,而我正在使用OAuth2进行身份验证,但这似乎不够。

我担心的主要问题是任何人都可以检查合法客户端对API发出的请求并窃取OAuth client_id。此时,他们将能够构建他们想要冒充合法客户的任何请求。

有什么方法可以阻止这种情况吗?我见过人们使用只有客户端和服务器知道的密钥才能使用参数的HMAC哈希值,但我发现有2个问题。

  1. 要防止恶意用户反编译您的客户端并弄清楚密钥是非常困难的(不可能?)。
  2. 制作HMAC哈希的一些参数看起来很奇怪。例如,如果参数是文件的字节,那么您是否将整个内容包含在HMAC哈希中?

2 个答案:

答案 0 :(得分:5)

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

现在,您确实发现很难阻止某人对您的客户端进行逆向工程并恢复您的凭据(在这种情况下属于客户端证书的私钥)。而你是对的。您通常会将该密钥(和证书)存储在某种类型的密钥库中(如果您使用的是Android,则为KeyStore)并且该密钥库将被加密。该加密基于密码,因此您需要(1)将密码存储在客户端的某个位置,或者(2)在用户启动客户端应用程序时询问用户密码。你需要做什么取决于你的用例。如果(2)是可接受的,那么您已经保护您的凭证免受逆向工程,因为它将被加密并且密码不会存储在任何地方(但用户需要每次都输入它)。如果您执行(1),那么有人将能够对您的客户端进行反向工程,获取密码,获取密钥库,解密私钥和证书,以及创建另一个能够连接到服务器的客户端。

你无能为力阻止这种情况;你可以更难以对代码进行逆向工程(通过混淆等),但你不能让它变得不可能。您需要确定使用这些方法尝试缓解的风险是什么,以及为缓解这些风险需要做多少工作。

答案 1 :(得分:1)

您是否通过SSL本身运行OAuth身份验证步骤?这可以防止各种窥探,但这确实意味着您必须小心保持OAuth服务器的证书是最新的。 (注意,OAuth服务器可以具有公共SSL身份;即使是模糊合理的努力量,仍然无法进行伪造。只有私钥需要保密。)

那就是说,你需要更加小心你所保护的东西。为什么人们必须使用您的客户端代码?为什么它必须是“秘密”?更容易放弃并将智能(包括登录身份验证)放在您的服务器上。如果有人想写自己的客户,请让他们。如果有人想以愚蠢的方式在公共场合宣传他们的账户,请向他们收取他们因愚蠢而招致的费用......