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