令牌（token）与密码（password）的作用是一样的，都可以进入系统，但是有三点差异。
令牌
- 短期有效，到期自动失效
- 可以被数据所有者撤销，会立即失效
- 存在权限范围
密码
- 长期有效
- 一般不允许他人撤销
- 一般是完整权限
淘宝和支付宝登录
1、在淘宝点击支付宝登录
2、跳转到支付宝登录页面，输入账密或扫码登录
3、成功登录，跳回淘宝首页
登录时序图
资源持有者：淘宝用户
授权客户端访问资源（用户信息）
客户端：淘宝
访问受限资源的第三方应用
资源服务器和授权服务器：支付宝
授权服务器：颁发令牌，验证用户提交的信息是否正确 资源服务器：持有资源（用户信息），提供客户端访问 资源和授权服务器项目中需要分开
OAuth2：授权协议
解决了第三方认证的问题，让客户端获得用户数据
OAuth2授权模式
授权码模式、简化模式、密码模式、客户端模式
| 名称 | 简介 | 安全性 |
|---|---|---|
| 授权码模式 | 最完整和严谨的授权模式,第三方登录 均是此模式 | 最高 |
| 简化模式 | 省略授权码阶段，客户端是纯静态页面采用 此模式 | 高 |
| 密码模式 | 把用户名密码告诉客户端,对客户端高度信 任，比如客户单和认证服务器是同一公司的 | 一般 |
| 客户端模式 | 直接以客户端名义申请令牌，很少使用 | 最差 |
授权码模式：先得到一个码，一个码只能换一次令牌，换完马上失效
浏览器即使持有码，也换不到令牌了，码换一次就失效。
授权码用于服务器间交互，淘宝通过远程调用的方式拿码换令牌，令牌在淘宝保存。浏览器看不到令牌，会很安全
简化模式：没有过程7 - 12，直接申请令牌，令牌在浏览器存储，都可以被读取，没有存储在服务器上安全。适用于纯静态页面，其无法在服务器端保持令牌，无法写代码发请求
密码模式：前后端登录使用密码模式，客户端被认证服务器高度信任
客户端模式：子网站，报出密钥都得把令牌给过来
为什么要用OAuth2？ 单体架构登录 cookie-session机制 微服务架构方案1
session共享
三种方案：
1、复制session，节点多的情况下不合适
2、nginx的session粘连，特定ip只能访问特定节点，无法高可用
3、session共享，存储到redis中，读共享session，使用到Spring Session
微服务架构方案2
基于token
通过令牌访问资源服务器，验证令牌进行认证和登录
cookie session和token的区别- cookie不能跨域，分布式架构实现多系统SSO困难
- 移动端应用没有cookie，移动端支持不好
- token基于header传递，解决了部分CSRF攻击
- token比sessionID大，客户端存储在LocalStorage，可直接被JS读取
