我必须实现安全RESTful web services。我已经使用 Google 进行了一些研究，但我被卡住了。
选项：
TLS (HTTPS) +
还有更多可能的选择吗？如果是 OAuth，那么什么版本？这还重要吗？从我目前所读到的OAuth 2.0 带有不记名令牌（即没有签名）似乎是insecure。
我在REST based authentication上发现了另一篇非常有趣的文章。
【问题讨论】：
标签： web-services security rest oauth restful-authentication
如果在 OAuth 版本之间进行选择，请使用 OAuth 2.0。
OAuth 不记名令牌只能用于安全传输。
OAuth 不记名令牌仅与加密对话的传输一样安全或不安全。 HTTPS 负责防止重放攻击，因此不记名令牌也没有必要防止重放。
确实，如果有人拦截了您的不记名令牌，他们可以在调用 API 时冒充您，但有很多方法可以降低这种风险。如果你给你的令牌一个很长的有效期，并希望你的客户在本地存储令牌，那么你有更大的令牌被拦截和滥用的风险，而不是你给你的令牌一个短暂的有效期，要求客户在每个会话中获取新的令牌，并建议客户不要持久化令牌。
如果您需要保护通过多个参与者的有效负载，那么您需要的不仅仅是 HTTPS/SSL，因为 HTTPS/SSL 仅加密图表的一个链接。这不是 OAuth 的错误。
不记名令牌易于客户端获取，易于客户端用于 API 调用，并且广泛用于（通过 HTTPS）保护来自 Google、Facebook 和许多其他服务的面向公众的 API。
【讨论】：
还有另一种非常安全的方法。这是客户端证书。当您在 https 上联系服务器时，知道服务器如何呈现 SSL 证书吗？好吧，服务器可以向客户端请求证书，这样他们就知道客户端就是他们所说的那个人。客户生成证书并通过安全渠道将其提供给您（例如使用 USB 密钥进入您的办公室 - 最好是非木马 USB 密钥）。
您将 证书的公钥 客户端证书（及其签名者的证书，如有必要）加载到您的 Web 服务器中，并且 Web 服务器不会接受来自任何人的连接 除了拥有它所知道的证书的相应私钥的人。它在 HTTPS 层上运行，因此您甚至可以完全跳过 OAuth 之类的应用程序级身份验证（取决于您的要求）。您可以抽象出一个层并创建一个本地证书颁发机构并签署来自客户端的证书请求，从而允许您跳过“让他们进入办公室”和“将证书加载到服务器上”步骤。
脖子疼？绝对地。对一切都有好处吗？没有。非常安全？对。
它确实依赖于客户来保证他们的证书安全（他们不能在线发布他们的私钥），并且通常在您向客户出售服务而不是让任何人注册和连接时使用它。
无论如何，它可能不是您正在寻找的解决方案（说实话可能不太好），但它是另一种选择。
【讨论】：
HTTP Basic + HTTPS 是一种常用的方法。
【讨论】：