用户登陆验证

1.基于session的用户登陆验证

基本流程

• 登陆成功之后，将sessionId和用户绑定（通常存放在redis中），以后通过sessionId来标识用户
• 服务器端将sessionId利用「Cookie」返回给客户端
• 客户端在以后的请求中都添加这个「Cookie」来进行请求

缺点

• session相关信息存储在服务器，当用户量很大时，会对服务器造成压力
• 有安全隐患，「Cookie」被拦截，会收到请求伪造攻击
• 不利于服务器的「横向扩展」，分布式环境下session需要做多机数据共享

2.基于JWT的用户token登陆验证

JWT（JSON Web Token）基于「token」的用户认证。

基本流程

• 用户输入登录信息，客户端将其密码使用RSA公钥进行加密后，发送post请求给服务器
• 服务器收到请求后进行解密验证用户信息合法性，验证成功后返回服务器生成的用户「token」给客户端
• 客户端收到「token」之后，将其存储在本地（一般存储在localStorage,cookie,sessionStorage）
• 客户端之后的HTTP请求都需要将「token」添加到请求头里边
• 服务器解码JWT，如果用户令牌还在有效期内，则接受请求，否则返回提示信息要求客户端重新获取「token」

优点

• 「token」是无状态的，服务器不需要保存令牌相关信息，不会造成服务器压力
• 可拓展性好，多机只需使用相同的JWT算法即可实现用户认证

缺点

• JWT的载荷（playload）使用base64编码，并没有加密，所以JWT中不能存放敏感数据，安全性对于session来说较低。
• 由于JWT是无状态的，所以相关数据都存放在JWT的载荷之中，导致编码后JWT会很长，可能会超出cookie的大小限制（4K），一般存放在「local stroage」中，并且会导致http请求的开销较大。
• JWT是一次性的，需要控制好「token」的过期时间，避免多次获取「token」（也可以设置双「token」机制来减少用户登陆次数，只要用户「访问token」没用过期，就可以直接生成「用户token」实现用户的无感认证）

3.JWT认证原理

JWT的组成部分

• 头部：描述JWT的最基本信息，如类型、签名所用的算法等
• 载荷（Playload）：存放一些不敏感信息，如该JWT的签发者、面向的用户、过期时间（Unix时间戳）、签发的时间等信息
• 签名：将头部和载荷分别进行base64编码后使用.将两部分拼接在一起，然后使用「头部」中指定的加密算法对拼接得到的字符串进行加密，得到用户「token」。由于消息体是透明的，签名可以保证消息不被篡改。

实例：

token

eyJraWQiOiIyIiwidHlwIjoiSldUIiwiYWxnIjoiUlMyNTYifQ.eyJpc3MiOiLnrb7lj5HogIUiLCJleHAiOjE2NTY2NjY5NTV9.OSifVMWPXGIpZSnQnQmHqfX5owjkFThQTdC1AB2noEvqdjbvYXizOjMzhONTISsllqP34FZn5rmeR5dgmscMXCwXB75i-VfwCa5tf0KiaSfwYYxR-ZzCF4AN8qFikhig3I0oxbEaFde4QB5K4uFuItwIdJaJMnSYLAnt1kLowes

可以通过解密工具解析出头部和载荷信息：