SSang

说到这里，我就想起来一个比较经典的密码学问题。

安全的密码要求人在不同系统使用不同的密码，并且要有高复杂度，这本是好事，但由于系统太多，密码太复杂，没法记清楚，于是大多数用于选择将密码写在便利贴上，以方便登录时候能快速获取密码。然后便利贴被盗了。

@IvanLi127 是的，长期 token 一定更不安全，但是确实有使用场景，比如 git 上面我想要每次发版本时候自动获取项目的一些信息，就得调用 api ，如果只有短期 token ，用户很有可能会把账号密码直接存储下来自动获取 token ，这就不是我们想看到的结果了。

要相对安全点就是得用 api token ，可以申请一个范围很小的，比如只能读项目信息的 token ，相对来说，泄漏后造成的损失也就比较小了。方便和安全之中总要取得某些平衡。

@SSang 嗯，不如说，是用了 json 格式的 token ，实际上不用来做 JWT 的无状态校验。

@Chad0000

嗯，感觉纠结半天还是用回了 JWT 。

上次有个有个帖子有人说 JWT 存有状态就是 ** 我还给他点了个赞。（笑哭）

@Chad0000

我比较核心的使用场景是，用于 CI 中调用，或用于命令行脚本调用。这种场景，比如 CI 这种无交互的就不能用户登录，必须提前把 token 配进去，然后他的有效期一般都是以年为单位的，甚至有些低权限的是永久有效期。

这种场景感觉用 refresh token 就有点奇怪，一是因为我用命令行实际上不好存 access_token ，如果是 CI 里面，存缓存也有点奇怪。二是定时任务往往超过 access_token 的有效期，比如每个月只执行一次的任务，相当于每次我其实都是拿 refresh_token 去请求，和 access_token 就没关系了。

@3dwelcome

> 你是怕 token 时间太长泄露吗？我个人觉得问题不大，后台都是可以控制的。

不是，我是觉得 refresh_token + access_token 的使用场景，一般适用于相对短期的认证，比如比较主流的 oauth 、oidc 就是用户先通过用户密码登录，然后服务端返回 refresh_token 和 access_token ，当 access_token 过期时，拿 refresh_token 刷新。和 git 上面的 用户令牌 是由用户申请，之后直接拿 token 访问 api 不太相同。

> 类似 B 站的 cookie, 接近一年前的我都还在用，也没啥问题。

这种隐私性不高的页面一般确实长时间持有 token 也问题不大，但是比较敏感的，比如 阿里云的后台，AWS 的后台界面，这种，他们就不会长时间持有 token （没记错的话他们两个的有效期都是 18 小时）

@3dwelcome 那这种就是数据库存 token 的 hash 值了吗，比如像 gitlab 还有 personal_access_token 他可以创建好多个，那登录时候，如果有加随机盐，就得一个一个地取盐然后 hash 校验，这个索引效率就很低了。

@Chad0000 确实，OAuth 就是这么设计的，但实际上这个 RefreshToken 的有效期也不会很长，比如默认是 30 天，像 gitlab 、github 的 token 往往有 90 天，180 天，甚至是永久有效期。所以感觉实际设计时候不太能用这种方式。

然后其实我想讨论的就是这个 Refresh Token 要怎么存，要不要带用户信息，如果不带如何索引等。这个比较纠结，其实如果能想明白这个，我就不纠结用不用 Refresh Token 了