在B\S架构中一般是使用cookie加session,但是后面又诞生了JWT
cookie加session认证过程
-
我们需要再浏览器输入账号密码去进行验证
-
服务器验证通过以后,相关的数据,如登录时间,用户啥的,都会存储在服务器,保存在session里
-
然后服务器会向用户返回一个唯一的session ID,同时会把请求保存在cookie里叫做jessionID
-
当客户端保存了jessionID的时候他就要发起一些请求了,比如说要查询用户的信息,此时会把这个jessionID放在cookie或者header里,然后在向服务端发起查询用户信息的请求
-
在查询一些需要去鉴权的接口是,需要判断jessionID是否存在,是否合法,验证通过的话,就把信息返回给前端。
缺陷:
传统的cookie加session模型最大的问题就是不支持横向扩展,也就是不支持分布式架构,如果要保证高可用,我们需要搭建服务器集群,进行负载均衡的时候,这样就不能保证每一次他都会发在同一台服务器上,这样也就没法验证身份了。现在也有一些分布式session的一些方案,虽然解决了在多台服务器之间不能共享的问题,但是这样依赖性太强了,如果我们这台redis服务器崩了,会导致整个集群,前端用户都访问不了。
JWT认证过程
JWT是一种无状态的token,简单的可以把无状态理解为服务端不会保存任何会话数据,也就不会保存这个sessionID,他把数据存在了JWT中。
-
JWT认证过程 : 第一步发送登录请求,输入账号密码去进行验证
-
此时服务器不会在本机保存任何信息,账号密码验证通过,他就会去创建一个无状态的token,然后把这个token(JWT)返回给浏览器
-
浏览器拿到这个token就会发起其他的请求,假设他要请求用户信息,那么他会在请求头中携带这个token(JWT)来发送请求
-
服务器在收到这个请求后,他只需要去解析这个token,当校验通过,服务器会把用户信息返回给浏览器。
缺陷:
1 、服务器不会保存会话状态
2、不能去传递一些敏感信息,虽然不会被篡改,但是可以解密
3、会有一个更大的空间占用。
JWT的数据结构
JWT(JSON Web Token),具体分为三个部分
header 头部 | 有两个参数: alg:"HS256"(表明这个签名使用的算法是什么) typ:"JWT"(令牌的类型) |
payload 荷载 | 默认有七个字段: "发行人"(企业名称)"到期时间"(token的到期时间)"主题"(存一些交互的东西)"用户"(存一些用户的ID)"在某个时间前不可用"(可以设置一个预发布的时间,也就是生效时间)"发布时间""JWT ID用于表示该JWT",我们也可以去自定义字段,想去存什么都行。 |
signature 签名 | 签名部分,是对前两部分的数据签名,通过指定的算法生成哈希来确保数据不会被篡改 |
总结:
我们在整个web应用当中,不能把JWT当成session来使用,在很多情况下,传统的cookie加session也能工作的很好,JWT适合的场景就是一次性的命令认证,比如去颁发一个有效期非常短的token等这种情况。