如今，越来越多的项目开始采用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本身就没有太多含义，只需修改服务端中存储的数据即可。
适用场景
JWT
JWT的最佳用途是一次性授权Token，这种场景下的Token的特性如下：
- 有效期短
- 只希望被使用一次
真实场景的例子——文件托管服务，由两部分组成：
- Web 应用：这是一个可以被用户登录并维持状态的应用，用户在应用中挑选想要下载的文件。
- 文件下载服务：无状态下载服务，只允许通过密钥下载。
如何把JWT用在这个场景中呢？
- 用户登录到 Web 应用中，挑选好想要下载的文件，点击下载。
- 认证服务颁发包含下载信息的、具有较短过期时间的JWT。JWT中包含的信息可以是这样的：
{ "file": "/books/我这一辈子.pdf
