概念解释

SSO 单点登录，打通多个系统的用户认证和权限系统。最简单的描述就是将鉴权抽离出来作为一个单独的系统，用户的鉴权统一移交至该系统。而其他系统无需再重复创建用户系统部分。实现系统层面的功能解耦

cookie 生命周期为浏览器关闭或者到期失效

session 存在于服务端的会话信息，主要用于处理会话状态。通常生命周期是客户端浏览器第一次发送请求到 session 时间到期。（当客户端浏览器更换时 session id 便会变更，服务端可以主动删除这个session)

jwt 无服务状态的短期权限认证，因为存在无状态机制，主要用于申请部分资源的限时访问。(如果 redis + jwt 用于类似session机制，可能对同一账户的登录无法进行限制)

鉴权

• Session
  需要通过web容器的会话管理机制来对访问用户进行鉴别

弊处

1. 这种方法对容器的依赖性较高
2. 会话信息数据的迁移不便
3. 不利于做集群

因此存在 spring session 以及 mysql/redis等数据存储统一存放session的机制。由于目前微服务和集群化的趋势，session目前已经不再是局限于容器或者单机应用了。

• Token
  目前应用的比较多的是使用jwt，生成的token中包含三部分：header/payload/verify signature,其中前面两部分可以通过base64转码得出，但是最后一部分需要服务端密钥。
  • header 用于描述元信息
  • payload 用于携带向服务端传递的信息
  • signature 用于签名认证

JWT只应该用于标识已经被授权，不应该传入重要的保密数据

JWT 的目的不是为了隐藏或者保密数据，而是为了确保数据确实来自被授权的人创建的（不被篡改）

优点

1. 比较容易验证是否为有效的token。这种方式不依赖于容器，可以将token存放在redis缓存中
2. 可以携带数据

---

下面两种方案都存是第三方授权认证方案，和用户鉴权有些区别，但是也有用户鉴别的功能

• SAML
  具体流程参考资料中有较为详细的解释
  弊端

1. 主要应用于早时期的web时代，适用于http post场景，但是不适用于目前的移动端

• OAuth 2.0
  通过例如微信小程序、QQ、支付宝、google应用商店、Youtube等等应用的第三方授权。通过授权以后，程序开发者就可以调用这些应用中的部分用户授权数据。
  借用参考资料中的一段话。

OAuth 的本意是一个应用允许另一个应用在用户授权的情况下访问自己的数据,OAuth 的设计本意更倾向于授权而非认证（当然授权用户信息就间接实现了认证）

• OpenId
  和OAth不同，通常只是为了站点登录，作为用户身份背书使用，例如使用github账号登录gitee，利用facebook登录站点等等

⚓mark
下面的资料仅供参考，后面还需要更多的资料探究。
参考资料

Q.E.D.