Token 作为用户获取受保护资源的凭证，必须设置一个过期时间，否则一次登录便可永久使用，认证功能就失去了意义。但是矛盾在于：过期时间设置得太长，用户数据的安全性将大打折扣；过期时间设置得太短，用户就必须每隔一段时间重新登录，以获取新的凭证，这会极大挫伤用户的积极性（即用户体验）。针对这一问题，我们可以利用 Access / Refresh Token 这一概念来平衡 Token 安全性和用户体验。
前言
Token 作为用户获取受保护资源的凭证，必须设置一个过期时间，否则一次登录便可永久使用，认证功能就失去了意义。但是矛盾在于：过期时间设置得太长，用户数据的安全性将大打折扣；过期时间设置得太短，用户就必须每隔一段时间重新登录，以获取新的凭证，这会极大挫伤用户的积极性（即用户体验）。针对这一问题，我们可以利用 Access / Refresh Token 这一概念来平衡 Token 安全性和用户体验。
对于 Access / Refresh Token 的理解
上图表示 Access / Refresh Token 在客户端、认证服务器、资源服务器三者之间的传递关系，简单来说：
Access Token即 “访问令牌”，是客户端向资源服务器换取资源的凭证；Refresh Token即 “刷新令牌”，是客户端向认证服务器换取Access Token的凭证。
使用 Access / Refresh Token 的基本流程
上图表示客户端请求资源的过程中，Access Token 和 Refresh Token 是如何配合使用的：
- 用户提供身份信息（一般是用户名密码），利用客户端向认证服务器换取
Refresh Token和Access Token； - 客户端携带
Access Token访问资源服务器，资源服务器识别Access Token并返回资源； - 当
Access Token过期或失效，客户端再一次访问资源服务器，资源服务器返回 “无效token” 报错； - 客户端通过
Refresh Token向认证服务器换取Access Token，认证服务器返回新的Access Token。
🤪用一个现实生活中的比喻来解释 Access/Refresh Token 的使用过程：
假设我在网上预定了一家酒店。如果要入住这家酒店，我必须出示身份证和订单。酒店前台会登记相关证件和订单信息，确认无误后会给我一张票据和一张房卡（票据记录我需要入住多少天，而房卡则让我有当天的入住权）。
以上场景中，“身份证和订单”是我的用户名密码，“票据/房卡”是 Refresh/Access Token，“前台”是认证服务器，“房间”是资源服务器。
在整个入住过程中，“身份证和订单”只在前台使用一次；实际能进入房间的是“房卡”，但是房卡只有一天的有效期；如果房卡过期，我需要凭“票据”去前台刷新“房卡”，获取第二天的入住权。
使用 Access / Refresh Token 的必要性
或许你到这里有一点点不明白为何使用 Access/Refresh Token 这一组合，那我们先回想一下在没有 Refresh Token 的时候，我们是如何实现 token 鉴权的。
要明白，之前我们常说的 token 都是指向 Access Token，然后需要更新 token 时，就再次使用当前登录账号的用户名和密码向认证服务器发送请求以刷新当前 Access Token（当然这是我以前在我未接触过 Refresh Token 时愚蠢的处理方式）；
而现在有了 Refresh Token 后，那么可以直接通过它主动刷新 Access Token。这样不仅改进了认证服务器的访问模式（降低负载，加快检查速度），同时使得泄漏访问令牌的访问窗口变短（这些访问令牌很快过期，减少了泄露令牌允许访问受保护资源的机会）。
😀最关键的是，将 Token 拆分成两个，就是为了解决安全性和用户体验方面的矛盾：
Access Token使用频繁，且与用户数据直接关联，安全性方面比较敏感，因此有效期设置得较短，即使 Access Token 泄漏也将很快失效。利用过期时间较短这个特性，也可以及时更新用户的访问权限（比如管理员缩小了的某员工访问公司数据的权限，当 Token 过期后换取的新 Access Token 将立马缩小其访问数据的权限）。- 而
Refresh Token仅用于获取新的 Access Token，使用频率较低，不与用户数据直接关联，过期时间允许设置得长一些。这样就解决了用户反复登录的问题。
落地实践上有什么具体的用处？
站在系统管理员的角度，我们很容易想到去管理用户的会话行为。一般来说，可以通过设置 Token 过期时间（被动过期）、设置结束会话的行为、手动结束用户会话（主动下线）这三种方式来管理用户会话。而若对管理员开放自定义会话管理的功能，在提升系统管理员的运维体验上更进一步——让管理员真正“有能力管理”系统发放出去的 Token。
比如会话过期时间设置：
结束会话行为设置：
手动结束用户会话：
小结
综上所述，通过 Access Token 和 Refresh Token 配套使用，我们得以很好的平衡 Token 时效性（安全性）与用户体验二者之间的关系，并利用 Refresh Token 的特点让 IT 系统管理员真正有能力管理系统发放出去的 Token，并实现“点对点”的结束会话操作。
