您的位置 首页 java

基于token机制鉴权架构

常见的 鉴权 方式有两种,一种是基于session,另一种是基于token方式的鉴权,我们来浅谈一下两种 鉴权方式的区别。

两种鉴权方式对比

session

  1. 安全性:session是基于 cookie 进行用户识别的,cookie如果被截获,用户很容易受到跨站请求伪造的攻击。
  2. 扩展性:session是有状态的,是具有IP黏贴性和有中心化特性的,在 分布式 环境下,虽然每台服务器业务逻辑一样,但是session是保存在各个服务器中的,而且每个 服务器内存 是不共享的,如果使用session去实现分布式部署的话,需要使用其他的一些技术手段去实现,比如spring session,将session保存在第三方服务中,比如redis,这样一旦第三方服务出现问题,整个验权系统就会奔溃,在电商系统及高并发系统中的集群化处理显然是不合适的。
  3. 抗压能力:通常session是存储在内存中的,每个用户通过认证后都会将session存储在服务器内存中,当用户量增大的情况下服务器的压力也随之增大。

token

  1. 安全性:浏览器会将接收到的token值存储在Local Storage中,(通过js代码写入Local Storage,通过js获取,并不会像cookie一样自动携带)
  2. 扩展性:token是无状态的,是去中心化的,在分布式环境下,各个服务器中的服务只对token进行数据查询,它不需要在服务端保留用户信息或者会话信息,这意味着用户不需要考虑登录的是哪一台服务器,高效的解决了session扩展性的弊端。
  3. 抗压能力:token与session的不同主要在认证成功后,会对当前用户数据进行加密,生成一个加密字符串token,返还给客户端(服务器端并不进行保存)

基于token的鉴权方式

业界常用的授权标准有两种,一种是使用auth2,这种方式更适合于类似第三方授权登录,比如 微信 微博 、QQ信任登录业务。另一种是 oauth ,即第三方无需知道用户和密码就可以申请获得该资源的授权,更适用于对用户的权限校验并分配访问权限,比如常见的登录后分配可见资源(按钮、菜单等)类型网站。

Javashop电商系统 采用的是oauth方式的鉴权标准。我们以系统的应用为例来介绍oauth的方案。

1. 登录

服务端校验密码,成功后返回access_token和refresh_token,客户端记录上述token。

2. 访问API

在访问API之前解析access_token,并且查看是否过期,如果不过 期则请求API,如果过期,则要刷新令牌,在请求API。

3. 刷新token

携带有效期的refresh_token换回有效token,如果refresh_token过期,则需要用户重新登录。

4. 注销

请求注销api,服务器端和客户端应同时删除token的存储。

1. 客户端请求API

携带access_token信息,如果生成环境不会直接携带access_token,会使用加密后的签名校验。祥见以下防重放机制。

2. 获取token

根据环境不同而有不同的获取token方式。

3. 解析token

通过JWT工具将token解析。

4. 由redis读取token

根据uid拼接key读取access_token, 如果不存在这个用户的token说明已经登出。

5. 验证token

判断次token是否属于此uid,判断token是否过期,如果过期则进行以下刷新token的流程。

6. 注入权限

如果token验证成功,根据user信息生成权限注入到spring安全上下文中。

刷新token流程

1. 客户端请求API

携带refresh_token,如果是生产环境不会直接携带refresh_token信息,详见以下防重放攻击。

2. 获取token

根据环境不同而有不同的获取token方式。

3. 解析token

通过JWT工具将token解析。

4. token读取

根据uid拼接key读取出access_token,如果不存在这个用户的token说明用户已经登出。

5. 验证token

判断此token是否属于此uid,判断token是否已经过期,如果过期,则返回refresh_token过期错误,此时用户需要重新登录。

6. 刷新token

如果refresh_token 验证成功,则重新生成access_token和refresh_token,上述有效期以当前时间向后计算,替换此用户在redis中的token,并将token返回给客户端。

防重放机制

一、 参数的读取

1. 在生产环境时,不能直接传递token,而是要传递签名数据,服务器端验签后由Redis中获取签名。

2. 如果是非生产环境,直接由header中读取token。

二、 生产环境传递如下参数

memberid (用户id)

nonce(随机字串,6位)

timestamp(当前时间戳,到秒)

sign= md5( uid+ nonce + timestamp +token )

三、 验证逻辑

1. 验证时间戳

判断时间戳是否起过60s,大于60s则判别为重放功击。

2. 验证nonce

首先验证nonce在 reids中是否存在,如果存在,则判别为重放功击,否则将nonce记录在redis中(key为:”nonce”+uid+”_”+nonce),失效时间为60s。

3. 验证sign

md5( uid+ nonce + timestamp +token ) 验证是签名是否通过。

4. 验证token

通过uid拿到token ,验证逻辑同验权流程。

当然在不同的业务场景下实现方案是多种多样的,仅以此方案抛转引玉,供大家参考。

文章来源:智云一二三科技

文章标题:基于token机制鉴权架构

文章地址:https://www.zhihuclub.com/190663.shtml

关于作者: 智云科技

热门文章

发表回复

您的电子邮箱地址不会被公开。

1条评论

  1. Host Michele Welcome brings her first hand knowledge from 20 years of competing, coaching, and judging across 6 federations in the bodybuilding industry to help you make educated decisions on how to be your best on stage whatever stage that is, have longevity in the sport, and not make mistakes on and off stage that were preventable

网站地图