前后端鉴权方案

链接：https://mp.weixin.qq.com/s/wnkq4gQuVGp4_9rQ4_t8aA

什么是认证：根据声明者的识别信息，确认身份（根证明自己类似）
什么是授权：资源所有者 赋予执行者指定范围的资源操作权限（银行卡、门禁卡、钥匙、we b的session、web的cookie、token等）
什么是鉴权：对声明者声明的身份权利对其真实性鉴别的过程（这个身份有这个权利吗）
什么是权限控制：将可执行的操作定义为权限列表，判断操作是否允许禁止

一、HTTP 基本鉴权
是允许客户端（通常指的就是网页浏览器）在请求时，通过用户提供用户名和密码的方式，实现对用户身份的验证
过程 ：
1、客户端向服务器请求一个受限的列表数据或资源
2、服务器：返回401受权限控制，并附带提供一个认证域www-Authenticate: Basic realm=”baidu.com”
3、客户端 携带用户名、密码等（浏览器中会弹框让输入），以base64加密发送
4、服务器：验证成功后正确返回
优点：所有流行浏览器都支持
缺点：
（1）不安全：http传输base64很容易被解码。恶意用户可以 获取认证内容后不断向服务器请求，重放攻击
（2）无法主动注销：无机制清楚浏览器的Basic认证心机，除非标签页浏览器关或用户清楚历史记录
== 内部网站，安全性要求不高的网络使用该鉴权（不包含APP）==

二、Session-Cookie鉴权
利用服务端的 Session（会话）和 浏览器（客户端） 的 Cookie 来实现的前后端通信认证模式
Cookie:针对http是无状态的，为让服务器区分不同客户端而维护的状态，旨在告诉服务器请求是否来自同一浏览器
存储在客户端，可随意篡改，不安全，最大4kb,一个浏览器一个网站最多20个Cookie，浏览器只能300Cookie
不允许跨域
Session:用户向服务端发首次请求，服务端创建特定的Session/SessionId用于标识用户并跟踪用户的会话过程 。浏览器收到响应获取会话信息(响应头中)，下一次请求携带Session/SessionId（sid，放在Cookie信息中）
优点：简单易用，后端操作，前端可以无感等操作
缺点：依赖Cookie，用户在浏览器禁止Cookie则GG
Cookie 将数据暴露在浏览器中，增加了数据被盗的风险（容易被 CSRF 等攻击）
对移动端支持不好，影响服务端性能
一般中大型的网站都适用（除了 APP 移动端）

三、Token鉴权（令牌）-后端生成，前端存储
客户端访问服务器验证通过后服务器发令牌，客户端携带令牌访问，服务端验证令牌有效期
Token组成：uid(用户唯一身份标识+time时间戳+sign签名)

Token 认证步骤解析：
客户端： 输入用户名和密码请求登录校验；
服务器： 收到请求，去验证用户名与密码；验证成功后，服务端会签发一个 Token 并把这个 Token 发送给客户端；
客户端： 收到 Token 以后需要把它存储起来，web 端一般会放在 localStorage 或 Cookie 中，移动端原生 APP 一般存储在本地缓存中；
客户端发送请求： 向服务端请求 API 资源的时候，将 Token 通过 HTTP 请求头 Authorization 字段或者其它方式发送给服务端；（放在header中）
服务器： 收到请求，然后去验证客户端请求里面带着的 Token ，如果验证成功，就向客户端返回请求的数据，否则拒绝返还（401）
优点：支持移动端，安全性好，可防止CSRF攻击（因为不需要Coolie）,支持跨域
缺点：前后端配合使用
耗性能需要对Token进行加解密（占带宽，比sid大）
有效期短（防止被盗用）Refresh Token

Refresh Token 认证步骤解析：

客户端： 输入用户名和密码请求登录校验；
服务端： 收到请求，验证用户名与密码；验证成功后，服务端会签发一个 Access Token 和 Refresh Token 并返回给客户端；
客户端： 把 Access Token 和 Refresh Token 存储在本地；
客户端发送请求： 请求数据时，携带 Access Token 传输给服务端；
服务端：
验证 Access Token 有效：正常返回数据
验证 Access Token 过期：拒绝请求
客户端 ( Access Token 已过期) ： 则重新传输 Refresh Token 给服务端；
服务端 ( Access Token 已过期) ： 验证 Refresh Token ，验证成功后返回新的 Access Token 给客户端；
移动端、浏览器都可

四、 JWT（JSON Web Token）鉴权
通过 对 JSON 进行加密签名来实现授权验证的方案(因为token加解密耗性能)
组成：Header 头部、 Payload 负载 和 Signature 签名（.分隔）
同token的步骤
到期问题：在到期之前一直有效
移动端、浏览器都可

五、单点登录（Single Sign On 只需登录一次）
在多个应用系统中，只需要登录一次，就可以访问其他相互信任的应用系统（子系统较多）
子系统较多的系统

六、OAuth 2.0
OAuth是个协议，允许用户授权第三方网站 (CSDN、思否等) 访问他们存储在另外的服务提供者上的信息，而不需要将用户名和密码提供给第三方网站，支持宝、QQ、微信、微博
OAuth 就是一种授权机制。数据的所有者告诉系统，同意授权第三方应用进入系统，获取这些数据。系统从而产生一个短期的进入令牌（Token），用来代替密码，供第三方应用使用。

七、联合登录和信任登录

八、唯一登录（用的Token,更改Token）
指的是禁止多人同时登录同一账号，后者的登录行为，会导致前者掉线
用户在客户端 A 操作：
输入账号请求登录接口；
后端生成对应 Token 并且返回给客户端 A，并且在服务端保存一个登录状态；
客户端A 保存 Token，并且每次请求都在 header 头中携带对应的 Token；
用户在客户端 B 操作：
突然用户在客户端 B 上开始登录操作，我们会发现，步骤和在客户端A上面的操作几乎是一致的；
只是后端在生成新的 Token 时，要先验证登录状态，然后再生成对应新的 Token；
令牌更改，则之前的就失效，从而实现唯一登录

九、扫码登录
码登录需要三端 (PC端、手机端、服务端) 来进行配合才能达到登录成功的效果
PC通过轮询查询登录状态，直到登录成功

十、 一键登录（适用于原生APP）
账号密码登录：需要记住
手机号验证码登录：繁琐
一键登录：利用手机卡的手机号进行验证，不用用户输入

总结：
HTTP 基本认证适用于内部网络，或者对安全要求不是很高的网络；
Session-Cookie 适用于一般中大型的网站（移动端 APP 除外）；
Token 和 JWT 都适用于市面上大部分的企业型网站，JWT 效能会优于 Token；
单点登录 适用于子系统较多的大型企业网站；
OAuth 2.0适用于需要快速注册用户型的网站；
扫码登录 适用于已完成部署了三端的企业；
一键登录 适用于原生 APP；