用户认证机制

关于用户认证

• 一般在传统的认证中，由于Http是无状态的，所以都是采用session的机制，当用户登录后服务端存有一个session,而后将sessionid给与客户端，客户端将sessionid存储在cookie中，每次请求都会携带sessionid
• 服务端一般验证客户端是否带有sessionid,然后通过sessionid查找内存中的sessison，如果找到对应的session。再将session绑定的数据取出做校验，例如是否有用户的信息
  • 
  • 
• 由于所有信息由服务端持有，随着用户增多，session的开销就越大，且每个session的持续时间是最终活动时间+时限(列如Tomcat默认的30分钟)
• 当业务规模扩大，用户持续增多。单节点环境势必无法满足当前的需求，这时一般通过负载均衡来横向的扩展软件的服务能力。这时候session就会出现问题，因为每台服务的session都是唯一独有的。
• 这种情况下就引入了session共享机制，就是将session不存储在每台服务的内存中，而通过其他容器、组件存储。所有的服务的session生成、更新都记录在独立的组件或者容器内.比如存储在数据库(Oracle、Mysql)或者内存中(Redis)

关于JWT

• JWT 全称是Json Web Token
• JWT的原则是在服务端身份验证通过之后,生一个包含信息的加密字符串令牌给到客户端,身份信息由客户端持有
• jwt令牌如下
  • 
• JWT分为三部分，JWT头,有效载荷,签名 获取到的令牌。三部分均为JSON对象
  • 头部保存签名使用的算法,以及令牌类型
  • 有效载荷也是JWT的主体内容，包含需要传递的数据
    • iss: 发行人
    • exp: 到期时间
    • sub: 主题
    • aud: 受众
    • nbf: 开始生效时间
    • iat: 发布时间
    • jti: JWT标识
  • 签名通过的算法生成的哈希密钥，确保令牌无法被解析或者篡改
    • 密钥的解析密码不会跟随令牌进行传递,只存储在服务端
• 当三部分完成后通过签名组合一个字符串，每个部分用"."分割,就构成了完整的JWT对象

无状态下的认证机制

• 就如上面对JWT介绍的那样,用户的认证不再依赖服务端持有信息，而是将身份令牌交由客户端(浏览器、移动端、其他公司或者部门)持有。
• 这样每次的校验就无需再次校验用户是否登录，而是校验是否有令牌，令牌是否已生效或者过期。具体的方式如下图
• 

JWT的缺点

• 由于令牌机制下，信息由客户端持有。所以令牌中不应当有隐私或者敏感信息。例如:密码，身份证号等
• JWT默认是不加密的，额外的加密/解析会牺牲一部分的性能
• 由于不再使用session来保存会话,所以如何回收令牌就变得具有挑战性。因为令牌一旦签发，将会在有效期内一直有效
  • 比如系统需要使某个用户失效或者停用，在该用户的令牌失效前用户持有的令牌是无法回收的，虽然通过技术手段可以由服务端向客户端发送消息删除令牌，但是如果用户通过技术手段获取令牌然后存储在别处。然后将请求中的令牌替换，这样仍然可以使用没有回收的令牌来访问系统接口
  • 在这种情况下就要考虑令牌的回收机制，一般情况下会牺牲性能做二次校验
• 由于JWT在网络中传输，在不安全的网络中很容易被窃取和盗用。所以尽量在加密的HTTPS协议下传输

转载于:https://my.oschina.net/shadowli/blog/3046006