JWT
-
JWT就像一个临时的用户凭证,代替了用户名和密码组合
-
JWT 的目的不是为了隐藏或者保密数据,而是为了确保数据确实来自被授权的人创建的(不被篡改)
-
它是 JSON 结构的 token,由三部分组成:header,payload,signature
- 格式:
Base64(Header) + "." + Base64(Payload) + "." + $Signature
- header
- JSON对象,用于描述元信息,例如产生 signature 的算法
- payload
- 用于携带希望向服务端传递的信息
- 由于payload不加密,建议只在其中保存非敏感的用于身份验证的数据
- signature 用于签名,校验合法性
- 利用认证服务器的密钥进行签名
- 格式:
HS256(Base64(Header) + "." + Base64(Payload), secretKey)
- HS256使用了对称加密算法,需要应用服务器也有同样的secretKey才能验证,安全性较差
- 所谓验证就是重新执行一次加密过程
- 现在一般用非对称加密算法的RS256进行签名,只有认证服务器有私钥,应用服务器用公钥验证
- 参考:https://www.jianshu.com/p/cba0dfe4ad4a
- HS256使用了对称加密算法,需要应用服务器也有同样的secretKey才能验证,安全性较差
- 格式:
-
JWT和Cookie&Session的区别
- 两者一个是服务端session,一个是客户端session
-
JWT的好处:
- 避免了cookie跨域的麻烦
- 现代动态加速往往会有多个域名
- 无状态,避免了每次去数据库(或者redis)验证session
- 特别是服务器数量特别多的时候,数据库负载很大
- 每次都要验证的网络IO消耗比公钥验证的CPU消耗大很多
- 避免了cookie跨域的麻烦
-
JWT的弊端:
- 服务后台无法拒绝携带JWT的请求(除非加上黑名单机制,但这样又有状态了)
- 服务器端没法统计多少个人登录了,一个人登录了多少次,登陆了什么设备
- 无法很好的控制payload的数据量
- 应该只把认证的相关信息放到payload里。但实际上,开发人员往往会误用,把几乎所有和user相关的数据都放到payload里
- 会极大的损耗带宽和IO性能,因为每次请求都必须把全量的JWT都带着
-
客户端发送方式
- 你可以把JWT放在 Cookie 里面自动发送,但是这样不能跨域