我想保护我的Rest API，这是保护Rest Api的最佳方法吗？我想使用用户名和密码在请求标头中进行身份验证。我对OAuth2和JWT令牌感到困惑。如果可能，请提供样品以便了解。感谢。
答案 0 :(得分：4)
看看这个link。它解释了用户名：密码与OAuth之间的一些区别。
基本API身份验证w / TLS
基本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 Notes：
熵
API密钥/秘密通常是一系列难以猜测的随机字符。用户名/密码的长度通常要小得多，使用常用词，通常不安全，并且可能受到暴力破解和字典攻击。
密码重置问题
密码经常被重置。如果您将密码用作API身份验证方案的一部分，则每次更改密码时API访问都会失败。
速度
最佳做法是加密数据库中的密码以限制潜在的数据泄露。这在验证用户时增加了每个请求的开销。独特的API密钥身份验证会跳过散列步骤，从而加快您的通话速度。
因此，确定最适合您实施的内容！