我想保护我的Rest API,哪种是保护Rest Api的最佳方法?我想使用用户名和密码在请求标头中进行身份验证。我对OAuth2和JWT令牌感到困惑。如果可能的话,请提供样本让我理解。
看一下这个链接。它说明了username:password和OAuth之间的一些区别。
带TLS的基本API身份验证
基本的API身份验证是这三种方法中最容易实现的,因为在大多数情况下,无需附加库即可实现它。实现基本身份验证所需的一切通常都包含在您的标准框架或语言库中。基本身份验证的问题在于,它是“基本”的,并且提供了通用协议中最低的安全性选项。没有使用此协议的高级选项,因此您只发送的是Base64编码的用户名和密码。如果没有TLS(以前称为SSL)加密,则绝对不能使用基本身份验证,因为否则用户名和密码组合很容易解码。
OAuth1.0a
OAuth 1.0a是三种常见协议中最安全的。OAuth1是一种广泛使用的,经过测试的,安全的,基于签名的协议。该协议使用组合了令牌机密,随机数和其他基于请求的信息的密码签名(通常为HMAC-SHA1)值。OAuth 1的最大优点是您永远不会直接在网上传递令牌密钥,从而完全消除了任何人在传输过程中看到密码的可能性。这是在没有SSL的情况下可以安全使用的三种协议中的唯一一种(尽管如果传输的数据是敏感的,您仍然应该使用SSL)。但是,这种级别的安全性是有代价的:生成和验证签名可能是一个复杂的过程。您必须使用一组严格的步骤来使用特定的哈希算法。然而,
OAuth2
OAuth2听起来像是OAuth1的演变,但实际上,它是完全不同的身份验证方法,试图降低复杂性。OAuth2的当前规范删除了签名,因此您不再需要使用加密算法来创建,生成和验证签名。现在,所有加密都由TLS处理,这是必需的。OAuth2库不如OAuth1a库那么多,因此利用此协议实现REST API安全可能更具挑战性。
去年,OAuth2标准的主要作者和编辑辞职,并发表了这篇内容丰富的帖子。.由于规格委员会的这种不稳定以及OAuth2的默认设置不如OAuth1安全(没有数字签名意味着您无法验证内容是否合法)。已在传输之前或之后进行了篡改),对于敏感数据应用,我们建议OAuth1优于OAuth2。OAuth2对于不太敏感的环境(例如某些社交网络)可能有意义。
自订通讯协定
除非您真的,真的知道自己在做什么并且完全了解加密数字签名的所有复杂性,否则应避免使用自定义API身份验证协议。大多数组织没有此专业知识,因此我们建议使用OAuth1.0a作为可靠的替代方案。
即使您愿意走这条潜在的危险道路,也有避免它的另一个原因:由于它是自定义的,因此您将无法轻松使用它。仅当您愿意支持可以提供给REST API调用程序(Java,Ruby,PHP,Python等)的客户端库时,才使用自定义身份验证协议,以便您的用户可以轻松使用这些协议。否则,API将被忽略。
我们选择了什么?在Stormpath,我们确实使用了自定义身份验证协议。它与OAuth1非常相似,但具有许多增强功能(例如,与OAuth1不同,Stormpath的方案在计算签名时使用请求主体,以确保主体不被篡改,其中包括诸如其他密钥派生功能)。但是同样,此算法仅对使用我们的实现此算法的SDK的客户端有用。对于不能使用我们的SDK的客户端,我们还支持其他通用协议。
为什么要使用API密钥与用户名/密码身份验证
我们使用的另一种技术是生成API密钥,而不是传统的用户名/密码身份验证。该决定已在我们的博客中得到了充分记录,但对于API安全性也非常重要,因此以下是关于API密钥的Cliff注意事项:
熵
API密钥/秘密通常是一连串的随机字符,很难猜到。用户名/密码的长度通常小得多,使用常用单词,通常不安全,并且可能遭受暴力破解和字典攻击。
密码重置问题
密码经常重置。如果将密码用作API身份验证方案的一部分,则每次更改密码后,API访问都会失败。
速度
最佳做法是对数据库中的密码进行加密,以限制潜在的数据泄露。验证用户时,这会增加每个请求的开销。独特的API密钥身份验证跳过了哈希步骤,因此加快了调用速度。
因此,请确定最适合您的实施方案!