您好,登录后才能下订单哦!
今天就跟大家聊聊有关如何平衡Token安全性和用户体验,可能很多人都不太了解,为了让大家更加了解,小编给大家总结了以下内容,希望大家根据这篇文章可以有所收获。
下面继续介绍一组相关概念:Access Token & Refresh Token。
众所周知,Token作为用户获取受保护资源的凭证,必须设置一个过期时间,否则一次登录便可永久使用,认证功能就失去了意义。但是矛盾在于:过期时间设置得太长,用户数据的安全性将大打折扣;过期时间设置得太短,用户就必须每隔一段时间重新登录,以获取新的凭证,这会极大挫伤用户的积极性。针对这一问题,我们可以利用Access / Refresh Token这一概念来平衡Token安全性和用户体验。
图 1
上图表示Access/Refresh Token在客户端、认证服务器、资源服务器三者之间的传递关系,简单来说:
Access Token即“访问令牌”,是客户端向资源服务器换取资源的凭证;
Refresh Token即“刷新令牌”,是客户端向认证服务器换取Access 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):
图 3结束会话行为设置(如图4):
图 4手动结束用户会话(如图 5):
图 5
综上所述,通过 Access Token 和 Refresh Token 配套使用,我们得以很好的平衡 Token 时效性(安全性)与用户体验二者之间的关系,并利用 Refresh Token 的特点让 IT 系统管理员真正有能力管理系统发放出去的Token,并实现“点对点”的结束会话操作。IDaaS(Identity as a Service)即身份认证管理云平台,它能提供多种标准化功能帮助用户实现高效、安全的身份认证管理服务,如单点登录、智能多因素认证、账号生命周期管理等等。
看完上述内容,你们对如何平衡Token安全性和用户体验有进一步的了解吗?如果还想了解更多知识或者相关内容,请关注亿速云行业资讯频道,感谢大家的支持。
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。