我在身份验证中使用基于令牌的方法，但在许多博客中我读到他们将令牌存储在数据库中。
我们需要将令牌存储在数据库中的基于令牌的身份验证中吗？
https://scotch.io/tutorials/the-ins-and-outs-of-token-based-authentication
在这篇博客中，提到我们正在签署令牌而不是存储在数据库中，我认为这应该是实现真正无状态的方法。
【问题讨论】：
Authentication : Basic xSdaqsdfawEFdqweD 的东西吗？但是basic只有base64，不需要保存。你可以在每次新的时候计算它们。
标签： authentication token
如果您使用链接/提到的网页中描述的基于令牌的身份验证，则无需将令牌存储在数据库中。
您必须考虑的是，是否可以传输资源服务器所需的所有信息，以便以安全的方式在令牌中交付请求的资源。
要以安全的方式传输例如 userId，您可以另外加密令牌。如果您想确保某些数据出于安全原因永远不会离开您的数据中心，那么将这些数据保存在数据库中是一个好主意，并且令牌仅包含对存储在数据库中的用户相关数据的引用（id） - 更多或更少 Open ID connect 中描述的内容。
您还应该记住，将用户信息添加到令牌意味着每个请求都有额外的负载，并且可能需要更长的时间来加密/解密和签署/验证签名。
如果您要使用无状态/无数据库方法，您应该澄清：
【讨论】：
这取决于。 如果您有多个服务器在服务器重新启动之间保留令牌，那么您需要将其保存在某个地方。数据库通常是一个简单的选择。 如果您有一个服务器并且不关心您的用户必须在重新启动后再次登录，那么您可以将其保留在内存中。
【讨论】：
如果您正在构建 Web 应用程序，您有几个选择：
如果您比较这些方法，它们都会收到一个 JWT 到浏览器。两者都是无状态的，因为您的 API 需要的所有信息都在 JWT 中。两者都很容易传回受保护的 API。区别在于媒介。
Web 存储 (localStorage/sessionStorage) 可通过同一域上的 JavaScript 访问。这意味着在您的站点上运行的任何 JavaScript 都可以访问 Web 存储，因此很容易受到跨站点脚本 (XSS) 攻击。简而言之，XSS 是一种漏洞，攻击者可以在其中注入将在您的页面上运行的 JavaScript。基本的 XSS 攻击尝试通过表单输入注入 JavaScript，攻击者将<script>alert('You are Hacked');</script> 放入表单中以查看它是否由浏览器运行并可供其他用户查看。
作为一种存储机制，Web Storage 在传输过程中不强制执行任何安全标准。阅读和使用 Web Storage 的人必须尽职尽责，以确保他们始终通过 HTTPS 而不是 HTTP 发送 JWT。
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 标头。
Read this great blog post 来自Stormpath 了解更多详情。
【讨论】：
我正在考虑两种方法让网络应用程序调用 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
【讨论】：