既生瑜何生亮 access_token VS refresh_token

Posted 2021-12-24 dotNET跨平台

中国有句老话, 既生瑜何生亮, 既然有我周瑜在世, 为什么老天还要一个诸葛亮啊？

同样的, 众所周知, 在 OAuth 2.0 授权协议中, 也有两个令牌 token , 分别是 access_token 和 refresh_token, 为什么已经有了 access_token, 还需要 refresh_token 呢?

我们先看下面两者的介绍

• access_token 访问令牌, 它是一个用来访问受保护资源的凭证

• refresh_token 刷新令牌, 它是一个用来获取access token的凭证

下面是 OAuth 2.0 中的 token 工作流程图

两个令牌的主要区别如下:

• access_token 时效短, refresh_token 时效长, 比如 access_token 有效期1个小时, refresh_token 有效期1天

• access_token 是授权服务器一定颁发的, 而 refresh_token 却是可选的

• access_token 过期后, 可以使用 refresh_token 重新获取, 而 refresh_token 过期后就只能重新授权了, 也没有 refresh_refresh_token

• access_token 和 资源服务器和授权服务器交互, 而 refresh_token 只和授权服务器交互

• access_token 颁发后可以直接使用, 而使用 refresh_token 需要客户端秘钥 client_secret

接下来, 我们继续看两个令牌在下面场景的应用, 假设有一个用户需要在后台管理界面上操作6个小时。

1 颁发一个有效性很长的 access_token, 比如 6 个小时, 或者可以更长, 这样用户只需要刚开始登录一次, access_token 可以一直使用, 直到 access_token 过期, 然后重复, 这种是不安全的, access_token 的时效太长, 也就失去了本身的意义。

2 颁发一个1小时有效期的 access_token, 过期后重新登录授权, 这样用户需要登录 6 次, 安全倒是有了, 但是用户体验极差

3 颁发1小时有效期的 access_token 和6小时有效期的 refresh_token, 当 access_token 过期后（或者快要过期的时候）, 使用 refresh_token 获取一个新的 access_token, 直到 refresh_token 过期, 用户重新登录, 这样整个过程中，用户只需要登录一次, 用户体验好。

access_token 泄露了怎么办? 没关系, 它很快就会过期。
refresh_token 泄露了怎么办? 没关系, 使用 refresh_token 是需要客户端秘钥 client_secret 的。

4 用户登录后, 在后台管理页面上操作1个小时后, 离开了一段时间, 然后 5个小时后, 回到管理页面继续操作, 此时 refresh_token 有效期6个小时, 一直没有过期, 也就可以换取新的 access_token, 用户在这个过程中, 可以不用重复登录。但是在一些安全要求较高的系统中, 第二次操作是需要重新登录的, 即使 refresh_token 没有过期, 因为中间有几个小时, 用户是没有操作的, 系统猜测用户已离开, 并关闭会话。

所以, 得出的结论是, refresh_token 是一个很巧妙地设计, 提升了用户体验的同时, 又保证了安全性。

另外, 在 OAuth 2.0 安全最佳实践中, 推荐 refresh_token 是一次性的, 什么意思呢? 使用 refresh_token 获取 access_token 时, 同时会返回一个 新的 refresh_token, 之前的 refresh_token 就会失效, 但是两个 refresh_token 的绝对过期时间是一样的, 所以不会存在 refresh_token 快过期就获取一个新的, 然后重复，永不过期的情况。  

往期推荐:

OAuth 2.0 的探险之旅

OAuth 2.0 扩展协议之 PKCE

OAuth 2.1 的进化之路

OAuth 2.1 带来了哪些变化