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