前端鉴权的10种方式

鉴权

鉴权(Authentication) 在信息安全领域是指对于一个声明者所声明的身份权利，对其所声明的真实性进行鉴别确认的过程。

在it领域：校验session、cookie、token的合法性和有效性。

1、HTTP鉴权

允许客户端在请求时，通过用户名+密码的方式，实现对用户身份的验证。

⚠️注意：几乎所有的网站都不会走该认证方案，看看就好

过程

1. 客户端向服务器请求一个受限的数据
2. 服务器返回 HTTP/401 Unauthorized
3. 客户端弹窗询问用户
4. 客户端携带Base64格式的用户名+密码再次向服务器发送请求
5. 服务端进行身份验证
6. 校验成功，服务端返回状态码200给客户端（或校验失败，返回状态码403给客户端）

优点

• 简单，基本的浏览器都支持

缺点

• 不安全：基于HTTP传输，几乎是裸奔的，而且Base64解码也很容易
• 无法主动注销：HTTP协议没有提供机制清楚浏览器中的Basic认证信息，除非关闭标签页、浏览器、清除历史记录

使用场景

• 内部网络
• 对安全要求不是很高的网络

2、Session-Cookie鉴权

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

何为Cookie？

为了让服务器区分不同的客户端，用Cookie告知服务器前后两个请求是否来自同一浏览器。

特点：

1. Cookie存储在客户端，可随意修改，不安全
2. 最大为4kb
3. 有数量限制，对于一个网站不能超过20个Cookie，浏览器一般能存300个Cookie
4. Cookie是不可跨域的，但是一级域名和二级域名是可以共享的（domain）

何为Session？

Session的抽象概念是会话，是无状态协议通信过程中，为了实现中断/继续操作，将用户和服务器之间的交互进行的一种抽象。

过程：

1. 客户端：用户向服务器首次发请求
2. 服务器：接受到数据并自动为该用户创建特定的Session/Session ID，来识别用户并跟踪该用户的会话过程
3. 客户端：浏览器收到相应获取会话信息，并在下一次请求时带上Session/Session ID
4. 服务器：服务器提取后会与本地保存的Session/Session ID进行对比找到该特定用户的会话，然后获取会话状态
5. 至此客户端与服务器的通信变成有状态的通信

特点：

1. Session保存在服务器
2. 通过服务器自动的加密协议进行

与Cookie的差异：

1. Session的安全性优于Cookie：因为Cookie存在客户端可以被篡改，而Session存在服务器，无法伪造
2. 大小不同：Cookie的大小不超过4k
3. 有效期不同：Cookie可设置为长时间保存，Session一般失效时间较短
4. 存取值的类型不同：Cookie只支持字符串数据，Session可以存放任意数据类型

Session-Cookie鉴权过程

1. 客户端：发送登录信息（用户名+密码）至服务器
2. 服务器：校验用户名+密码
3. 服务器：通过校验后生成Session ID，并保存在Session服务器中
4. 服务器：返回数据给客户端，并Set-Cookie:PHPSESSID=sid
5. 客户端：携带Cookie，向服务器请求资源
6. 服务器：通过Session服务器校验Session
7. Session服务器：校验成功
8. 服务器：接口处理数据
9. 服务器：返回正确的数据给客户端

Session-Cookie 的优点

• Cookie简单
• Session存在服务器，相较于JWT方便进行管理
• 只需后端操作，前端无感

Session-Cookie 的缺点

• 依赖Cookie，一旦浏览器禁用Cookie，就无法后续操作了
• 不安全，Cookie暴露在浏览器中，容易被盗用、CSRF攻击
• Session存粗在服务器，增大了服务器开销，用户量大的时候会降低性能

3、Token鉴权

Session-Cookie 的一些缺点，以及Session的维护给服务器造成的压力。然后我们又必须找个地方存放它，Token应运而生。

何为Token？

Token是一个令牌，客户端访问服务器时，验证通过后服务端会为其签发一张令牌，之后，客户端就可以携带令牌访问服务器，服务端只需言验证令牌的有效性即可。

Token的组成：

uid（用户唯一身份标识）+ time（当前的时间戳）+ sign（签名，token的前几位以hash算法压缩成的一定长度的十六进制字符串）

Token认证过程

1. 客户端发送登录信息（用户名+密码）给服务器
2. 服务器校验登录信息，生成一个加密的Token令牌，返回给客户端
3. 客户端获取Token后，保存至本地
4. 客户端再次请求API数据时，携带Token至服务器
5. 服务器拿到Token后，做解密和签名校验
6. 校验成功，服务器返回数据给客户端

Token的优点

• 服务端无状态化、可扩展性好：Token机制在服务器不需要存储Session信息，本身就已包含了用户的相关信息
• 安全性好：避免CSRF
• 支持跨域访问

Token的缺点

• 配合：需要前后端配合
• 占带宽：正常情况下比sid更大，消耗更多流量，挤占更多带宽
• 性能：需要加密解密Token，所以更耗性能
• 有效期短：为了避免盗用，一般设置的有效期较短

由于Token有效期较短，所以就有了Refresh Token（刷新Token）

何为Refresh Token？

Token过期了，让用户重新登录获取Token会很麻烦，这个时候一个专门生成Access Token的Token就诞生了。Refresh Token的有效期可以长一些，通过独立服务和严格的请求方式增加安全性。由于不常验证，也可以如签名的Session一样处理。

Refresh Token认证过程

1. 客户端：用户名+密码请求登录校验
2. 服务器：收到请求，校验登录信息，成功后返回Access Token + Refresh Token 给客户端
3. 客户端：将收到的Access Token + Refresh Toke存储在本地；再次请求API数据时，携带Access Token给服务器
4. 服务器：验证Access Token有效：返回正常数据（无效：拒绝请求）
5. 客户端Access Token过期：则重新传输Refresh Token给服务器
6. 服务器Access Token过期：验证Refresh Token成功后，返回新Access Token给客户端
7. 客户端：重新携带新的Access Token请求API

Token和Session-Cookie的区别

Token更像Session-Cookie的改良升级版

• 存储地不同：Session存在服务器；Token无状态的，一般前端来存储
• 安全性不同：Token安全性优于Session，因为每个请求都有签名还能防止监听
• 支持性不同：Session-Cookie需靠浏览器的Cookie机制实现，遇到原生NativaApp就不起作用了（或浏览器Cookie存储禁用）；Token验证机制丰富了客户端类型

JWT（JSON Web Token）鉴权

使用Token鉴权的时候，不难发现，服务端验证需要每次去查询用户基本信息，再验证Token是否有效，都在增加查库带来的延迟等性能问题，这时候JWT就应运而生了。

何为JWT？

JWT 是 Auth0 提出的通过对 SON 进行加密签名来实现授权验证的方案。

登录成功后将相关信息组成JSON对象，并对它进行某种方式的加密返回给客户端，客户端在下次请求的时候带上这个Token，服务端会校验其合法性。

JWT的组成

• Header头部 ：typ（Token的类型，JWT类型） + alg（Hash算法，‘HS256’）
• Payload负载：包含一些声明，用来存放实际需要传递的数据
• Signature签名：对上面两部分的签名，放篡改

中间用点(.)分隔三个部分，如下：

 eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

JWT的使用方式

客户端收到服务器返回的JWT，可以存在Cookie里，也可以存在localStorage。

此后在请求API时，需要带上这个JWT。可以放在Cookie里自动发送，但是这样不能跨域，所以一般放在HTTP请求头信息Authorization字段里。

JWT认证过程

整体和Token认证过程差不多，只是不需要单独去查询数据库查找用户

1. 客户端：发送登录信息（用户名+密码）
2. 服务器：校验登录信息，使用密钥创建JWT；返回JWT给客户端
3. 客户端：收到JWT后保存在本地；此后调用API携带JWT在请求头中
4. 客户端：检查JWT是否有效，从JWT中获取用户信息，处理相关数据，返回数据给客户端

JWT的优点

• 不需要在服务器保存会话信息，所以易于应用的扩展
• JWT中Payload负载可以存常用信息，用于信息交换，有效地使用JWT可以避免多次查库

JWT的缺点

• 加密问题：JWT默认是不加密的，但是也可以加密，生成原始Token之后，可以用密钥再加密一次
• 到期问题：由于服务器不保存Session，因此无法在使用过程中废纸某个Token，或更改Token权限。也就是说，JWT一旦签发了，在到期时间之前都有效。

5、单点登录

随着企业的发展，一个大型系统里可能包含多个子系统，用户在操作不同系统时，需要多次登录，很麻烦，这时单点登录就能很好的解决这个问题。只需要登录一次，就可以访问其他相互信任的应用系统。

同域下的SSO（主域名相同）

当百度网站存在两个相同主域名下的贴吧子系统 tieba.baidu.com 和网盘子系统 pan.baidu.com 时，以下为他们实现 SSO 的步骤：

1. 客户端：用户访问某个子系统时，如果没有登录，则跳转至SSO认证中心提供的登陆页进行登录
2. 服务端：登录认证后，服务端把登录用户的信息存在Session中，并附加在相应头Set-Cookie字段中，设置Cookie的Domain为：.baidu.com
3. 客户端：再次发请求时，携带主域名Domain下的Cookie发送给服务器，此时服务器就可以通过Cookie验证登录状态了

6、OAuth 2.0

我们实际浏览网站时，除了输入用户名+密码之外，还有第三方的登录方式，比如：微信、QQ，这时候就要谈到OAuth了。

OAuth 协议又有 1.0 和 2.0 两个版本，2.0 版整个授权验证流程更简单更安全，也是目前最主要的用户身份验证和授权方式。

何为OAuth 2.0？

OAuth是一个开放标准，允许用户授权第三方网站（CSDN等）访问他们存储在另外的服务器提供的信息，而不需要将用户名密码提供给第三方网站。

常见的提供 OAuth 认证服务的厂商： 支付宝、QQ、微信、微博

OAuth就是一种授权机制，数据的所有者告诉系统，同意授权第三方应用进入系统，获取这些数据。系统从而产生一个短期的进入令牌Token，用来代替密码，供第三方应用使用。

令牌与密码的差异：

• 令牌是短期的，到期会自动失效：用户自己无法修改，密码一般长期有效，用户不修改
• 令牌可以被数据所有者撤销，会立即失效
• 令牌有权限范围scope

7、联合登录和信任登录

联合登录指同时包含多种凭证校验的登录服务，同时，也可以理解为使用第三方凭证进行校验的登录服务。

通俗点讲： 对于两个网站 A 和 B，在登录 A 网站的时候用 B 网站的帐号密码，就是联合登录，或者登录 B 网站的时候使用 A 网站的帐号密码，也是联合登录。

信任登录是指所有不需要用户主动参与的登录，例如建立在私有设备与用户之间的绑定关系，凭证就是私有设备的信息，此时不需要用户再提供额外的凭证。信任登录又指用第三方比较成熟的用户库来校验凭证，并登录当前访问的网站

通俗点讲： 在 A 网站有登录状态的时候，可以直接跳转到 B 网站而不用登录，就是信任登录。

8、唯一登录

唯一登录，指的是禁止多人同时登录同一账号，后者的登录行为，会导致前者掉线。

用户在客户端 A 操作：

• 输入账号请求登录接口
• 后端生成对应 Token 并且返回给客户端 A，并且在服务端保存一个登录状态
• 客户端A 保存 Token，并且每次请求都在 header 头中携带对应的 Token

用户在客户端 B 操作：
突然用户在客户端 B 上开始登录操作，我们会发现，步骤和在客户端A上面的操作几乎是一致的
只是后端在生成新的 Token 时，要先验证登录状态，然后再生成对应新的 Token

9、扫码登录

二维码又称二维条码，常见的二维码为 QR Code，QR 全称 Quick Response，是一个近几年来移动设备上超流行的一种编码方式，它比传统的Bar Code条形码能存更多的信息，也能表示更多的数据类型。

通过上面所述，我们不难发现，扫码登录需要三端 (PC端、手机端、服务端) 来进行配合才能达到登录成功的效果；

扫码登录的步骤详解 (待扫码阶段、待确认阶段、已确认阶段)

待扫码阶段：

1. PC端：
   打开某个网站 (如taobao.com) 或者某个 APP (如微信) 的扫码登录入口；就会携带 PC 端的设备信息向服务端发送一个获取二维码的请求；
2. 服务端：
   服务器收到请求后，随机生成一个 UUID 作为二维码 ID，并将 UUID 与 PC 端的设备信息 关联起来存储在 Redis 服务器中，然后返回给 PC 端；同时设置一个过期时间，在过期后，用户登录二维码需要进行刷新重新获取。
3. PC 端：
   收到二维码 ID 之后，将二维码 ID 以 二维码的形式 展示，等待移动端扫码。并且此时的 PC 端开始轮询查询二维码状态，直到登录成功。
   如果移动端未扫描，那么一段时间后二维码会自动失效。

已扫码待确认阶段：

1. 手机端：
   打开手机端对应已登录的 APP (微信或淘宝等)，开始扫描识别 PC 端展示的二维码；
   移动端扫描二维码后，会自动获取到二维码 ID，并将移动端登录的信息凭证（Token）和二维码 ID 作为参数发送给服务端，此时手机必须是已登录（使用扫描登录的前提是移动端的应用为已登录状态，这样才可以共享登录态）。

2. 服务端：
   收到手机端发来的请求后，会将 Token 与二维码 ID 关联，为什么需要关联呢？因为，当我们在使用微信时，移动端退出时，PC 端也应该随之退出登录，这个关联就起到这个作用。然后会生成一个临时 Token，这个 Token 会返回给移动端，一次性 Token 用作确认时的凭证。

已确认阶段：

1. 手机端：
   收到确认信息后，点击确认按钮，移动端携带上一步中获取的 临时 Token 发送给服务端校验。

2. 服务端：
   服务端校验完成后，会更新二维码状态，并且给 PC 端生成一个 正式的 Token，后续 PC 端就是持有这个 Token 访问服务端。

3. PC端：
   轮询到二维码状态为已登录状态，并且会获取到了生成的 Token，完成登录，后续访问都基于 Token 完成。

10、一键登录

一键登录能不能做，取决于运营商是否开放相关服务；随着运营商开放了相关的服务，我们现在已经能够接入运营商提供的 SDK 并付费使用相关的服务。

一键登录步骤详解：

1. SDK 初始化： 调用 SDK 方法，传入平台配置的 AppKey 和 AppSecret
2. 唤起授权页： 调用 SDK 唤起授权接口，SDK 会先向运营商发起获取手机号掩码的请求，请求成功后跳到授权页。授权页会显示手机号掩码以及运营商协议给用户确认。
3. 同意授权并登录： 用户同意相关协议，点击授权页面的登录按钮，SDK 会请求本次取号的 Token，请求成功后将 Token 返回给客户端
4. 取号： 将获取到的 Token 发送到自己的服务器，由服务端携带 Token 调用运营商一键登录的接口，调用成功就返回手机号码。服务端用手机号进行登录或注册操作，返回操作结果给客户端，完成一键登录。