为什么使用双token实现无感刷新用户认证?

单token机制

认证机制:对与单token的认证机制在我们项目中仅使用一个Access Token的访问令牌进行用户身份认证和授权的方案处理。

不足之处:

  • 安全性较低(因为只有一个token在客户端和服务器端之间进行传递,一目Acess Token被截获或者被泄露,攻击者就会在有效时间内完成模拟用户行为,访问所有受保护资源)
  • 短有效期策略限制无法撒销会话(为了提高安全性access token通常设置的时间是比较短的,然而需要频繁的去获取access token.影响的是用户的体验,尤其是长时间操作或者是后台的服务场景下就会遇到一个瓶矜,而且也无法撤销对应的汇报,如果某个token被盗用了,难以立即撤销这个token的有效性,从而不能立即中断攻击者的访问权限)
  • 无代态刷新问题(若要自动去刷新token维持长期的绘画,单token的机制需要将刷新的逻辑耦合到具体的业务流程当中,这就会增加复杂性和潜在的安全风险)
  • 没有权限细分管理(单一的access token包含所有的授权信息,不易于对不同范文或者是力度的一个资源进行精细化的访问控制)

双Token机制

操作机制:双Token主要包含了AccessToken (访问令牌) 和 RefreshToken (刷新令牌),它的出现就是为了解决单token的不足,所以才会引入双token的机制也就是 RefreshToken (刷新令牌),因为它可以延长实际的绘画时间,用户提供了一种安全的方式来去更新AccessToken,并且在必要的时候撤销特定用户的权限,而并不会影响有效的绘画内容。

实时上双token的机制是 o os 2.0标准中常见的一种实现,主要包含两个类型的token,一个是AccessToken (访问令牌) ,一个是RefreshToken (刷新令牌)

AccessToken (访问令牌):它会设置一个有效时间较短的令牌内容,用于的是用户每次请求受保护资源时,进行身份验证的操作,通常直接包含在api请求头或者是URL地址参数之中,用于证明客户端其实是有权限去访问特定的资源的

RefreshToken (刷新令牌):刷新令牌,会设置一个有效时间比较长并且安全存储比较高的一个令牌,主要用于AccessToken过期了以后,去重新获取AccessToken的操作内容。我们并不需要用户去提供一个特殊的登录凭证。因为RefreshToken 一般不会频繁的在网络上进行传输,目的就是为了降低被截取的一个风险


双token有很多优势:

  • 安全性提升(因为AccessToken和RefreshToken其实是会被分离的,即使AccessToken被盗用了,但是由于有效时间是比较短的,损失还是可以控制的,同时RefreshToken的安全性则会变的更高,一般还不暴露在网络的传输过程当中,攻击者其实很难窃取到AccessToken长期的有效访问权限)
  • 用户体验优化(RefreshToken可以实现无感知的token刷新,也就是我们所说的无感刷新,因为当AccessToken失效的时候,客户端就会自动去刷新AccessToken,利用的就是RefreshToken,用户并不需要进行一个重新的登录,从而保证操作的连贯性)
  • 权限控制灵活(而且双token机制还有很好的权限控制灵活性,可以通过控制RefreshToken的有效期,刷新次数等方式来灵活的管理用户的绘画生命周期,并且在必要的时候去撤销RefreshToken的内容从而终止后续所以AccessToken的一个访问生成)

双token流程

用户登录(主要是用户通过用户名或者是用户码或者其他凭证向服务器去进行访问)----> 

验证通过?(验证我们的一个身份,然后服务器,将会设置一个请求授权)---->

颁发Access Token & Refresh Token(当认证成功了以后,颁发两个内容,一个是Access Token 另一个 Refresh Token,Access Token是一个短期的token(比如几十分钟),Refresh Token是一个长期的token(比如可以设置几天或者更长的时间),这两个token都会返回客户端)----->

客户端存储tokens(并且客户端会进行对应的存储)--->

客户端使用Access Token访问受保护资源(查看Access Token是否已经有过期的风险,当Access Token即将或者已经过期了后,客户端用Refresh Token向服务器发送一个新的请求,获取新的Access Token,服务器验证Refresh Token有效,如Refresh Token有效就会颁发一个新的Access Token,当然在此过程中有两种不同的情况,一种是并不会刷新Refresh Token还有一种在申请Access Token的时候还可能会重新生成Refresh Token,那么这两个token的有效期时间会从当前的时间段往回深延,具体的选择需要根据实际的业务情况进行策略的抉择)--->

客户端更新存储的tokens(客户端接收到新的Access Token以后则需要替换原来的Access Token,并且在新访问的时候则使用新的token进行一个访问)

应用场景:

实时上双token我们可以应用到,单点登录,移动应用或者是web网站应用当中,或者是第三方授权操作处理等

注意事项:

Refresh Token安全的存储,需要去确定客户端确保Refresh Token在本地实现更为安全的存储操作,需要去避免被泄露,被篡改,而且对应Refresh Token需要去实时更为合理的生命周期管理和失效的策略,包括并且不限于我们响应的倒退时间还得去考虑何时更新或者是废除Refresh Token,我们需要考虑并发的处理,防止同一个Refresh Token在同一时刻被多次刷新Access Token,目的就是为了防止我们的攻击行为,那么当用户进行系统退出的时候,注销的不光是Access Token还得将Refresh Token也进行一个一统删除,确保用户在进行后续操作的时候无法在获得最新的一个授权,那么对于访问的限制,Refresh Token相关接口应该收到一个严格的控制,仅限于可性的客户端才能进行对应的访问处理

相关推荐

  1. 前端实现token刷新技术方案

    2024-01-17 22:16:02       46 阅读
  2. 刷新token

    2024-01-17 22:16:02       45 阅读
  3. token刷新

    2024-01-17 22:16:02       32 阅读
  4. token刷新

    2024-01-17 22:16:02       26 阅读
  5. token刷新方法

    2024-01-17 22:16:02       30 阅读
  6. 前端实现token刷新的原因和步骤

    2024-01-17 22:16:02       53 阅读

最近更新

  1. docker php8.1+nginx base 镜像 dockerfile 配置

    2024-01-17 22:16:02       94 阅读
  2. Could not load dynamic library ‘cudart64_100.dll‘

    2024-01-17 22:16:02       100 阅读
  3. 在Django里面运行非项目文件

    2024-01-17 22:16:02       82 阅读
  4. Python语言-面向对象

    2024-01-17 22:16:02       91 阅读

热门阅读

  1. 每日coding

    2024-01-17 22:16:02       59 阅读
  2. LeetCode 37. 解数独

    2024-01-17 22:16:02       57 阅读
  3. 基于stm32的智能衣柜系统设计(毕业设计)

    2024-01-17 22:16:02       53 阅读
  4. GoLang刷题之leetcode

    2024-01-17 22:16:02       50 阅读
  5. 用Python做数据分析之生成数据表

    2024-01-17 22:16:02       48 阅读
  6. openssl3.2 - 官方demo学习 - signature - rsa_pss_hash.c

    2024-01-17 22:16:02       48 阅读
  7. ssl解码

    2024-01-17 22:16:02       54 阅读
  8. Git远程仓库

    2024-01-17 22:16:02       55 阅读
  9. c语言基础知识

    2024-01-17 22:16:02       56 阅读
  10. python

    2024-01-17 22:16:02       57 阅读
  11. 深入探讨 Go 语言中的 Map 类型

    2024-01-17 22:16:02       52 阅读
  12. zabbix

    zabbix

    2024-01-17 22:16:02      38 阅读