token、session 和 JWT 有这么大的区别吗？

Question

最近在了解接口的认证机制，不可避免地碰到了 Token、Session、JWT (JSON Web Token) 等概念。网上看了一些博客，对它们有了一些认识，但随之产生了一些疑问，特来请教。

1. 如果 Token 是针对登录用户生成的唯一口令，并存在服务端，那么它与 SessionID 有什么区别呢？
2. Refresh Token 是为了解决什么问题呢？如果是为了避免由于 Token 的有效期太短而频繁验证身份导致用户体验差，为什么不设置一个有效期较长的 Token 呢？如果因为 Token 有效期太长而担心安全问题，那么 Refresh Token 的长有效期为什么不会导致安全问题呢？
3. 对于 JWT，很多文章提到“JWT 本身包含了认证信息，一旦泄露，任何人都可以获得该令牌的所有权限。”，对于普通的 Token 和 SessionID 难道不是面临一样的问题？
4. 现在比较常用的验证机制是哪一种呢？有没有经验指南？

Answer 1

如果 Token 是针对登录用户生成的唯一口令，并存在服务端，那么它与 SessionID 有什么区别呢？

没太大区别，对于在 web 端的话，如果允许了跨域 Cookie，那相比发送 Token 来说，就少了一个主动管理 Token 的步骤。其他情境下基本都差不多，都是需要在服务端存储 Token（SessionID）。

Refresh Token 是为了解决什么问题呢？如果是为了避免由于 Token 的有效期太短而频繁验证身份导致用户体验差，为什么不设置一个有效期较长的 Token 呢？如果因为 Token 有效期太长而担心安全问题，那么 Refresh Token 的长有效期为什么不会导致安全问题呢？

Token 是会在你每次请求的时候都发送给服务端，以让服务端来确认你是谁，而如果你存在于不安全的网络环境下，每次发送的 Token 就存在被截获的可能性，第三方拿到你的 Token 后就可以代替你去操作，形成安全问题，较短的 Token 有效期则可以在一定程度上减少你的损失。

而 Refresh Token 则只是在你登录或者刷新 Token 后才会获得，并保存在客户端，不会每次发送，相对安全一些，当然如果截获到了你的 Refresh Token 也可以不停的刷新你的 Token，同样还是存在安全问题，所以 Refresh 同样也会存在失效时间，只是相较 Token 的有效时间更长，并不会无限长。

并且，大部分时候，刷新 Token 这一步骤，不应为用户所感知。

PS：如果你持续处于不安全的网络环境，那以上手段根本救不了你

除此之外，你应该也不想你在一个设备上登录后，这个 Token 始终可以访问你的账户，即使这个设备不再为你所使用，因而这也存在一些风险情况。

对于 JWT，很多文章提到“JWT 本身包含了认证信息，一旦泄露，任何人都可以获得该令牌的所有权限。”，对于普通的 Token 和 SessionID 难道不是面临一样的问题？

是的，不论哪种情况，只要你的 Token 泄露了，别人就可以伪造你的身份，最常见的，比如 百度网盘的 bdstoken 还有京东、QQ 的那些个 Token。

现在比较常用的验证机制是哪一种呢？有没有经验指南？

软件工程没有银弹，往往一种方案并不能完美解决。

比如 JWT，他的优势就是后端不需要存储 Token，而是通过密钥和签名算法来验证 Token 从而确保 Token 是合法有效的，并从里面读取出来信息使用。

而 JWT 的标准实现问题则在于，你没法吊销一个 Token，其一旦颁发，就只有等待其过期后，才判定为无效。

传统的 Token 就相对简单了，只要删除对应的 Token 就行了。

对于这种情况，就需要一个类似于 Token 黑名单的机制，在销毁 Token 时，将其加入黑名单，在读取时， JWT Token 通过验证后，判断 Token 是否处于黑名单，从而过滤被销毁的 Token。