OAuth
OAuth（Open Authorization）是一种开放协议，允许用户分享数据给第三方。
使用示例：第三方登录。
历史版本：
- OAuth 1.0：已废弃
- OAuth 2.0：使用中，不兼容1.0
- OAuth 2.1：草稿中
授权流程
客户端通过token来访问受限资源。
服务端下发token的过程称为授权。
OAuth有四种授权流程：
- 授权码（authorization code）
- 隐藏式（implicit）
- 客户端凭证（client credentials）
- 密码式（password）
在开始了解流程前，先回想下使用过第三方登录的场景。
下面是一个PC浏览器使用微博账号登录知乎的流程：
- 在知乎登录界面，选择其他方式登录-微博，弹出新窗口到微博登录界面
- 登录微博账号，进入权限选择界面（邮箱可选），点“允许”或“忽略”，窗口自动关闭
- 知乎网站登录成功
授权码
术语：
client_id：类似用户名client_secret：类似密码authorization server：授权服务，处理认证、授权resource server：资源服务，提供受保护的资源
在上面的第三方登录例子中，知乎网是client，微博网是server，提供了授权服务、资源服务（获取微博账号信息、邮箱）。
授权码完整流程如下：
- 客户端发起授权流程，打开服务端授权页面
url上携带client_id、response_type=code、scope（所需权限）、redirect_uri（可选）等信息 - 服务端要求用户登录（服务端自己的登录流程），然后选择允许的权限。操作完成后通知客户端（重定向、opener等），给予授权码
- 客户端使用授权码，加上
client_id、client_secret，在客户端自己的后端服务请求服务端的授权服务 - 服务端校验上一步的信息，通过则下发token给客户端，客户端即可使用此token访问资源服务
隐藏式
相比于授权码的流程，不发送授权码，改为直接发送token给客户端。
称为（授权码）“隐藏式”。适用于客户端没有后端服务，是纯前端应用的情况。
四步缩短为两步，只有1、2。
客户端凭证
相比于授权码流程，不需要用户参与，客户端的后端服务直接与服务端通信。
适用于服务端完全信任客户端的情况。
四步缩短为两步，只有3、4。
密码式
相比于授权码的流程，不跳转服务端授权页面，客户端直接让用户输入服务端的用户名密码，加上client_id请求服务端授权。
适用于服务端高度信任客户端的情况。
相比“客户端凭证”流程多了一步：客户端让用户输入服务端的用户名密码。
使用token
一般客户端、服务端是不同源的，OAutn token通常会放在请求头里，没有CORS问题。
http
Authorization: Bearer ACCESS_TOKEN更新token
token过期，为避免用户重新走一遍授权流程，服务端可在下发token时，多发一个refresh token。客户端使用refresh token来刷新token。