如何保护RESTful Web服务?

我必须实现安全的REST风格的Web服务 。 我已经做了一些使用谷歌的研究,但我卡住了。

选项:

TLS(HTTPS)+

  • HTTP基本(pc1oad1etter)
  • HTTP摘要
  • 双腿 OAuth
  • 基于Cookie的方法
  • 客户端证书(Tom Ritter和这里 )
  • 使用HMAC签名的请求和有限的生命周期

有更多可能的select考虑? 如果OAuth那么什么版本? 它甚至重要吗? 从迄今为止我读到的OAuth 2.0与无记号(没有签名)似乎是不安全的 。

我发现了另一篇关于基于REST的authentication的非常有趣的文章。

保护您的REST API …正确的方法

还有另外一个非常安全的方法。 这是客户端证书。 在https上联系他们时知道服务器如何提供SSL证书? 那么服务器可以向客户请求证书,这样他们就知道客户是他们自己说的。 客户生成证书并通过一个安全的渠道给你(例如,用USB密钥进入你的办公室 – 最好是一个非攻击性的USB密钥)。

如果需要,您可以将证书客户端证书(及其签名者证书)的公钥加载到您的Web服务器中,并且Web服务器不会接受任何人的连接, 除了拥有相应的证书私钥的人员它知道。 它运行在HTTPS层上,所以你甚至可以完全跳过像OAuth这样的应用程序级authentication(取决于你的要求)。 您可以将图层抽象出来并创build一个本地证书颁发机构,并从客户端签署证书请求,允许您跳过“让他们进入办公室”和“将证书加载到服务器”的步骤。

痛苦的脖子? 绝对。 对一切都好? 不。 非常安全? 对。

它确实依赖于客户保证他们的证书安全(他们不能在网上发布他们的私钥),而且通常用于向客户销售服务,而不是让任何人注册和连接。

无论如何,这可能不是你正在寻找的解决scheme(这可能不是诚实的),但它是另一种select。

HTTP Basic + HTTPS是一种常用的方法。

如果selectOAuth版本,请使用OAuth 2.0。

OAuth承载令牌只能用于安全的传输。

OAuth承载令牌只与encryption会话的传输一样安全或不安全。 HTTPS负责防范重放攻击,因此不需要不记名令牌来防止重放。

诚然,如果有人拦截你的不记名标记,他们可以在调用API的时候冒充你,但是有很多方法可以减轻这种风险。 如果你的代币有很长的到期期限,并希望你的客户在本地存储代币,那么与代币短期到期相比,你的代币被截获和滥用的风险更大,要求客户每次获得新的代币,并build议客户不要坚持令牌。

如果您需要保护通过多个参与者的有效负载,那么您需要的不仅仅是HTTPS / SSL,因为HTTPS / SSL仅对图的一个链接进行encryption。 这不是OAuth的错。

承载令牌易于客户获取,客户可以轻松使用API​​调用,并被广泛使用(使用HTTPS)来保护来自Google,Facebook和其他许多服务的面向公众的API。