我正在尝试了解 cookie 与基于 token 的身份验证。我了解了基础知识 - cookie 必须存储在服务器(以及客户端)中以便每次进行验证，而 token 只需存储在客户端。服务器只需解码任何传入的 token 并验证请求。
我不明白的是，如果有效 token 列表没有存储在服务器中的任何位置，服务器如何知道任何解码的 token 是否有效？
https://dzone.com/articles/cookies-vs-tokens-the-definitive-guide
- User enters their login credentials.
- Server verifies the credentials are correct and returns a signed token.
- This token is stored client-side, most commonly in local storage - but can be stored in session storage or a cookie as well.
- Subsequent requests to the server include this token as an additional Authorization header or through one of the other methods mentioned above.
- The server decodes the JWT and if the token is valid processes the request.
- Once a user logs out, the token is destroyed client-side, no interaction with the server is necessary.
具体来说 - 我想知道#5 是如何工作的。谢谢。
最佳答案
对您问题的完整回答非常，但我尝试做一个简短的回答。服务器也恰好是首先发出 JWT 的实体。因此，它拥有一个 key ，用于签署每个传出的 JWT。因此，当服务器收到传入的 JWT 时，它首先尝试使用其私钥打开/解锁该 JWT。如果 JWT 被以任何方式篡改，服务器可能无法正确打开它，并会导致异常。作为服务器对传入 JWT 执行的健全性检查的一个示例，它将观察 JWT 的校验和，在篡改的情况下不会通过。
一旦服务器打开 JWT 并认为它有效，它可能会检查的下一件事情是 exp claim，它可能是多个声明之一包含在 JWT 中。 exp(或过期声明)记录 JWT 的有效时间。如果用户提供过时的 JWT，服务器将立即拒绝该 JWT，因为该 JWT 无效。
到目前为止，我们一直在讨论服务器可以不使用状态执行的检查，即仅依赖于 JWT 本身包含的状态。事实上，大多数时候服务器实际上会存储它自己的某种状态。作为为什么这可能是必要的示例，请考虑退出网站或应用程序的用户的边缘情况。在这种情况下，他的手机或浏览器仍将带有具有有效 exp 过期时间的 JWT。为了防止用户继续使用此 JWT，服务器可能会维护一个 JWT 黑名单，即使 exp 和校验和通过检查，服务器也不会遵守该黑名单。因此，解锁 JWT 并检查 exp 后的第三步可能是确保 JWT 不会出现在黑名单中。
良好的 JWT 实现可以将服务器端状态量限制为非常小的值，但通常服务器实际上会维护自己的某些状态。
关于authentication - 在基于 token 的身份验证中，应用程序服务器如何知道哪些 token 有效？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/56436268/