JWT必知必会

最近，项目的安全认证机制全面采用JWT。如今，趁整个工做基本告一段落之际，将一些知识点总结一下发布出来。

为何要迁移？

缘由很简单，就如下几点：

• 为了迁移到微服务架构，因为服务分拆以后，单一的登陆入口点消失了，采用Token是必然之选。
• 为了伸缩性考虑，采用Cookie + Session机制，必然面临着应用状态的问题，并且必然牵涉到session的复制。采用Token，自然避免这一点。这里并不是是指彻底无Session化，但起码能够降至最少。
• 为了移动端考虑，Token更适合移动端，比Cookie更灵活了。
• 为了安全性考虑，Token机制【仅验证request header时】自然对CSRF免疫。

JWT为什么物？

JWT由三部分组成：header + payload + signature，每部分是一个Json表示。最终的Token对这三部分进行编码以后的字符串，中间用“.”分割：

token = encodeBase64(header) + '.' + encodeBase64(payload) + '.' + encodeBase64(signature) # token is now: 
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJsb2dnZWRJbkFzIjoiYWRtaW4iLCJpYXQiOjE0MjI3Nzk2Mzh9.gzSraSYS8EXBxLN_oWnFSRgCzcmJmMjLiuyu5CSpyHI

在应用与服务器之间传递的就是上述字符串形式的Token。

如何使用JWT？

使用JWT的应用基本都遵循下面的使用流程：

1. 访问登陆点。
2. 登陆服务验证以后，签发证书返回给客户端。
3. 客户端保存证书，并在每次请求时将其附在request header中，表示已经登陆。
4. 服务器接收请求以后，经过签名和时戳，验证Token的有效性。
5. 如有效，则响应客户端。

对应的request header以下：

Authorization:Bearer <token>

整个过程以下图：

在通常的应用中，验证成功以后，服务器可能会在Cookie或Session中保留一些用户相关的额外信息，简化后续的编程，同时避免反复读取数据库。

在JWT，一样能够实现这样的功能：只需将相应的内容放入payload便可。这样，下次从客户端发送的token中即可以解码得出。

验证JWT的有效性时，会考虑至少下面两点：

1. 签名是否正确？
2. Token是否到期？

整个过程的编码其实并不复杂，请参见文后的连接，这里再也不啰嗦。

使用中的注意事项

出于安全性，注意如下几点：

• 签名证书须要安全存放
• 不要将敏感信息放置于token中
• 请结合SSL使用

• 若是要在Cookie中保存Token【此时，服务器要同时验证cookie或header中是否有token】

  • 留意Token的大小超过Cookie的限制
  • 请使用HttpOnly标志。如有可能，使用Secure标志。
  • 采用Synchronize Token来防止CSRF【这是由于，在A站点上发起向B站点的请求时，B站点的Cookie一样会被发送给B。若不使用另外一个Token来防御，则没法得知cookie中的JWT是否属于从A->B，仍是从B->B。目前，大部分现有的框架已经支持】。
• 为了防止replay attack，可加上jti、exp和iat声明

以上是对JWT的旋风式说明，其余的内容，请参见参考文献。

参考文献

• Get Started with JSON Web Tokens
• Introduction to JSON Web Tokens
• 维基百科上的JWT
• Vert.x Web的JWT例子
• Where to Store your JWTs – Cookies vs HTML5 Web Storage
• Use JWT The Right Way!
• Authentication: Cookies vs JWTs and why you’re doing it wrong
• How to store a JWT token inside an HTTP only cookie?
• Cookies vs Tokens: The Definitive Guide
• 管理JWT的生命周期
• JWT规范