单点登录之如何平衡 Token 安全性和用户体验？

在 《IDaaS 技术解析系列（一）》中，我们介绍了在单点登录中Token认证相对于传统基于Session认证的优势，本文继续介绍一组相关概念：Access Token & Refresh Token。

众所周知，Token作为用户获取受保护资源的凭证，必须设置一个过期时间，否则一次登录便可永久使用，认证功能就失去了意义。但是矛盾在于：过期时间设置得太长，用户数据的安全性将大打折扣；过期时间设置得太短，用户就必须每隔一段时间重新登录，以获取新的凭证，这会极大挫伤用户的积极性。针对这一问题，我们可以利用Access / Refresh Token这一概念来平衡Token安全性和用户体验。

Access / Refresh Token是什么？

图 1

上图表示Access/Refresh Token在客户端、认证服务器、资源服务器三者之间的传递关系，简单来说：

• Access Token即“访问令牌”，是客户端向资源服务器换取资源的凭证；
• Refresh Token即“刷新令牌”，是客户端向认证服务器换取Access Token的凭证。

Access / Refresh Token如何使用？

图 2

上图表示客户端请求资源的过程中，Access Token 和 Refresh Token 是如何配合使用的：1. 用户提供身份信息（一般是用户名密码），利用客户端向认证服务器换取 Refresh Token和Access Token；2. 客户端携带Access Token访问资源服务器，资源服务器识别Access Token并返回资源；3. 当Access Token过期或失效，客户端再一次访问资源服务器，资源服务器返回“无效token”报错；4. 客户端通过Refresh Token向认证服务器换取Access Token，认证服务器返回新的Access Token。

用一个现实生活中的比喻来解释 Access/Refresh Token 的使用过程：假设我在网上预定了一家酒店。如果要入住这家酒店，我必须出示身份相关信息和订单。酒店前台会登记相关信息和订单信息，确认无误后会给我一张票据和一张房卡（票据记录我需要入住多少天，而房卡则让我有当天的入住权）。以上场景中，“身份相关信息和订单”是我的用户名密码，“票据/房卡”是Refresh/Access Token，“前台”是认证服务器，“房间”是资源服务器。

在整个入住过程中，“身份相关信息和订单”只在前台使用一次；实际能进入房间的是“房卡”，但是房卡只有一天的有效期；如果房卡过期，我需要凭“票据”去前台刷新“房卡”，获取第二天的入住权。

将Token拆分成两个，就是为了解决安全性和用户体验方面的矛盾——

• Access Token使用频繁，且与用户数据直接关联，安全性方面比较敏感，因此**有效期设置得较短，即使Access Token泄漏也将很快失效。利用过期时间较短这个特性，也可以及时更新用户的访问权限（比如管理员缩小了的某员工访问公司数据的权限，当Token过期后换取的新Access Token将立马缩小其访问数据的权限）。**
• 而 Refresh Token仅用于获取新的Access Token，使用频率较低，不与用户数据直接关联，过期时间允许设置得长一些。这样就解决了用户反复登录的问题。

实现对用户会话的管理

站在系统管理员的角度，我们很容易想到去管理用户的会话行为。一般来说，可以通过设置Token过期时间、设置结束会话的行为、手动结束用户会话这三种方式来管理用户会话。目前玉符IDaaS在Token标准应用的基础上，为管理员开放了自定义会话管理的功能，在提升系统管理员的运维体验上更进一步——让管理员真正“有能力管理”系统发放出去的Token，比如：会话过期时间设置（如图3）：

结束会话行为设置（如图4）：

手动结束用户会话（如图 5）：

小结

综上所述，通过 Access Token 和 Refresh Token 配套使用，我们得以很好的平衡 Token 时效性（安全性）与用户体验二者之间的关系，并利用 Refresh Token 的特点让 IT 系统管理员真正有能力管理系统发放出去的Token，并实现“点对点”的结束会话操作。

IDaaS 即身份认证管理云平台，它能提供多种标准化功能帮助用户实现高效、安全的身份认证管理服务，如单点登录、智能多因素认证、账号生命周期管理等等。由于 IDaaS 在国内尚属于新兴产品形态，很多人对它只有模糊的印象，所以我们计划用一系列文章，深入浅出介绍 IDaaS 相关的技术原理和细节。 本文是「IDaaS 技术解析系列」文章的第 2 篇。后续我们将继续分享更多技术思考，欢迎关注我们并留言交流。