解决单点登录问题

 在B\S架构中一般是使用cookie加session,但是后面又诞生了JWT

cookie加session认证过程

1. 我们需要再浏览器输入账号密码去进行验证

2. 服务器验证通过以后,相关的数据,如登录时间,用户啥的,都会存储在服务器,保存在session里

3. 然后服务器会向用户返回一个唯一的session ID,同时会把请求保存在cookie里叫做jessionID

4. 当客户端保存了jessionID的时候他就要发起一些请求了,比如说要查询用户的信息,此时会把这个jessionID放在cookie或者header里,然后在向服务端发起查询用户信息的请求

5. 在查询一些需要去鉴权的接口是,需要判断jessionID是否存在,是否合法,验证通过的话,就把信息返回给前端。

        缺陷:

        传统的cookie加session模型最大的问题就是不支持横向扩展,也就是不支持分布式架构,如果要保证高可用,我们需要搭建服务器集群,进行负载均衡的时候,这样就不能保证每一次他都会发在同一台服务器上,这样也就没法验证身份了。现在也有一些分布式session的一些方案,虽然解决了在多台服务器之间不能共享的问题,但是这样依赖性太强了,如果我们这台redis服务器崩了,会导致整个集群,前端用户都访问不了。

JWT认证过程

        JWT是一种无状态的token,简单的可以把无状态理解为服务端不会保存任何会话数据,也就不会保存这个sessionID,他把数据存在了JWT中。

1. JWT认证过程 : 第一步发送登录请求,输入账号密码去进行验证

2. 此时服务器不会在本机保存任何信息,账号密码验证通过,他就会去创建一个无状态的token,然后把这个token(JWT)返回给浏览器

3. 浏览器拿到这个token就会发起其他的请求,假设他要请求用户信息,那么他会在请求头中携带这个token(JWT)来发送请求

4. 服务器在收到这个请求后,他只需要去解析这个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等这种情况。