jwt使用评价

http://www.andaily.com/blog/?s=nimbus-jose-jwt

从易用性, 扩展性, 完整性等来看, 使用首先推荐 jose4j, 其次是 Nimbus-jose-jwt.

概述以及官方文档

JWT是一种紧凑且自包含的，用于在多方传递JSON对象的技术。传递的数据可以使用数字签名增加其安全行。可以使用HMAC加密算法或RSA公钥/私钥加密方式。
紧凑：数据小，可以通过URL，POST参数，请求头发送。且数据小代表传输速度快。
自包含：使用payload数据块记录用户必要且不隐私的数据，可以有效的减少数据库访问次数，提高代码性能。
JWT一般用于处理用户身份验证或数据信息交换。
用户身份验证：一旦用户登录，每个后续请求都将包含JWT，允许用户访问该令牌允许的路由，服务和资源。单点登录是当今广泛使用JWT的一项功能，因为它的开销很小，并且能够轻松地跨不同域使用。
数据信息交换：JWT是一种非常方便的多方传递数据的载体，因为其可以使用数据签名来保证数据的有效性和安全性。

https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-25#section-4.1.1

使用场景

Authorization (授权) : 这是使用JWT的最常见场景。一旦用户登录，后续每个请求都将包含JWT，允许用户访问该令牌允许的路由、服务和资源。单点登录是现在广泛使用的JWT的一个特性，因为它的开销很小，并且可以轻松地跨域使用。
Information Exchange (信息交换) : 对于安全的在各方之间传输信息而言，JSON Web Tokens无疑是一种很好的方式。因为JWTs可以被签名，例如，用公钥/私钥对，你可以确定发送人就是它们所说的那个人。另外，由于签名是使用头和有效负载计算的，您还可以验证内容没有被篡改。

用户提供用户名和密码,我们去数据库查询一下是否匹配,如果匹配了我们就签发token,用户得到token以后可以找一个地方存起来,比如存储浏览器cookie等等,下回用户请求接口时候需要提供token, 后台代码验证token对不对,看看是不是自己签发的,token里面包含的数据可以确定用户是谁,包含了什么权限等等,然后再确定给用户提供对应的权限的资源响应数据等等,token的格式,生成验证的方法可以使用jwt等等

身份认证在这种场景下，一旦用户完成了登陆，在接下来的每个请求中包含JWT，可以用来验证用户身份以及对路由，服务和资源的访问权限进行验证。由于它的开销非常小，可以轻松的在不同域名的系统中传递，所有目前在单点登录（SSO）中比较广泛的使用了该技术。 信息交换在通信的双方之间使用JWT对数据进行编码是一种非常安全的方式，由于它的信息是经过签名的，可以确保发送者发送的信息是没有经过伪造的。

它是如何做身份验证的？

首先，JWT 的 Token 相当是明文，是可以解密的，任何存在 payload 的东西，都没有秘密可言，所以隐私数据不能签发 token。
而服务端，拿到 token 后解密，即可知道用户信息

优点

JWT相比于Session的优点:
我们就来对比，传统的 session 和 JWT 的区别
我们以一个用户，获取用户资料的例子
传统的 session 流程
1.浏览器发起请求登陆
2.服务端验证身份，生成身份验证信息，存储在服务端，并且告诉浏览器写入 Cookie
3.浏览器发起请求获取用户资料，此时 Cookie 内容也跟随这发送到服务器
4.服务器发现 Cookie 中有身份信息，验明正身
5.服务器返回该用户的用户资料
JWT 流程
1.浏览器发起请求登陆
2.服务端验证身份，根据算法，将用户标识符打包生成 token, 并且返回给浏览器
3.浏览器发起请求获取用户资料，把刚刚拿到的 token 一起发送给服务器
4.服务器发现数据中有 token，验明正身
5.服务器返回该用户的用户资料

但实际上区别大了去了

不占用服务器内存开销：session需要保存在服务器，因此会占用服务器内存开销（尽管JWT会让服务器有一些计算压力，比如token的签名和验证）.
可扩展性强: 比如有3台机器（A、B、C）组成服务器集群，若session存在机器A上，session只能保存在其中一台服务器，此时你便不能访问机器B、C，因为B、C上没有存放该Session，而使用token就能够验证用户请求合法性，并且我再加几台机器也没事，所以可拓展性好就是这个意思。
前后端分离，支持跨域访问

登录成功之后jwt生成的token每次都是新的加密后的字符串.

缺点

有优点就会有缺点，是否适用应该考虑清楚，而不是技术跟风

1.token中不能保存私密敏感信息：Head和Payload使用base64进行编码
2.无法作废已颁布的token：由于所有的认证信息都在JWT中，即使你知道了某个JWT被盗取了，你也没有办法将其作废。在JWT过期之前（你绝对应该设置过期时间），你无能为力.
3.严重依赖于密钥:JWT生成与解析过程都需要依赖于密钥(Secret),且都是以硬编码的方式存在于系统中(也有放在外部配置文件中的),如果密钥不小心泄露了,系统的安全性将受到威胁.
4.JWT不是 session ，勿将token当session,服务端无法管理客户端的信息：如果用户身份发生异常(信息泄露，或者被攻击)，服务端很难向操作 Session 那样主动将异常用户进行隔离。
5.服务端无法主动推送消息：服务端由于是无状态的，他将无法使用像 Session 那样的方式推送消息到客户端，例如过期时间将至，服务端无法主动为用户续约，需要客户端向服务端发起续约请求。
6.冗余的数据开销：一个 JWT 签名的大小要远比一个 Session ID 长很多，如果你对有效载荷(payload)中的数据不做有效控制，其长度会成几何倍数增长，且在每一次请求时都需要负担额外的网络开销。
7.JSON Web Token 很流行，但是它相比于 Session,OIDC(OpenId Connect)等技术还比较新，支持 JSON Web Token 的库还比较少，而且 JWT 也并非比传统 Session 更安全，他们都没有解决 CSRF 和 XSS 的问题。因此，在决定使用 JWT 前，你需要仔细考虑其利弊。