个人理解
我认为它是分布式session的替代物，在没有jwt之前，我们可以用redis等缓存服务器来充当session存储服务器，用户根据cookic中的token到redis服务器取用户信息，这也是单点登录的一种设计方案。而JWT的出现，使成本更低，我们可以单独部署一台授权服务器，甚至把授权服务器和应用部署在同一台服务器，来验证用户信息并返回一个jwt，该jwt存储在用户端（可存储在cookic中）。当用户需要访问一个路径、资源时，在http请求的头部中添加Authorization:bearer <token>，token在登录认证后由服务器生成并返回，就可以访问该资源，这也使得跨域访问（到其他的服务器中获取资源）更方便，因为授权信息已经存在于http请求中了，而且该授权信息的数据量不大，也避免不同服务器不同cookic实现带来的阻碍。不同语言和平台，只要服务器端实现了jwt授权认证，用户的token就可以随时验证权限而后获取资源，同时也避免了为了验证用户信息而多次查询数据库。
JWT授权时序图
一个JWT由3个json部分组成，通过base64Url编码后用.符号来分隔，最终的JWT形式：xxxxx.yyyyy.zzzzz
header（头部）
{
"alg":"HS256", // 加密算法
"typ":"JWT" // 类型
}
payload（类似Http的body），可以包含多个claim（claim的key通常是由3个字符组成的，值通常是用户信息和另外的元数据）
claim分为3种：
预备的：JWT预先实现的，比如（iss (issuer), exp (expiration time), sub (subject), aud (audience)）等；
公有的：定义包含namespace的uri，或者定义一些已经在IANA注册的claim；
私有的：定义多个应用约定好要共享的数据。
payload的例子
{
"sub": "1234567890",
"name": "John Doe",
"admin": true
}
signature（签名，服务器认准此签名进行授权）
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret)
上面就是一个签名，HMACSHA256是我们在header中指定的加密算法，对base64UrlEncode(header)、
base64UrlEncode(payload)和secret进行加密。用来验证请求发送者的身份和确保JWT中途没有被窜改。
一个完整的JWT
与session的主要区别
JWT把用户信息加密后存放在http的header中，可以不使用cookic，更加通用，跟restful配置更顺手，可以跨平台跨语言，比较适合分布式应用。但是对于规模较小的应用，比如单服务器应用，还是用session比较好，不用特意在服务器中实现JWT授权。
JWT的缺点
1.token的有效性太过依赖生成token时设置的过期时间，用户一旦拿到token就可以随时访问服务器，服务器对token不可控，只能等它失效；
2.只能与https配置使用，否则token会被窃取，他人就可以伪装成该token的持有者去各个服务器获取数据；
3.各个服务器都得实现JWT，才可以相互请求资源。