2.前端常见的鉴权方式

HTTP Basic Authentication（HTTP基本鉴权）

大部分项目已经不使用此方案，了解即可

流程

流程如下：

优点

• 兼容性好

缺点

• 安全性差，以base64格式在http中传输，容易被截获解码，容易被重放攻击。
• 无法主动注销

Session-Cookie机制

利用服务端Session和客户端Cookie来实现前后端通信认证模式

流程

流程如下：

• 客户端（浏览器）：向服务器发送登录信息的用户名/密码来请求登录校验
• 服务端：验证信息 -> 通过后创建Session（保存在内存/Redis中）-> 给此session生成唯一id -> 在响应头（set-cookie）中设置

可以对sessionid进行加密，验证时服务端解密。

• 客户端（浏览器）：收到服务器的响应后会解析响应头，并自动将sessionid保存在本地 Cookie 中，浏览器在下次 HTTP 请求时请求头会自动附带上该域名下的 Cookie 信息；
• 服务端：接收客户端请求时会去解析请求头 Cookie 中的 sessionid，然后根据这个 sessionid 去找服务端保存的该客户端的 sessionid，然后判断该请求是否合法

优点

• cookie简单易用
• session存储在服务端，相比JWT好管理
• 只需要后端操作，前端无感

缺点

• 依赖Cookie，用户禁用Cookie就失效
• 安全性差，暴露在浏览器中
• 增加服务器开销
• 对移动端支持不好（ios和android cookie操作不方便）
• 对分布式应用支持不友好

Token机制(JWT)

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

JWT一般由Header（头部）、Payload（载荷）、Signature（签名）组成，中间用.隔开。Header是一个描述JWT元数据的Json对象（算法alg、类型typ）；payload是主体部分，保存实体信息（到期时间exp，发行人iss，主题sub，用户aud等...，也可以定义私有字段）；signature签名是对上面两个部分数据利用指定密钥进行签名

• payload和header只是简单的base64加密，因此payload不存储敏感信息
• signature为不可逆加密，仅用作校验Token是否被篡改
• 避免存储过多信息

流程

• 客户端（浏览器）:输入用户名和密码请求登录校验
• 服务器：收到请求，去验证用户名和密码；验证成功后，服务端签发token并发给前端
• 客户端（浏览器）：收到Token后存储到localStorage或cookie中
• 客户端发送请求时：将Token通过请求头的Authorization字段（可自定义）发送至服务端
• 服务器：验证Token可用性，通过返回数据，否则报错。

Refresh Token

为了避免Token因有效期过短过期，提出了Refresh Token这个概念

• Access Token：用于验证业务
• Refresh Token: 用于获取Access Token，有效期比Access Token长

流程

• 客户端（浏览器）:输入用户名和密码请求登录校验
• 服务器：收到请求，去验证用户名和密码；验证成功后，服务端签发Access Token和Refresh Token并发给前端
• 客户端（浏览器）：收到Token后存储到localStorage或cookie中
• 客户端发送请求时：将Access Token通过请求头的Authorization字段（可自定义）发送至服务端
  • 验证Access Token有效：正常返回数据
  • 验证Access Token过期：拒绝请求
• 客户端（Access Token过期）：传输Refresh Token给后端
• 服务端（Access Token过期）：验证 Refresh Token ，验证成功后返回新的 Access Token 给客户端；
• 服务器：重新携带新的 Access Token 请求接口；

优点

• 服务端无状态，利于微服务（分布式）应用
• 支持App端设备
• 有效避免CSRF
• 支持跨程序调用

缺点

• 到期前无法手动失效

SSO（Single Sign On - 单点登录）

同域SSO(主域名相同)

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

• 客户端：用户访问某个子系统时（tieba.baidu.com），如果没有登录，则跳转至SSO认证中心（sso.baidu.com）提供的登陆页面进行登录
• 服务端：登录认证后，服务端把登录信息存储于Session中，并且附加在响应头的set-cookie字段中（设置Cookie的domain为.baidu.com）

异域SSO（主域名不同）

传统：使用CAS（中央授权服务）

• 用户通过浏览器访问某个应用系统（CAS Client），该系统发现用户没有登录，于是返回302状态码，并且携带上一个service参数，让用户去CAS Server上登录。
• 浏览器自动重定向到CAS Server上，CAS Server获取用户Cookie中携带的TGC（Ticket Granting Cookie），去校验用户是否已经登录，如果已经登录，则完成身份校验（此时CAS Server可以根据用户的TGC找到TGT（Ticket Granting Ticket），进而获取用户的信息）；如果未登录，则重定向到CAS Server的登录页面，用户输入用户名/密码，CAS Server会生成TGT，并且根据TGT签发一个ST（Service Ticket），再将TGC放在用户的Cookie中，完成身份校验。
• CAS Server完成身份校验之后，会将ST拼接在service中，返回302状态码，浏览器将首先将TGC存在Cookie中，然后根据302的指示，携带上ST重定向到应用系统。
• 应用系统收到浏览器传来的ST之后，拿去CAS Server上校验，去判断用户的登录状态，如果用户登录合法，CAS Server就会返回用户信息给应用系统。应用系统可以根据用户信息建立一个局部的会话，把Cookie发给浏览器，同时返回请求页面的内容。
• 如果用户再去访问另一个应用系统（CAS Client），该系统也会重定向到CAS Server，CAS Server发现此时用户实际上已经登录了，于是又重定向回应用系统，同时携带上ST。应用系统拿着ST去CAS Server上校验，获取用户的登录信息。

TGT(Ticket-granting cookie)

存放用户身份认证凭证的cookie，在浏览器和CAS Server间通讯时使用。

TGC(Ticket-granting ticket)

TGT对象的ID就是TGC的值，在服务器端，通过TGC查询TGT。TGT封装了TGC值以及此Cookie值对应的用户信息。

OAUTH2.0

授权码模式