共计 2072 个字符，预计需要花费 6 分钟才能阅读完成。
如今，越来越多的项目开始采用 JWT 作为认证授权机制，那么它和之前的 Session 究竟有什么区别呢？今天就让我们来了解一下。
JWT 是什么
定义
JSON Web Token（JWT）是一个开放标准（RFC 7519），它定义了一种紧凑和自包含的方式，用于在各方之间作为 JSON 对象安全地传输信息。作为标准，它没有提供技术实现，但是大部分的语言平台都有按照它规定的内容提供了自己的技术实现，所以实际在用的时候，只要根据自己当前项目的技术平台，到官网上选用合适的实现库即可。
特点
使用 JWT 来传输数据，实际上传输的是一个字符串，这个字符串就是所谓的 json web token 字符串。所以广义上，JWT 是一个标准的名称；狭义上，JWT 指的就是用来传递的那个 token 字符串。这个串有两个特点：
紧凑：指的是这个串很小，能通过 url 参数，http 请求提交的数据以及 http header 的方式来传递；
自包含：这个串可以包含很多信息，比如用户的 id、角色等，别人拿到这个串，就能拿到这些关键的业务信息，从而避免再通过数据库查询等方式才能得到它们。
结构
它由三部分组成：header（头部）、payload（载荷）、signature（签名），以. 进行分割。（这个字符串本来是只有一行的，此处分成 3 行，只是为了区分其结构）
header 用来声明类型（typ）和算法（alg）。
payload 一般存放一些不敏感的信息，比如用户名、权限、角色等。
signature 则是将 header 和 payload 对应的 json 结构进行 base64url 编码之后得到的两个串用英文句点号拼接起来，然后根据 header 里面 alg 指定的签名算法生成出来的。
和 Session 的区别
为什么我们要把 JWT 和 Session 做对比呢？因为我们主要在每一次请求的认证时会用 JWT，在此之前我们都是用 Session 的。那这两者的区别在哪儿呢？
本身的含义
看了前面的介绍，我们发现 JWT 这个字符串其实本身就包含了关于用户的信息，比如用户名、权限、角色等。
Session 传递的 sessionId 虽然是一个更简单的字符串，但它本身并没有任何含义。
所以一般说来 JWT 的字符串要比 sessionId 长，如果你在 JWT 中存储的信息越长，那么 JWT 本身也会越长。
而 Cookie 的存储容量是有限制的（通常为 4KB），所以大家在使用的时候需要注意。
解析方法
JWT 的 header 和 payload 其实是有 json 转变过来的，而 signature 其实就是一个加密后的字符串，因此解析起来较为简单，不需要其他辅助的内容。
sessionId 是服务器存储的用户对象的标识，理论上需要一个额外的 map 才能找出当前用户的信息。
管理方法
JWT 理论上用于无状态的请求，因此其用户管理也只是依赖本身而已。我们一般是在它的 payload 中加入过期时间，在不增加额外管理的情况下，它只有自动过期的方式。
Session 因为它本就是存储在服务器端的，因此管理方案就有很多，而且大多都很成熟。
跨平台
JWT 本身就是基于 json 的，因此它是比较容易跨平台的，可以从官网下载不同平台的包，解析即可。
session 的跨平台可能就不那么好做了，需要考虑的地方在于用户信息存储的格式，ProtoBuf、json、xml 等，管理的话可能就需要专门的统一登录平台，这个就不展开了。
时效性
无状态 JWT 一旦被生成，就不会再和服务端有任何瓜葛。一旦服务端中的相关数据更新，无状态 JWT 中存储的数据由于得不到更新，就变成了过期的数据。
session 就不一样了，sessionId 本身就没有太多含义，只需修改服务端中存储的数据即可。
适用场景
JWTJWT 的最佳用途是一次性授权 Token，这种场景下的 Token 的特性如下：
有效期短
只希望被使用一次
真实场景的例子——文件托管服务，由两部分组成：
Web 应用：这是一个可以被用户登录并维持状态的应用，用户在应用中挑选想要下载的文件。
文件下载服务：无状态下载服务，只允许通过密钥下载。
如何把 JWT 用在这个场景中呢？
用户登录到 Web 应用中，挑选好想要下载的文件，点击下载。
认证服务颁发包含下载信息的、具有较短过期时间的 JWT。JWT 中包含的信息可以是这样的：
[Java] 纯文本查看 复制代码
?
{
“file”: “/books/ 我这一辈子.pdf”,
“exp”: 1500719759621
}
使用 JWT 从文件下载服务下载文件。
SessionSession 比较适用于 Web 应用的会话管理，其特点一般是：
权限多，如果用 JWT 则其长度会很长，很有可能突破 Cookie 的存储限制。
基本信息容易变动。如果是一般的后台管理系统，肯定会涉及到人员的变化，那么其权限也会相应变化，如果使用 JWT，那就需要服务器端进行主动失效，这样就将原本无状态的 JWT 变成有状态，改变了其本意。
总结
我们使用 JWT，并不是说看到它新就用，而应该考虑其适用场景，如果需要进行管理，可以考虑使用 Session，毕竟其方案更加成熟。
文章摘自：https://juejin.im/post/5d8054…
