REST认证方案的安全性

前面的回答只在数据传输的上下文中提到了SSL,实际上没有涉及身份验证。

您实际上是在询问如何安全地验证RESTAPI客户端。除非您使用的是TLS客户端身份验证,否则SSL 单独地 不是REST API的可行身份验证机制。不带客户端authc的SSL仅对 客户 .

如果不使用TLS客户端身份验证,则需要使用基于摘要的身份验证方案(如Amazon Web Service的自定义方案)或OAuth 1.0a,甚至HTTP基本身份验证(但仅通过SSL)。

对于那些感兴趣的人,我已经扩展了一个关于 HTTP Authentication Schemes and how they work .

一旦您承诺使用SSL,原则上就不需要任何验证了。您可以再次使用web标准并使用HTTP Basic auth(随每个请求一起发送的用户名和秘密令牌),因为它比复杂的签名协议简单得多,并且在安全连接的上下文中仍然有效。你只需要确保密码不会出现在纯文本上;因此,如果通过纯文本连接收到密码,您甚至可以禁用密码并向开发人员发送邮件。您还应该确保在收到凭证时不会在任何地方记录凭证,就像您不会记录常规密码一样。

HTTP摘要是一种更安全的方法,因为它可以防止秘密令牌被传递;相反,它是服务器可以在另一端验证的哈希。不过,如果您采取了上述预防措施,那么对于不太敏感的应用程序来说,这可能会有点过头。毕竟,用户的密码在登录时已经以明文形式传输(除非您在浏览器中进行了一些奇特的JavaScript加密),同样,用户在每次请求时都会发送cookie。

请注意,使用API时,客户端最好传递令牌(随机生成的字符串),而不是开发人员登录网站时使用的密码。因此,开发人员应该能够登录到您的站点并生成可用于API验证的新令牌。

使用令牌的主要原因是,如果它被泄露,它可以被替换,而如果密码被泄露,所有者可以登录到开发人员的帐户并使用它做任何他们想做的事情。令牌的另一个优点是,您可以向相同的开发人员发布多个令牌。可能是因为他们有多个应用程序,或者是因为他们想要具有不同访问级别的令牌。

如果您需要将主体的散列作为URL中的参数之一,并且该URL通过私钥签名,则中间人攻击只能将主体替换为生成相同散列的内容。至少现在MD5散列值很容易处理,当SHA-1被破坏时,您就明白了。

为了保护身体不被篡改,您需要对身体进行签名,中间人攻击不太可能破坏身体签名,因为他们不知道生成签名的私钥。

事实上,原始的S3授权 做 允许对内容进行签名,尽管MD5签名较弱。您可以简单地强制他们在HMAC(要签名的字符串)中包含Content-MD5头的可选实践。

http://s3.amazonaws.com/doc/s3-developer-guide/RESTAuthentication.html

http://docs.aws.amazon.com/general/latest/gr/signature-version-4.html

请记住,您的建议会使客户端难以与服务器通信。他们需要了解您的创新解决方案并相应地加密数据,此模型不适合公共API(除非您是amazon\yahoo\google…)。

无论如何,如果您必须加密正文内容,我建议您查看现有的标准和解决方案,如:

XML加密(W3C标准)

XML Security