前言

大家好，我是CoderBin，本次给大家讲将关于前端鉴权的理解，希望对大家有所帮助，谢谢。
如果文中有不对、疑惑的地方，欢迎在评论区留言指正🌻

什么是鉴权

鉴权也叫身份认证，指验证用户是否有系统的访问权限。就很像我们经常乘坐动车的票据（对应的标识，一定的时间范围）。

认证方式

接下来介绍几种我们工作中通常用到的认证方式。

Session-Cookie 认证

利用服务端的 Session（会话）和浏览器（客户端）的 Cookie 来实现的前后端通信认证模式。

来源

由于 HTTP 请求时是无状态的，服务端正常情况下无法得知请求发送者的身份。这个时候如果我们要记录状态，就需要在服务端创建会话，将相同客户端的请求都维护在各自的会话记录中，每当请求到达服务端时，先校验请求中的用户标识是否存在于 Session 中，如果有则表示已经认证成功，否则表示认证失败。

流程

实践

boss（我们的一个产品） 这边 Session ID 存在数据库里面，在 Memcached 里面做缓存。客户端每次调用接口的时候会通过 response headers 里面的 Set-Cookie 更新过期时间（boss 这边设置的是 6 个小时），这样做的作用是防止你在做一些复杂操作的时候，cookie 突然过期。

⚠️整个过程是比较重的，因为每次的接口调用都得更新过期时间。

优缺点

优点：

• 简单易用，浏览器会自动带上

缺点：

• 脱离浏览器没法用，比如原生应用

关于 Cookie 的安全问题

Cookie 属性：

提高安全性的办法

• Expires/Max-Age 设置合理过期时间
• HttpOnly 设置为 true
• Secure 设置为 true（使用 https）

Token 认证

来源

负载均衡多服务器的情况，不好确认当前用户是否登录，因为多服务器不共享 Session。这个问题也可以将 Session 存在一个服务器中来解决，但是就不能完全达到负载均衡的效果。
Token 和 Session-Cookie 认证方式中的 Session ID 不同，并非只是一个标识符。Token 一般会包含用户的相关信息，通过验证 Token 不仅可以完成身份校验，还可以获取预设的信息。
客户端可以将 token 存放于 localStroage 等容器中。客户端每次访问都传递 token，服务端解密 token，服务端就不需要存储 Session 占用存储空间，就很好的解决负载均衡多服务器的问题了。

流程

实践

平常用的最多的就是 JSON Web Token（JWT），也是目前最流行的跨域身份验证解决方案。

JWT 组成：头部. 载荷. 签名

头部和载荷用 base64 编码

签名计算：

HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload) , secret)

使用方法：

Authorization: Bearer <token>

但是 JWT 有个大缺点是服务器不保存会话状态，所以在使用期间不可能取消令牌或更改令牌的权限。也就是说，一旦 JWT 签发，在有效期内将会一直有效。

⚠️载荷的内容任何人都可以读到，不要放入敏感信息

jwt 存储位置的争论：我觉得如果存储信息多，天然防止 csrf 的话，放到 localStorage 或者 sessionStoraged 都行。

除了 JWT 可以提升 token 的安全性，Refresh token 也可以。

业务接口用来鉴权的 token，我们称之为 access token。越是权限敏感的业务，我们越希望 access token 有效期足够短，以避免被盗用。但是过短的有效期会造成 access token 经常过期，过期后怎么办呢？

一种办法是，让用户重新登录获取新 token，显然不够友好，要知道有的 access token 过期时间可能只有几分钟。

另外一种办法是，再来一个 token，一个专门生成 access token 的 token，我们称为 refresh token。

refresh token 的过期时间一般比较长，比如 6 个小时，access token 的过期时间比较短，比如 10 分钟。我们在实际业务中，api 调用时只传递 access token 进行鉴权。如果 access token 过期，则使用 refresh token 去授权服务器更新 access token。最终 refresh token 也过期了，这时候用户就得重新登陆了。

优缺点

优点：

• 轻量，服务端不用存储，移动端可用

缺点：

• 一旦派发出去，失效之前都是有效的（虽然可以解决，但是就类似于 Session 机制了）

单点登录

来源

但当我们业务线越来越多，就会有更多业务系统分散到不同域名下，就需要「一次登录，全线通用」的能力，叫做「单点登录」。

流程

对浏览器来说，SSO 域下返回的数据要怎么存，才能在访问 A 的时候带上？这就需要也只能由 A 提供 A 域下存储凭证的能力。

实践

OIDC

1. OIDC 登陆点击，重定向到登录的 OpenID 网站
2. 输入用户名密码，如果验证成功。则会重定向到登陆回调（之前设置好的地址）
3. 回调地址里面有个 code 参数，code 验证正确后，下发 sk，boss 系统登陆成功
4. 前端通过添加 iframe 的方式轮询 authing 链接实现单点登出

关于 OIDC

OIDC 是一个 OAuth2 上层的简单身份层协议。它允许客户端验证用户的身份并获取基本的用户配置信息。OIDC 使用 JSON Web Token（JWT）作为信息返回，通过符合 OAuth2 的流程来获取。

关于 OAuth2

OAuth2 最终目的是为第三方应用颁发一个有时效性的令牌 token。使得第三方应用能够通过该令牌获取相关的资源。当你想要登录某个论坛，但没有账号，而这个论坛接入了如 QQ、Facebook 等登录功能，在你使用 QQ 登录的过程中就使用的 OAuth 2.0 协议。

• Client 请求 Resource Owner 的授权。授权请求可以直接向 Resource Owner 请求，也可以通过 Authorization Server 间接的进行。
• Client 获得授权许可。
• Client 向 Authorization Server 请求访问令牌。
• Authorization Server 验证授权许可，如果有效则颁发访问令牌。
• Client 通过访问令牌从 Resource Server 请求受保护资源。
• Resource Server 验证访问令牌，有效则响应请求。

关于 LDAP

LDAP (Light Directory Access Portocol)，中文名轻量目录访问协议，是一个开放、广泛被使用的工业标准。比如我们的 Jira、Confluence、Yapi。

但是 LDAP 并不能做到单点登录 SSO，只是可以用同样的用户名和密码可以登陆不同的系统，但达不到一次登陆之后可以访问多个系统。

Others 认证方式

2FA（双因素认证）

线上的 boss 必须开启二次认证，会生成一个二维码，那个二维码就是一个 SecretKey，通过 CryptoJS.HmacSHA1（默认算法），每次会计算出一个 6 位（默认长度）随机数。计算公式为

⚠️因为默认是 30s 内有效，所以用户手机时间要比较准确

Google 验证器

谷歌身份验证器最早是谷歌为了减少 Gmail 邮箱遭受恶意攻击而推出的两步验证方式，后来被很多网站支持。使用谷歌身份验证器，可以避免比如不久前发生的 Coinbase 短信二次验证导致的安全事故。开启谷歌身份验证之后，登录账户，除了输入用户名和密码，还需要输入谷歌验证器上的动态密码。

谷歌验证器上的动态密码，也称为一次性密码，密码按照时间或使用次数不断动态变化（默认 30 秒变更一次）。它和很多银行发行的动态口令卡类似，可以断网使用，只不过前者是谷歌推出的一个 App，后者是专门的一个硬件。

在手机端生成动态口令后，在Google相关的服务登陆中除了用正常用户名和密码外，需要输入一次动态口令才能验证成功，此举是为了保护用户的信息安全。

与传统单因子密码不同，其采用的是更安全的双因子（2FA two-factor authentication）认证。

FA是指结合密码以及实物（信用卡、SMS手机、令牌或指纹等生物标志）两种条件对用户进行认证的方法。只需要在手机上安装如此高大上的密码生成应用程序，就可以生成一个随着时间变化的一次性密码，用于帐户验证，而且这个应用程序不需要连接网络即可工作。

实际上 Google Authenticator 采用的算法是TOTP（Time-Based One-Time Password基于时间的一次性密码），其核心内容包括以下三点：

• 一个共享密钥（一个比特序列）；
• 当前时间输入；
• 一个签署函数。

每文一句：书山有路勤为径，学海无涯苦作舟。

本次的分享就到这里，如果本章内容对你有所帮助的话欢迎点赞+收藏。文章有不对的地方欢迎指出，有任何疑问都可以在评论区留言。希望大家都能够有所收获，大家一起探讨、进步！