在基于令牌的身份验证中，应用程序服务器如何知道哪些令牌有效？

Question

我试图了解Cookie与基于令牌的身份验证。我掌握了基础知识-cookie必须每次都必须存储在服务器（以及客户端）中，而每次令牌都必须存储在客户端中。服务器只需解码所有传入的令牌并验证请求。

我不明白的是，如果没有在服务器的任何位置存储有效令牌的列表，服务器如何知道任何解码的令牌是否有效？

https://dzone.com/articles/cookies-vs-tokens-the-definitive-guide

  

  
1. 用户输入其登录凭据。
  
2. 服务器验证凭据正确无误，并返回签名的令牌。
  
3. 此令牌存储在客户端，通常存储在本地存储中-但也可以存储在会话存储或cookie中。
  
4. 对服务器的后续请求将此令牌作为附加的Authorization标头或通过上述其他方法之一包括在内。
  
5. 服务器解码JWT，如果令牌有效，则处理请求。
  
6. 用户注销后，令牌将在客户端被销毁，无需与服务器进行交互。
  

具体来说-我想知道＃5的工作原理。谢谢。

Answer 1

您的问题的完整答案将很长，但是这是我的简短尝试。服务器也恰好是首先发布JWT的实体。因此，它具有一个 key ，用于对每个传出的JWT进行签名。结果，当服务器收到传入的JWT时，它首先尝试使用其私钥打开/解锁该JWT。如果以任何方式篡改了JWT，则服务器可能无法正确打开它，这将导致异常。作为服务器将对传入的JWT执行完整性检查的一个示例，它将观察JWT的 checksum ，在篡改的情况下不会通过。

一旦服务器打开了JWT并认为它是有效的，它接下来可能要检查的事情就是exp claim ，它可能是包含在其中的多个声明之一智威汤逊。 exp或到期声明记录JWT有效的时间。如果用户提出陈旧的JWT，服务器将立即拒绝JWT为无效。

到目前为止，我们一直在讨论服务器可以不使用任何状态（即仅依赖于JWT本身包含的状态）执行的检查。实际上，大多数情况下，服务器实际上会存储自己的某些状态。作为可能为什么需要这样做的示例，请考虑注销网站或应用程序的用户的特殊情况。在这种情况下，他的电话或浏览器仍将使用有效期exp的JWT。为了防止用户继续使用此JWT，即使exp和校验和通过检查，服务器也可能会保留一个JWT的黑名单，该黑名单将不被接受。因此，解锁JWT并检查exp之后的第三步可能是确保JWT不会出现在黑名单中。

一个好的JWT实现可以将服务器端状态的数量限制在很小的程度，但是通常服务器实际上会维护自己的某些状态。