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

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

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

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

基于 Token 的鉴权方案

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

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

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

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

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

随后：

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

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

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

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

路由守卫基础模式

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

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

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

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

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

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

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

6. ……

于是，我们可以做一个简单的对比（从 1 到 5）：

相应的解释如下：

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

组合鉴权

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

首先，我们有两个后端 API：

前端代码设计（以 Angular 为例）：

1. 鉴权守卫（AuthGuard）。进行 Token 存在验证，和 Token 过期时间验证。

2. 角色守卫（RoleGuard）。进行角色验证

3. HTTP 异常拦截（HTTP Interceptor）。后端返回 401 时，删除 Token 等，并引导用户重新登录。

关键名词解释：

最后，我们的组合模式如下所示：

1. 用户进行普通（诸如自身相关的操作），只验证 Token 是否存在 + 是否在有效期内。

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

3. ……

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

结论

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