目录
1、单一服务器模式
2、SSO（Single Sign On）模式
3、Token模式
1、单一服务器模式
即只有一个服务器，用户通过输入账户和密码，提交表单后服务器拿到前端发送过来的数据查询数据库是否存在该用户，其一般流程如下：
- 用户向服务器发送用户名和密码。
- 验证服务器后，相关数据（如用户名，用户角色等）将保存在当前会话（session）中。
- 服务器向用户返回session_id，session信息都会写入到用户的Cookie。
- 用户的每个后续请求都将通过在Cookie中取出session_id传给服务器。
- 服务器收到session_id并对比之前保存的数据，确认用户的身份。
缺点：
- 单点性能压力，无法扩展。
- 分布式架构中，需要session共享方案，session共享方案存在性能瓶颈。
比如，有服务器A和服务器B，此时用户先访问服务器A后被提示登录，那么用户登录后cookie会记录与服务器A对应的sessionId，此时用户再去访问同个微服务的不同应用，即服务器B。此时因为服务器A和服务器B是独立的，sessionId并不共享，所以用户又被要求登录一次。
session共享方案：
session广播：性能瓶颈，不推荐
redis代替session：推荐，性能高，即将sessionId等可以识别用户登录的信息存放到redis，可以设置对应的过期时间，当用户访问对应的服务器就去redis中获取相应的的信息。
2、SSO（Single Sign On）模式
分布式，SSO(single sign on)模式：单点登录英文全称Single Sign On，简称就是SSO。它的解释是：在多个应用系统中，只需要登录一次，就可以访问其他相互信任的应用系统。
- 如图所示，图中有3个系统，分别是业务A、业务B、和SSO。
- 业务A、业务B没有登录模块。
- 而SSO只有登录模块，没有其他的业务模块。
一般过程如下：
- 当业务A、业务B需要登录时，将跳到SSO系统。
- SSO从用户信息数据库中获取用户信息并校验用户信息，SSO系统完成登录。
- 然后将用户信息存入缓存（例如redis）。
- 当用户访问业务A或业务B，需要判断用户是否登录时，将跳转到SSO系统中进行用户身份验证，SSO判断缓存中是否存在用户身份信息。
- 这样，只要其中一个系统完成登录，其他的应用系统也就随之登录了。这就是单点登录（SSO）的定义。
优点 ：
用户身份信息独立管理，更好的分布式管理。可以自己扩展安全策略
缺点：
认证服务器访问压力较大。每次访问服务都需要跳转到SSO服务进行验证登录。
3、Token模式
- token的引入：token是在客户端频繁向服务器端请求数据，服务器端频繁的去数据库查询用户名和密码并进行对比。由此，token出现了。
- token的定义：token是服务器端生成的一串字符串，作为客户端请求的一个令牌，当第一次登录后，服务器生成一个token并返回给客户端，客户端带着这个token前来发送请求，无需带上用户名和密码。
- 使用token的目的：token的目的是为了减轻服务器的压力，减少频繁的查询数据库，使得服务器更加健壮。
- token的产生：token是在服务器端产生的，如果前端使用用户名/密码向服务器端请求认证，服务器端认证成功后，那么在服务端会返回token给前端，前端可以在每次请求的时候带上token表明自己携带用户。
客户端将用户名和密码提交道授权服务器进行验证，验证通过后会返回一个token存放在客户端，客户端可以通过token去访问其他的服务器，就不需要像SSO模式一样每次访问SSO服务进行认证
优点：
- 无状态： token是无状态（即不将用户信息存在服务器或 Session 中），session是有状态的
- 基于标准化：你的API可以采用标准化的 JSON Web Token (JWT)
缺点：
- 占用带宽
- 无法在服务器端销毁，因为token是存放在客户端的
