账户体系（JWT,OAuth,SSO与CAS）

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

• JWT和Cookie&Session的区别

  • 两者一个是服务端session，一个是客户端session

• JWT的好处：

  • 避免了cookie跨域的麻烦
    • 现代动态加速往往会有多个域名
  • 无状态，避免了每次去数据库（或者redis）验证session
    • 特别是服务器数量特别多的时候，数据库负载很大
    • 每次都要验证的网络IO消耗比公钥验证的CPU消耗大很多

• JWT的弊端：

  • 服务后台无法拒绝携带JWT的请求（除非加上黑名单机制，但这样又有状态了）
  • 服务器端没法统计多少个人登录了，一个人登录了多少次，登陆了什么设备
  • 无法很好的控制payload的数据量
    • 应该只把认证的相关信息放到payload里。但实际上，开发人员往往会误用，把几乎所有和user相关的数据都放到payload里
    • 会极大的损耗带宽和IO性能，因为每次请求都必须把全量的JWT都带着

• 客户端发送方式

  • 你可以把JWT放在 Cookie 里面自动发送，但是这样不能跨域
  • 更好的做法是放在 HTTP 请求的头信息Authorization字段里面
    • Authorization: Bearer<token>
  • 或者放在 POST 请求的数据体里面

• 认证流程

  • 用户向认证服务