微服务架构,单点登录,token实现流程

1 篇文章 0 订阅
1 篇文章 0 订阅

分析需求:

  1. 进行前台页面登录,携带账号,密码等知识因子
  2. 身份验证,生成tiken
  3. token保存到cookie中携带
  4. 跳转首页面,根据需求使用token获取信息,存入cookie

流程实现

  1. 确定前端入口
  2. 创建页面
  3. 创建前端api接口方法
  4. 登陆页面实现登录操作
    4.1. 调用api接口方法验证用户名,密码
    4.2 验证通过后拿到token字符串
    4.3 token保存到cookie中
    4.4 创建request拦截器,token存入头信息
    4.5 调用api接口方法,用token获取用户信息
    4.6 用户信息存入cookie中,跳转首页
  5. 实现首页面的数据回显
    5.1 从cookie中取出用户信息
    5.2 用户信息赋值给页面展示对象
    5.3 页面根据对象,是否存在,实现数据的回显
    5.4 实现登出操作 清楚cookie中保存的token和用户信息
    在这里插入图片描述

用户登录业务介绍

单一服务模式

早期单一的服务器,用户认证
缺点:单点性能压力大,无法扩展
在这里插入图片描述

SSO(single sign on)模式

在这里插入图片描述
优点 : 用户身份信息独立管理,更好的分布式管理。可以自己扩展安全策略
缺点:认证服务器访问压力大

session广播模式

缺点:出现广播风暴,

cookie+redis 登录方案

缺点:需要引入第三方服务,增加了服务部署的成本

cookie+token 字符串实现单点登录

优点:无状态:token无状态,session有状态
基于标准化:采用标准的JSON Web Token(JWT)
缺点:服务端无法清除登录状态,客户端清楚cookie实现登出状态
占用带宽
在这里插入图片描述

JWT跨域身份验证

传统用户身份验证在这里插入图片描述

Internet服务无法与用户身份验证分开。一般过程如下:

  1. 用户向服务器发送用户名和密码。
  2. 验证服务器后,相关数据(如用户角色,登录时间等)将保存在当前会话中。
  3. 服务器向用户返回session_id,session信息都会写入到用户的Cookie。
  4. 用户的每个后续请求都将通过在Cookie中取出session_id传给服务器。
  5. 服务器收到session_id并对比之前保存的数据,确认用户的身份。

这种模式最大的问题是,没有分布式架构,无法支持横向扩展。
解决方法
6. session广播方式
7. 将透明令牌存入cookie中,将用户信息存入redis
另一种灵活的解决方案:
使用自包含的令牌,通过客户端保存数据,而服务端不保存会话数据,JWT是这种解决方案的代表

JWT令牌

1、访问令牌的类型

在这里插入图片描述

2、JWT的组成

分成三部分:
JWT头

JWT头部分是一个描述JWT元数据的JSON对象,通常如下所示。

{
  "alg": "HS256",
  "typ": "JWT"
}

在上面的代码中,alg属性表示签名使用的算法,默认为HMAC SHA256(写为HS256);typ属性表示令牌的类型,JWT令牌统一写为JWT。最后,使用Base64 URL算法将上述JSON对象转换为字符串保存。

有效载荷

有效载荷部分,是JWT的主体内容部分,也是一个JSON对象,包含需要传递的数据。 JWT指定七个默认字段供选择。

iss:发行人
exp:到期时间
sub:主题
aud:用户
nbf:在此之前不可用
iat:发布时间
jti:JWT ID用于标识该JWT

除以上默认字段外,我们还可以自定义私有字段,如下例:

{
  "sub": "1234567890",
  "name": "Helen",
  "admin": true
}

请注意,默认情况下JWT是未加密的,任何人都可以解读其内容,因此不要构建隐私信息字段,存放保密信息,以防止信息泄露。

JSON对象也使用Base64 URL算法转换为字符串保存。

签名哈希

签名哈希部分是对上面两部分数据签名,通过指定的算法生成哈希,以确保数据不会被篡改。

首先,需要指定一个密码(secret)。该密码仅仅为保存在服务器中,并且不能向用户公开。然后,使用标头中指定的签名算法(默认情况下为HMAC SHA256)根据以下公式生成签名。

HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(claims), secret)

在计算出签名哈希后,JWT头,有效载荷和签名哈希的三个部分组合成一个字符串,每个部分用"."分隔,就构成整个JWT对象。

3、JWT的原则

JWT的原则是在服务器身份验证之后,将生成一个JSON对象并将其发送回用户,如下所示。

{
  "sub": "1234567890",
  "name": "Helen",
  "admin": true
}

之后,当用户与服务器通信时,客户在请求中发回JSON对象。服务器仅依赖于这个JSON对象来标识用户。为了防止用户篡改数据,服务器将在生成对象时添加签名。

服务器不保存任何会话数据,即服务器变为无状态,使其更容易扩展。

4、JWT的用法

客户端接收服务器返回的JWT,将其存储在Cookie或localStorage中。

此后,客户端将在与服务器交互中都会带JWT。如果将它存储在Cookie中,就可以自动发送,但是不会跨域,因此一般是将它放入HTTP请求的Header Authorization字段中。当跨域时,也可以将JWT被放置于POST请求的数据主体中。

5、JWT问题和趋势

  1. JWT不仅可用于认证,还可用于信息交换。善用JWT有助于减少服务器请求数据库的次数。
  2. 生产的token可以包含基本信息,比如id、用户昵称、头像等信息,避免再次查库
  3. 存储在客户端,不占用服务端的内存资源
  4. JWT默认不加密,但可以加密。生成原始令牌后,可以再次对其进行加密。
  5. 当JWT未加密时,一些私密数据无法通过JWT传输。
  6. JWT的最大缺点是服务器不保存会话状态,所以在使用期间不可能取消令牌或更改令牌的权限。也就是说,一旦JWT签发,在有效期内将会一直有效。
  7. JWT本身包含认证信息,token是经过base64编码,所以可以解码,因此token加密前的对象不应该包含敏感信息,一旦信息泄露,任何人都可以获得令牌的所有权限。为了减少盗用,JWT的有效期不宜设置太长。对于某些重要操作,用户在使用时应该每次都进行进行身份验证。
  8. 为了减少盗用和窃取,JWT不建议使用HTTP协议来传输代码,而是使用加密的HTTPS协议进行传输。

OAuth2

解决权限问题的解决方案
第三方授权问题
在这里插入图片描述

什么是OAuth 2.0

在这里插入图片描述

OAuto 2.0 的误解

是授权框架,仅用于授权管理
在这里插入图片描述

  • 1
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值