我在身份验证中使用基于令牌的方法，但在许多博客中，我读到他们正在将令牌存储在数据库中。
我们是否需要在DB中以令牌为基础的身份验证存储令牌？
https://scotch.io/tutorials/the-ins-and-outs-of-token-based-authentication
在这个博客中，提到我们签署令牌而不是存储在数据库中，我认为这应该是实现真正无状态的方法。
答案 0 :(得分：4)
如果您使用链接/提及网页中描述的令牌基本身份验证，则无需将令牌存储在数据库中。
您必须考虑的是，可以传输资源服务器所需的所有必需信息，以便以安全的方式在令牌内完整地提供所请求的资源。
要以安全的方式传输 userId ，您还可以加密令牌。如果您想确保某些数据永远不会出于安全原因而离开您的数据中心，那么将这些数据保存在数据库中并且令牌只包含存储在数据库中的用户相关数据的引用（id） - 更多或更少Open ID connect中描述的内容。
您还应该记住，向令牌添加用户信息意味着每个请求的附加有效负载，并且可能需要更长时间来加密/解密并签名/验证签名。
如果您打算使用无状态/数据库较少的方法，您应该澄清：
答案 1 :(得分：0)
这取决于。 如果您有多个服务器在服务器重新启动之间保留令牌，则需要将其保留在某处。数据库通常是一个简单的选择。 如果您有一台服务器，并且不关心用户在重新启动后必须再次登录，那么您可以将其保留在内存中。
答案 2 :(得分：0)
如果您正在构建Web应用程序，则有几个选项：
如果比较这些方法，两者都会向浏览器收到JWT。两者都是无状态的，因为您需要的所有信息都在JWT中。两者都很容易传递回受保护的API。不同之处在于媒介。
可以通过同一域上的JavaScript访问Web存储（localStorage / sessionStorage）。这意味着您站点上运行的任何JavaScript都可以访问Web存储，因此可能容易受到跨站点脚本（XSS）攻击。简而言之，XSS是一种漏洞，攻击者可以在其中注入将在您的页面上运行的JavaScript。基本的XSS攻击试图通过表单输入注入JavaScript，攻击者将<script>alert('You are Hacked');</script>放入表单中，以查看它是否由浏览器运行，并且可以被其他用户查看。
作为一种存储机制，Web Storage在传输过程中不会强制执行任何安全标准。读取Web存储并使用它的人必须尽职尽责，以确保他们始终通过HTTPS发送JWT，而不是HTTP。
Cookie与HttpOnly Cookie标记一起使用时，无法通过JavaScript访问，并且不受XSS的影响。您还可以设置Secure cookie标志，以保证cookie仅通过HTTPS发送。这是过去利用cookie来存储令牌或会话数据的主要原因之一。现代开发人员对使用cookie犹豫不决，因为他们传统上需要将状态存储在服务器上，因此破坏了RESTful最佳实践。如果要在cookie中存储JWT，作为存储机制的Cookie不需要将状态存储在服务器上。这是因为JWT封装了服务器为请求提供服务所需的一切。
但是，Cookie容易受到不同类型的攻击：跨站点请求伪造（CSRF）。 CSRF攻击是一种攻击，当恶意网站，电子邮件或博客导致用户的Web浏览器在用户当前已通过身份验证的受信任站点上执行不需要的操作时，就会发生此类攻击。
您可以通过添加xsrfToken JWT声明来使此CSRF保护无状态。
利用您的Web应用程序框架的CSRF保护，使得cookie可以用于存储JWT。通过检查API中的HTTP Referer和Origin标头，也可以部分阻止CSRF。 CSRF攻击将包含与您的应用程序无关的Referer和Origin标头。
答案 3 :(得分：0)
我正在思考2种方法来使Web应用程序调用rest api。
first: store on db and each request call we make a check token.
second: store on cookies and it check in services memory