oauth2.0-授权过程

invalid redirect uri

包含以下情况
无效uri
参数丢失
uri与注册的不匹配

Verifying the Authorization Request

verify client id

verify redirect uri

如果服务端允许APP注册多个redirect uri，那么需要分两步校验。
如果请求中包含redirect uri，则服务端需确认它是有效的。
如果请求中不包含redirect uri,且只注册了一个URI，使用注册的redirect uri。
如果请求中不包含redirect uri,且未注册URI，有误。

verify response type

verify scope

save state

保存该值，并将它包含在获取access token的响应中

用户登录

一般，登录成功就相当于授权成功。

授权界面

包含服务端信息（如网站名称、网站logo，便于用户识别)，用户身份（如姓名、照片，便于用户知道用那个账号操作），APP信息（APP名称、
app网址、app logo）、范围、取消和同意按钮

临时令牌

下发后，很短时间需过期，推荐10分钟，大多数是30-60秒，长度是任意的，需声明,最好的实现方案是自我包含（避免在数据库中存储临时令牌，
通常通过加密库或jws），需包含client_id、redirect_uri（用在下发access_token校验）、user info(如user id)、过期时间、uid(校验是否被使用过，一般使用数据库id或随机的字符串)

scope

主要是为了限制权限，最好是读写分离

redirect uri validation

当开发者新建app注册redirect uri时（不包含fragment）；
授权请求时；
交换获取令牌时；

请求令牌

redirect_uri

如果授权请求包含了redirect uri,则token请求必须包含redirect uri

response

include the additional Cache-Control: no-store and Pragma: no-cache HTTP headers to ensure clients do not cache this request

令牌生命周期

short-lived access token and long live refresh token

什么情况下使用

使用自包含access token;
限制access token泄露风险；
提供SDK控制access token刷新；

short-lived access token and no refresh token

什么情况下使用

最大保证access token泄露风险；
促使用户意识到在授权给第三方应用；
不希望第三方应用离线访问用户数据；

non-expiring access token

什么情况下使用

有机制回收access token（如存储在数据库）;
泄露不会造成大风险；
提供简单授权机制；
希望第三方应用离线访问用户数据；