这是一种++无状态身份验证机制++，因为用户状态永远不会保存在服务器内存中。 服务器受保护的路由将在授权头中检查有效的JWT，如果存在，则允许用户访问受保护的资源。 由于JWT是独立的，所有必要的信息都在那里，减少了多次查询数据库的需求。
这使得我们可以完全依赖无状态的数据API，甚至向下游服务提出请求。 无论哪些域正在为API提供服务并不重要，因此不会出现跨域资源共享（CORS）的问题，因为它不使用Cookie。
请注意，使用已签名的令牌，令牌中包含的所有信息都会暴露给用户或其他方，即使他们无法更改它。 在JWT中，不应该在Playload里面加入任何敏感的数据,比如像密码这样的内容。如果将用户的密码放在了JWT中，那么怀有恶意的第三方通过Base64解码就能很快地知道你的密码了。
5. 常见问题 ① JWT 安全嗎?Base64编码方式是可逆的，也就是透过编码后发放的Token内容是可以被解析的。一般而言，我们都不建议在有效载荷内放敏感讯息，比如使用者的密码。
② JWT Payload 內容可以被伪造嗎？JWT其中的一个组成内容为Signature，可以防止通过Base64可逆方法回推有效载荷内容并将其修改。因为Signature是经由Header跟Payload一起Base64组成的。
③ 如果我的 Cookie 被窃取了，那不就表示第三方可以做 CSRF 攻击?是的，Cookie丢失，就表示身份就可以被伪造。故官方建议的使用方式是存放在LocalStorage中，并放在请求头中发送。
④ 空间及长度问题？JWT Token通常长度不会太小，特别是Stateless JWT Token，把所有的数据都编在Token里，很快的就会超过Cookie的大小（4K）或者是URL长度限制。
⑤ Token失效问题？
无状态JWT令牌（Stateless JWT Token）发放出去之后，不能通过服务器端让令牌失效，必须等到过期时间过才会失去效用。
假设在这之间Token被拦截，或者有权限管理身份的差异造成授权Scope修改，都不能阻止发出去的Token失效并要求使用者重新请求新的Token。
6. JWT使用建议不要存放敏感信息在Token里。
Payload中的exp时效不要设定太长。
开启Only Http预防XSS攻击。
如果担心重播攻击（replay attacks ）可以增加jti（JWT ID），exp（有效时间） Claim。
在你的应用程序应用层中增加黑名单机制，必要的时候可以进行Block做阻挡（这是针对掉令牌被第三方使用窃取的手动防御）。
[1] Stop using JWT for sessions：
~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/
[3] Use JWT The Right Way!:
https://stormpath.com/blog/jwt-the-right-way
[2] JSON Web Token 维基百科：
https://en.wikipedia.org/wiki/JSON_Web_Token