认证方式

1.Cookie-Session模式

1.基本介绍

• 早期互联网以 web 为主，客户端是浏览器，所以 Cookie-Session 方式最那时候最常用的方式，直到现在，一些 web 网站依然用这种方式做认证。

2.认证流程

1. 客户端发起认证请求;
2. 服务端认证请求验证后，创建Session对象(封装用用户的一些信息)，并将SessionId存入cookie，随cookie写入响应头给客户端;
3. 客户端再次发起请求时，携带cookie信息，服务端通过cookie获取Session信息校验;

3.缺点

• 只能在 web 场景下使用，如果是 APP 中，不能使用 cookie 的情况下就不能用了;
• 即使能在 web 场景下使用，也要考虑跨域问题，因为 cookie 不能跨域;
• cookie 存在 CSRF（跨站请求伪造）的风险;
• 如果是分布式服务，需要考虑 Session 同步问题;

4.改造

• 将Session存入redis来解决分布式系统中的Session同步问题。同时提高了Session的获取速度;

• web客户端采用local storage存储;

• 认证流程:

  1. 用户输入用户名、密码或者用短信验证码方式登录系统;
  2. 服务端经过验证，将认证信息构造好的数据结构存储到 Redis 中，并将 key 值返回给客户端;
  3. 客户端拿到返回的 key，存储到 local storage;
  4. 下次客户端再次请求，把 key 值附加到 header 或者 请求体中;
  5. 服务端根据获取的 key，到 Redis 中获取认证信息;

---

2.Token-Auth模式

1.基本介绍

• 使用基于JWT的Token认证方案;
• **JWT介绍:**JSON Web Token（JWT）是一个非常轻巧的规范。这个规范允许我们使用JWT在用户和服务器之间传递安全可靠的信息;
• **JWT结构:**由头部(header)，荷载(payload)，签名(signature);

2.认证过程

1. 客户端发起认证请求;
2. 服务端，将认证信息进行加密，例如用户名或角色。其中使用的密匙保存在服务端。将加密后的结果发送给客户端。注:加密的字符串格式为三个"." 分隔的字符串 Token，分别对应头部、载荷与签名，头部和载荷都可以通过 base64 解码出来，签名部分不可以(header+payload+密匙的加密);
3. 客户端拿到返回的 Token，存储到 local storage 或本地数据库;
4. 下次客户端再次发起请求，将 Token 附加到 header 中;
5. 服务端获取 header 中的 Token ，通过相同的算法对 Token 中的用户名和所属角色进行相同的加密验证，如果验证结果相同，则说明这个请求是正常的，没有被篡改。这个过程可以完全不涉及到查询 Redis 或其他存储;

3.缺点

• 无状态导致其无法保持长对话，一旦token过期，用户将面对重新登录的情况，用户体验差;
• 多次认证会颁发多次token，多个token同时有效，被窃取的概率增大，不安全;

4.改造

目的在于解决token的刷新

• 引入refresh_token,加上原本的token，存入redis，添加过期时间（refresh_token的设置时长大于token）

• 认证流程:

  • 客户端发起认证请求;
  • 服务端认证完成，生成两个token，一个用来刷新token，一个用来验证后续的访问。通过请求体或者头返回给前端;
  • 客户端收到结果，将结果保存到本地。
  • 当发现token过期时，此时携带refresh_token访问服务端;
  • 服务端接口验证refresh_token是否过期，再次返回两个token;
  • 客户端接收到返回结果，带上新的token来访问对应资源;

---

3.OAuth模式

1.基本介绍

1.介绍：

OAuth 认证比较常见的就是微信登录、微博登录、qq登录等，简单来说就是利用这些比较权威的网站或应用开放的 API 来实现用户登录，用户可以不用在你的网站或应用上注册账号，直接用已有的微信、微博、qq 等账号登录。

2.工作原理:

• 维基百科对它的解释摘要如下：

  OAuth允许用户提供一个令牌，而不是用户名和密码来访问他们存放在特定服务提供者的数据。每一个令牌授权一个特定的网站（例如，视频编辑网站)在特定的时段（例如，接下来的2小时内）内访问特定的资源（例如仅仅是某一相册中的视频）。这样，OAuth让用户可以授权第三方网站访问他们存储在另外服务提供者的某些特定信息，而非所有内容。

• 涉及角色:

  • 用户：即使用我们平台的用户
  • 用户终端：即最终用户使用的 APP 端或 web 端
  • 应用服务器端：即我们的服务器端
  • 授权服务器端：这里就是微信处理授权请求的服务器

2.认证流程

1. 我们电商平台的用户过来登录，常用场景是点击“微信登录”按钮；
2. 接下来，用户终端将用户引导到微信授权页面；
3. 用户同意授权，应用服务器重定向到之前设置好的 redirect_uri （应用服务器所在的地址），并附带上授权码（code） ;
4. 应用服务器用上一步获取的 code 向微信授权服务器发送请求，获取 access_token，也就是上面说的令牌;
5. 之后应用服务器用上一步获取的 access_token 去请求微信授权服务器获取用户的基本信息，例如头像、昵称等；

3.缺点

• 结构复杂，简单项目不建议使用