在现代应用程序的安全认证体系中,特别是在使用 OAuth 2.0 这样的授权框架时,Access Token (访问令牌) 和 Refresh Token (刷新令牌) 是两个核心且经常被同时提及的概念。 [10] 它们协同工作,旨在平衡安全性与用户体验,但它们各自的角色、生命周期和使用方式有着本质的区别。 [6, 7]
可以把它想象成一把进入特定房间的“钥匙”。客户端(例如你的手机应用)每次需要访问受保护的资源(如你的个人信息、好友列表等)时,都必须出示这把“钥匙”。 [8]
可以把它看作是一张能“换取新钥匙”的长期凭证。当你的“房间钥匙”(Access Token)过期后,你不需要重新进行完整的登录流程,而是用这张凭证去换一把新的钥匙。 [1, 6]
Access Token 和 Refresh Token 的协同工作流程是 OAuth 2.0 框架中实现持久化登录和保障安全的关键。这个流程旨在最大化用户便利性(避免重复登录)的同时,最小化安全风险。 [6]
Access Token
和一个长期的 Refresh Token
给客户端。 [15]Access Token
访问受保护的资源(API)。资源服务器会验证此令牌的有效性。Access Token
过期后,资源服务器会拒绝访问并返回错误(例如 HTTP 401 Unauthorized)。Refresh Token
发送给授权服务器的一个特定端点(Token Endpoint)。Refresh Token
的有效性。如果验证通过,它会签发一个新的 Access Token(有时也会签发一个新的 Refresh Token)并返回给客户端。客户端随后使用新的 Access Token
重新尝试访问资源,流程继续。 [18]正确的令牌存储策略对于应用的安全至关重要。
Access Token
由于其生命周期短且需要频繁使用,通常存储在客户端的内存中(例如,存储在 JavaScript 变量里)。这样可以防止跨站脚本攻击(XSS)直接窃取,因为内存中的数据相对不易被访问。 [12]
Refresh Token
由于其长期有效且权限高,必须得到最严格的保护。在 Web 应用中,最佳实践是将其存储在 HttpOnly、Secure、SameSite 的 Cookie 中。这可以有效防止 XSS 攻击,因为浏览器禁止 JavaScript 访问 HttpOnly Cookie。 [12]
这种双令牌机制的核心安全优势在于显著缩短了高风险令牌(Access Token)的暴露窗口。 [19] 即使 Access Token 被攻击者截获,它也会在很短的时间内失效。而真正有价值的 Refresh Token 则不直接参与与资源服务器的通信,仅在安全的后端通道中与授权服务器进行低频交互,从而大大降低了被盗风险。 [3] 同时,授权服务器可以随时撤销某个 Refresh Token,从而立即使其关联的所有会话失效。 [14]