鉴权:用户体验与安全的平衡艺术

鉴权,是指验证用户是否拥有访问系统的权利。它是一个系统的重要组成部分,只是我好像从来没有写过相关的文章。于是,于是,最近手不怎么疼,又刚好有几个项目有相关的问题。讨论了多次之后,我发现鉴权简直称得上是一门艺术。

不过,在开始之前,我不得不声明一下这里的场景:

Token 鉴权

单页面应用

传统的 Cookie-Session 的方式,并不需要这样的方式。

基于 Token 的鉴权方案

通用的基于 Token 的鉴权方案,大致步骤如下所示:

客户端将用户名和密码等信息,发送到服务端。

服务端验证生成 Token,并以 Token 作为 Key,存储到数据库中,并返回 Token 给前端。

前端存储 Token 到前端『数据库』中。

需要注意的是,对于那些对安全要求高的系统而言,前端所需要提供的参数,不限于用户名和密码,还要有地理位置、设备相关信息等参数。

随后:

前端在每个请求中,带个授权相关的信息。

后端校验前端的 Token 是否有效,再返回给前端相应的结果。

前端处理后端返回的结果。一旦鉴权失败,则删除 Token,调用登录逻辑。

好像没的毛病,大家都是这么做的,那么到底哪来的平衡艺术?

路由守卫基础模式

前端是以路由作为边界,来划分不同领域的。也因此,在用户进行每一个路由点击之前, 系统需要对用户是否有权限进行判断。若是用户有权限,便继续访问;若是用户没有权限,那么就返回 401,并重新登录。

基于这种鉴权模式,我们会有多种多样的路由守卫方式。在执行路由跳转时,存在这么一些基础的模式:

提交时验证。这样的系统,可能是不存在的,但是我不确定。

Token 存在验证。只验证 Token 是存在的,懂技术的用户可以修改,但是后果自负(无非就是数据丢失 + 重定向)。

关键步骤二次验证。先验证是否存在 Token,随后在进行一些重要的操作之前,先进行 Token 有效性验证,再进行路由跳转。

每步二次验证。即每次在路由跳转时先进行验证,再决定是否跳转。同理于刷新页面的情形。

跳转后二次验证。先跳转到页面上,再进行二次验证。

……

于是,我们可以做一个简单的对比(从 1 到 5):

相应的解释如下:

提交时验证。提交后再告诉用户授权失败,会导致数据丢失。或者额外的前端持久化数据,而每个持久化都会带来额外的工作量。

Token 存在验证。当用户(开发人员)修改 Token 或者 Role 时,他/她可以访问一些不应该看到的页面。

关键步骤二次验证。额外的后台 API,以及关键步骤的设计。

每步验证。每次跳转时,都需要等待时间,并访问后台API——会对性能造成影响。

跳转后验证。减少等待时间,但是还存在大量的后台接口访问。

对于不同的场景,都可以采用不同的方案。又或者是组合出自己需求的方案。

组合鉴权

回到我们的故事上,我们采用的是第二种方案:关键步骤二次验证

首先,我们有两个后端 API:

登录鉴权 API。返回 Token 和用户信息,以及 Token 的过期时间。

Token 有效性 API。返回用户信息,以及 Token 的过期时间。

前端代码设计(以 Angular 为例):

鉴权守卫(AuthGuard)。进行 Token 存在验证,和 Token 过期时间验证。

角色守卫(RoleGuard)。进行角色验证

HTTP 异常拦截(HTTP Interceptor)。后端返回 401 时,删除 Token 等,并引导用户重新登录。

关键名词解释:

Token 存在验证。在本地的浏览器里存在 Token 时,便是认证通过。

Token 有效期验证。将本地的 Token 生成时间,与本地时间进行对比,如果不过期,则是有效的。

Token 有效性验证。发送请求到后端,看 Token 是否有效,更刷新用户角色。

最后,我们的组合模式如下所示:

用户进行普通(诸如自身相关的操作),只验证 Token 是否存在 + 是否在有效期内。

在用户进行部分关键操作(诸如角色绑定菜单)之前,先进行 Token 有效性验证,随后刷新本地的用户角色。

……

反正,后端会进行一系列的权限校验,不是吗?

结论

平衡,真的是是一门艺术。

  • 发表于:
  • 原文链接:https://kuaibao.qq.com/s/20190522A0OVVL00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。

扫码关注云+社区

领取腾讯云代金券