1.cookie-session

1. cookie

cookie简单来说就是浏览器客户端在请求时会携带的一个字段数据，常用与保存当前用户状态并在请求时携带给服务端验证。

2. session

session简单来说就是服务单对于每一个用户生成一个用户会话标识session /session id，并返回给客户端，客户端在每次请求时携带这个会话标识就可以判断当前用户的会话状态。

3. 鉴权原理

1. 初次登录时，服务端将当前用户的登录状态生成一个session/session id
2. 服务端将session id（sid)） 设置到cookie 中随请求返回。
3. 下次请求时浏览器自动携带当前域名下的cookie，服务端获取到sid之后，根据sid的信息来匹配上对应的session,然后判断该请求是否合法。

4. 缺点

1. 不安全， sid保存到cookie容易被篡改
2. 对移动端支持不优化，仅可在浏览器web应用中使用
3. 依赖浏览器请求头携带cookie，如果浏览器禁用cookie会造成该方案无法使用

2.token

1.token

token指的是由服务端生成的一个专门用于判断用户身份的令牌，客户端可以携带这个令牌来获取数据。这个token一般来说会存在时效性，过期即作废，需要重新申请。因此这也衍生出了两种不同的token。

2.token的分类

1. Access token

用户校验用户信息的token，在每次请求时发送给服务器

1. Refresh token

用户重新火球Access token，在Access token过期，服务器返回401时发送给服务器，服务器根据Refresh toekn的有效性重新签发一份新的Access toekn返回给浏览器。

3.鉴权原理

1. 初次登录，服务器生成一份toekn并返回给客户端
2. 客户端收到token后将其保存到浏览器本地，一般为localStorage
3. 后续请求时客户端在请求头中携带token,一般为Authoration 字段
4. 服务端判断token是否有效，有效则正常请求，无效返回401

以下阶段为使用Refresh token 场景下

1. 如果使用Refresh toekn方案，此时客户端接受到401 后，会携带Refresh toen再次请求服务器
2. 服务器收到Refresh toekn后，根据其有效性自动重新签发一份token并返回
3. 浏览器接收到新token之后覆盖本地token并重新发发送请求

Refresh token方案下， Refresh toekn是在初次登录是和Access token一起生成并返回给客户端客户端

3.JWT

1.jwt（json web token）

jwt本质上就是token鉴权的一种实现方式,通过服务端临时深成一个编码的toekn字符串来返回给客户端。

2.组成

jwt主要有三部分组成，分别是Header,Payload,Signature(签名）

jwt是一段很长的字符串，有点号（.）分割为以上的三部分

• Header一般包含token的类型，例如是JWT；加密使用的算法
• Payload一般是保存用户的一部分信息以及一些官方字段，包括iss（签发人），exp（过期时间），nbf(生效时间）等等。
• Sginature 一般是一个签名，这个签名是将一个密钥通过Header里面的加密算法加密过后的字符串。密钥保存再当前服务端。

3.鉴权原理和token一样

4.单点登录（SSO）

1.单点登录介绍

所谓单点登录，指的是在登录了某一个系统之后，再去使用其子系统或相关系统是，可以自动获取到用户信息，不需要重复登录的一种技术。单点登录主要分为两种类型，即同域名和不同域名

2.同域名单点登录

1.前提条件

• 两个系统均使用cookie携带用户信息（可以是cookie-session ,也可以是token）
• 两个系统的一级或者二级域名相同（同一个主域名）

2.鉴权原理

1. 客户端登录系统1后，将其对应的cookie信息保存下来，并设置cookie的Domain字段为主域名
2. 客户端访问系统2时，在发送请求时会自动携带上与当前系统主域名相同的cookie信息到服务端请求数据，此时服务端就可以获取到用户信息了。

3.不同域名下的单点登录

1.CAS 中央授权系统

用于判断用户登录状态并为需要的系统签发用户登录凭证

2.鉴权原理

1. 用户当访问系统1时，发现用户未登录，调用CAS的登录登录模块并跳转至CAs的登录界面
2. 用户在CAS上登陆之后，服务端生成一份TGC存放到session中，并生成一份ST授权信息，携带ST重定向系统1的页面。将TGC写入到当前中央授权系统的Domain下。
3. 系统1在加载后获取到ST，拿着ST向CAS校验授权有效性，若授权有效则系统1将ST作为凭证参与后续请求会话。
4. 此时再去访问系统2，首先判断用户未登录跳转至CAS，携带Domain中的TGC发送请求判断登陆状态
5. 判断已登录后跳转至系统2的地址并附上ST凭证

5.OAuth 2.0(三方登录）

1.OAuth

OAuth是一个开放的标注，允许第三方网站访问提供商服务并获取对应的用户信息而无需再忍第三方网站单独登录

2.授权码模式

1. 客户端点击第三方登录，发送请求
2. 服务端收到请求之后，会重定向到授权器
3. 授权服务器返回授权网站，判断用户是否登录，登陆之后会询问是否为这个网站授权
4. 用户同意后，会跳转会原来的网站地址，并且携带一个授权码
5. 服务端拿到授权码之后，通过授权码向授权服务器发送请求获取token
6. 授权服务器将对应的token信息发送至当前服务端，服务端会把token返回给浏览器，在后续请求时都会携带

3.隐藏式模式

1. 客户端点击第三方登录直接重定向到授权页面
2. 授权成功后，在重定向到前端页面时，直接携带一个token挑战
3. 跳转成功后将token保存下来
4. 每次请求用户信息是直接携带token向授权服务器发送请求

6.扫码登录

1.扫码登录

扫码登录一般是使用一些移动端设备，为pc端授权登录的场景

2.登录原理

待扫码阶段

1. pc端点击扫码登陆之后，向服务端请求一个获取二维码的请求
2. 服务端接收请求后，生成一个uuid作为二维码id并将uuid和pc设备信息关联起来存储到redis中，然后返回给pc端。
3. pc端接收到二维码id之后，通过canvas价格二维码id渲染二维码，等待移动端扫码。并且开始轮询查询二维码状态，发现二维码过期之后会提示。

已扫码待确认阶段

1. 使用移动端设备扫码，扫码后会解析二维码图像并生成对应的id
2. 移动端将对应的id发送给服务端，并查询到pc登录设备信息返回。并生成一个临时token用于移动端确认
3. 移动端弹出确认界面，并展示pc登录的状态，比如登录时间，地点等等

已确认阶段

1. 移动端确认登录，携带上一步获取的临时token发送到服务端
2. 服务端验证token有效性，通过验证后签发一个正式的token返回给PC端。
3. Pc端获取到token信息后，二维码展示为已确认状态，并跳转至使用页面完成登录。

7.一键登录

1.一键登录

一键登录指的是客户端直接从用户系统中获取到对应的手机号，直接使用该手机号完成登录。一般适用于原生应用或小程序应用

2.登录原理

1. 用户点击一键登录
2. 通过运营商SDK调用，唤起配置页面，SDK会先发送手机号掩码到运营商服务器，请求成功后跳转至确认页面，显示出手机掩码及运营商协议等供用户确认。
3. 同意授权登录后，SDK会请求本次取号的token，成功后将token返回给客户端
4. 客户端将取号token发送到服务器，服务器携带携带取号token调用运营商的一键登录接口获取用户手机号，服务端使用手机号完成登录流程，生成token返回给客户端。