引言

对于IAM系统，它的主要功能的设计会体现在设计文档和项目描述中，但依然存在一些小的技术细节，可能无关乎项目的主要功能和目标，但是我仍然觉得十分有意义，为了不让它们被遗失或遗忘，我决定单独用一篇博客把它们汇总起来

DTO设计-控制面认证使用Access Token和Refresh Token双Token

我先前对于账户登录控制鲜有思考，具体的实现也都是一笔带过，并不考虑安全性，而是直接完成登录认证的核心功能。

而这个双Token的设计则是实现了安全性的飞跃的同时兼顾了运行效率

我们来一步步引入双Token机制

不用token会怎么样

我们就需要在前端登录后，由前端自己保存用户的账号密码，每次发送带权限的请求都需要附加账户密码字段，由服务器验证权限，这就导致了账户密码频繁通过互联网传输，曝光度过高，同时服务器也需要反复查询账户密码用于验证，降低效率。

小结：

  • 安全性：差，因为敏感信息曝光度过高，泄漏后造成的影响也很大
  • 效率： 差，因为需要反复查询用户账户数据

使用一个toekn会怎样

使用Token机制后，直接解决了账户密码的曝光度过高问题和服务器需要反复查询的问题，因为Token相对较短，可以缓存在内存中查询。

但是Token会面临安全性和性能考量:

  • 过期时间过长：一旦泄漏就会是长时间的权限泄漏
  • 过期时间过短： 用户需要频繁重新登录

使用两个Token用于改进

为此我们:

  • 将权限功能交给Access Token管理
  • 将过期时间功能交给Refresh Token管理

这样就能 一定程度上解决单Token的问题，它们两个token的职责如下:

AccessToken 的角色

  • 高频使用
  • 每次 API 请求都带
  • 权限校验靠它

典型特征

属性 值
有效期 很短（10–30 分钟）
使用场景 所有受保护 API
泄露影响 有限
存储位置 内存 / Header 
1
Authorization: Bearer <access_token>

RefreshToken 的角色

  • 低频使用
  • 只在 AccessToken 过期时用
  • 换新的 AccessToken

典型特征

属性 值
有效期 长（7–30 天）
使用场景 /auth/refresh
泄露影响 可控（可吊销）
存储位置 更安全（HttpOnly Cookie / 安全存储）