REST身份验证方案的安全性
背景：
我正在设计REST Web服务的身份验证方案。 这并不是“真正”需要安全的（这更像是一个个人项目），但我想尽可能保证它的安全性，例如锻炼/学习体验。 我不想使用SSL，因为我不需要麻烦，而且大多数情况下都是为了设置它。
这些SO问题对我的启动特别有用：
我正在考虑使用Amazon S3身份验证的简化版本（我喜欢OAuth，但似乎太复杂了，无法满足我的需求）。 我将由服务器提供的随机生成的随机数添加到请求中，以防止重放攻击。
为了解决这个问题：
S3和OAuth都依靠签名请求URL和几个选定的标头。 他们都没有签署 POST或PUT请求的请求正文 。 这难道不容易受到中间人攻击吗？它会保留网址和标题，并用攻击者想要的任何数据替换请求主体？
看起来好像我可以通过在被签名的字符串中包含请求主体的散列来防范这种情况。 这是安全的吗？
以前的答案只是在数据传输的环境中提到了SSL，并没有真正涵盖认证。
您确实在询问有关安全认证REST API客户端的问题。 除非您使用TLS客户端身份验证，否则SSL本身不适用于REST API的可行身份验证机制。 没有客户端身份验证的SSL仅对服务器进行身份验证，这对于大多数REST API来说都是无关紧要的，因为您确实需要对客户端进行身份验证。
如果您不使用TLS客户端身份验证，则需要使用类似基于摘要的身份验证方案（如Amazon Web Service的自定义方案）或OAuth 1.0a甚至HTTP基本身份验证（但仅限于SSL）。
这些方案验证请求是由某人预期发送的。 TLS（SSL）（无客户端身份验证）确保通过线路发送的数据不受影响。 他们是分开的 - 但是互补的 - 关注。
对于那些感兴趣的人，我已经扩展了关于HTTP身份验证方案的SO问题以及它们如何工作。
REST意味着符合网络标准，网络上“安全”传输的标准是SSL。 其他任何东西都会有些时髦，并且需要额外的客户端部署工作，这将需要加密库。
一旦您提交到SSL，原则上真的不需要验证。 您可以再次使用Web标准并使用HTTP Basic auth（与每个请求一起发送的用户名和秘密令牌），因为它比精巧的签名协议简单得多，并且在安全连接的情况下仍然有效。 你只需要确保密码永远不会超过纯文本; 所以如果通过纯文本连接收到密码，您甚至可能会禁用密码并向开发人员发送邮件。 您还应该确保凭据在收到后不会记录到任何位置，就像您不会记录常规密码一样。
HTTP Digest是一种更安全的方法，因为它可以防止秘密令牌传递; 相反，它是服务器可以在另一端验证的散列。 尽管如果您采取了上述预防措施，对于敏感度较低的应用程序来说，这可能是过度的。 毕竟，用户的密码在登录时已经以纯文本形式传输（除非您在浏览器中进行一些奇妙的JavaScript加密），并且每次请求都使用Cookie。
请注意，使用API时，客户端最好传递令牌 - 随机生成的字符串 - 而不是开发人员登录到网站的密码。 因此，开发者应该能够登录到您的网站并生成可用于API验证的新令牌。
使用令牌的主要原因是，如果它被泄露，它可以被替换，而如果密码被泄露，则所有者可以登录到开发者的账户并且用它做任何他们想做的事情。 令牌的另一个优点是可以向同一个开发者发出多个令牌。 也许是因为他们有多个应用程序或者因为他们想要具有不同访问级别的令牌。
（已更新以涵盖仅使SSL连接的含义。）
或者你可以使用已知的解决方案解决这个问题并使用SSL。 自签名证书是免费的，它的个人项目是正确的？
链接地址: http://www.djcxy.com/p/12307.html