所以我有一个问题要理解为什么“令牌”在不同的新网络技术中进行认证的炒作很多。
我理解这意味着改善使用Cookie和会话时可能“丢失”的控件。但是很多人都在谈论这样一个事实：它通过允许客户端 - 服务器通信成为无状态来坚持Restful“意识形态”。
但......是吗？我的意思是，无状态通信意味着服务器不必在客户端上存储任何信息用于auth，并且请求100％独立于彼此。
在令牌的情况下：
服务器显然需要存储它们（就像大多数应用程序中的客户端一样，如果你想让令牌重新启动）那么，客户端和服务器都有状态。
客户端需要轮询“/ get token”以便能够请求其他任何内容，并且此请求的结果会关闭任何进一步请求的结果。换句话说，如果我正在设计一个状态图，我的图表将由多个州组成。
所以对我而言，令牌与我们所谓的“无国籍”通信（这是架构为Restful的必要条件）无关。
顺便说一下，我认为HTTP凭证更接近于实现无状态通信，因为基本上，即使服务器仍然通过存储凭证而具有状态，auth +请求进程也只依赖于一个请求（作为凭据）是HTTP“对话”的第一个请求的完整部分。）
另一点HTTP凭据比令牌更好，是Restful API中的“客户端/服务器角色”。这一点指出RESTFul通信拆分客户端和服务器，这意味着客户端不必处理数据存储。但是在令牌的情况下，它们肯定需要存储，至少是暂时的（如果（例如）你希望浏览器在重启后使用cookie或localstorage保留令牌，则更多）。相比之下，用户可以在每次会话请求时填写HTTP信誉，使客户端非数据存储，就像它应该处于Restful表示一样。
另外我想指出，根据Rest架构，客户端持有的任何信息都应该由客户自行决定是否应该删除/修改它，99％不是这样。令牌系统不会使客户端存储令牌的超时日期（cookie所在的位置）。
总而言之，很多人因违反体系结构的Restfulness而将HTTP信誉或会话归咎于此。但令牌系统根本无法解决问题，是吗？
答案 0 :(得分：3)
如您的评论中所述，我假设您指的是jwt.io。
服务器显然需要存储它们（就像大多数客户端一样） 应用程序的情况，如果你想保持令牌重新启动）所以，两者 客户端和服务器确实有状态。
服务器不需要存储任何状态。甚至jwt.io上的默认示例也证明了这一点：
{
"sub": "1234567890",
"name": "John Doe",
"admin": true
}
使用JSON Web令牌，此信息将被签名并存储在客户端上。如果不知道秘密就无法更改信息，因此在此设计中，只要使用“足够强大”的密钥，就会被认为是安全的。
这就是为什么它可以被视为无国籍。正如您所提到的，客户端确实需要存储令牌，因此需要携带状态。但是，服务器没有，这意味着服务器端的实现可以被视为无状态。