我必须实现安全的RESTful Web服务。我已经使用Google进行了一些研究，但遇到了麻烦。
选项：
TLS（HTTPS）+
还有更多可能的选择要考虑吗？如果是OAuth，那么什么版本？有关系吗 从到目前为止的内容来看，带有承载令牌（没有签名）的OAuth 2.0似乎是不安全的。
我发现了另一篇有关基于REST的身份验证的非常有趣的文章。
我必须实现安全的RESTful Web服务。我已经使用Google进行了一些研究，但遇到了麻烦。
选项：
TLS（HTTPS）+
还有更多可能的选择要考虑吗？如果是OAuth，那么什么版本？有关系吗 从到目前为止的内容来看，带有承载令牌（没有签名）的OAuth 2.0似乎是不安全的。
我发现了另一篇有关基于REST的身份验证的非常有趣的文章。
Answers:
还有另一种非常安全的方法。它是客户证书。在通过https与服务器联系时，是否知道服务器如何提供SSL证书？好的服务器可以从客户端请求证书，以便他们知道客户端是他们所说的身份。客户端生成证书，并通过安全通道将其提供给您（例如，使用USB密钥（最好是非木马USB密钥）进入您的办公室）。
您将证书客户端证书的公共密钥（及其签名者的证书，如有必要）加载到您的Web服务器中，该Web服务器将不接受任何人的连接，但拥有证书相应私钥的人除外它知道。它运行在HTTPS层上，因此您甚至可以完全跳过OAuth之类的应用程序级身份验证（取决于您的要求）。您可以抽象一个层并创建本地证书颁发机构，并从客户端签署证书请求，从而可以跳过“使它们进入办公室”并将“将证书加载到服务器上”的步骤。
脖子疼吗？绝对。一切都好吗？不。很安全吗 对。
但是，它确实依赖于客户确保其证书安全（他们不能在线发布其私钥），并且通常在您向客户出售服务而不是让任何人进行注册和连接时使用。
无论如何，这可能不是您要寻找的解决方案（说实话，这可能并不适用），但这是另一种选择。
HTTP Basic + HTTPS是一种常用方法。
如果要在OAuth版本之间进行选择，请使用OAuth 2.0。
OAuth承载令牌应仅与安全传输一起使用。
OAuth承载令牌仅与对会话进行加密的传输一样安全或不安全。HTTPS可以防止重放攻击，因此，承载令牌也不必防御重放。
确实，如果有人拦截了您的承载令牌，他们可以在调用API时冒充您，但有很多方法可以减轻这种风险。如果您给令牌提供了较长的有效期，并希望客户将令牌存储在本地，那么与让令牌短暂到期相比，令牌被拦截和滥用的风险要大得多，这要求客户端为每个会话获取新令牌，并建议客户不要保留令牌。
如果您需要保护通过多个参与者的有效负载，那么您需要的不仅仅是HTTPS / SSL，因为HTTPS / SSL仅加密图形的一个链接。这不是OAuth的错。
承载令牌易于客户获得，易于客户端进行API调用，并且已广泛使用（与HTTPS一起）从Google，Facebook和许多其他服务中保护面向公众的API。