OAuth 2.0 是行业标准的授权协议，OAuth 2.0 专注于客户端开发人员的简单性，同时为 Web 应用程序、桌面应用程序、移动电话和直播间设备提供特定的授权流程。
一、角色
OAuth2.0定义了4个角色： 资源所有者（resource owner）：能够授予对受保护资源的访问权限的实体。当资源所有者是一个人时，它被称为终端用户 资源服务器（resource server）：托管受保护资源的服务器，能够使用access token接收和响应受保护资源的请求 客户端（client）：代表资源所有者并经其授权发出受保护资源请求的应用程序 授权服务器（authorization server）：在成功验证资源所有者后并向客户端颁发access token
角色之间的交互如下：
流程不复杂，授权的目的是获取到access token，通过access token来访问服务器资源
二、授予授权
授予授权代表资源所有者通过客户端获取一个access token的凭证，OAuth2.0定义了4钟授权类型：授权码（authorization code），隐式授权（implicit），资源所有者密码凭证（resource owner password credentials），客户端凭证（client credentials）
授权码：授权码是通过授权服务器获取的，作为客户端和资源所有者之间的中介，客户端通过授权码让资源所有者访问授权服务器
隐式授权：隐式授权是一种简化的授权码流程，主要是给浏览器使用的
密码凭证：比如使用账号和密码来获取access token
客户端凭证：仅限在客户端控制下的受保护资源时，或对先前经授权安排的受保护资源服务器时，可以通过客户端凭证授予授权
三、Access Token
OAuth访问令牌是OAuth 客户端用来向资源服务器发出请求的字符串，access token没有固定格式，可以是bearer tokens或者 sender-constrained token，sender-constrained token要求客户端以某种方式证明拥有私钥才能使用访问令牌，这样access token本身就无法使用，bearer tokens是一串不透明的字符串，一些服务器会使用一串16进制的字符来制作access token。
发布access token
如果access token请求是合法且允许授权，那么就可以发布access token，一个成功的响应（status=200）如下：
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"example",
"expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
"example_parameter":"example_value"
}
access_token：必须 token_type：token的类型，"bearer" token或者是"mac” token，datatracker.ietf.org/doc/html/rf… expires_in：建议，有效期，如3600表示access token可存活一小时 refresh_token：可选 scope：可选，由授权服务器定义的字符串，如果客户端在请求授权时省略了scope参数，授权服务器必须要么 使用预定义的默认值处理请求，要么使请求失败，指示无效范围。如果客户端传了scope参数，授权服务器应该记录其范围要求和默认值。
失败的响应如下：
HTTP/1.1 400 Bad Request
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"error":"invalid_request"
}
error还可以描述：invalid_client、invalid_grant、unauthorized_client、unsupported_grant_type、invalid_scope
四、Refresh Token
Refresh Token主要用来刷新access token，access token一般会有一个有效期，Refresh Token也会有一个有效期，一般前者的有效期是小于后者的有效期的，这样如果access token过期了，我们可以使用Refresh Token重新获取新的access token。刷新过程如下：
(1) 客户端通过与授权服务器进行身份验证并提供授权许可来请求access token。 (2) 授权服务器对客户端进行身份验证并验证授予授权，如果有效，则返回access token和一个refresh token。 (3) 客户端通过提供access token向资源服务器发出受保护的资源请求。 (4) 资源服务器验证access token，如果有效，则为请求提供服务。 (5) 重复步骤 (3) 和 (5) 直到access token过期。如果客户端知道access token过期，则跳到步骤（7）；否则，它会发出另一个受保护的资源请求。 (6) 由于access token无效，资源服务器返回无效token错误。 (7) 客户端通过向授权服务器进行身份验证并提供refresh token来请求新的access token。客户端身份验证要求基于客户端类型和授权服务器策略。 (8) 授权服务器对客户端进行身份验证并验证refresh token，如果有效，则发出新的access token（以及，optional refresh token）。
五、Authorization Code授权
Authorization Code授权类型既可以获取access token，也可以获取refresh token
由于这是基于重定向的流程，因此客户端必须能够在资源拥有者的代理（通常是web浏览器）和来自授权服务器的请求之间交互，也就是必须能够充当中介的作用。
(1) 客户端通过将资源所有者的用户代理定向到授权端点来启动流程。客户端包括其标识符、请求的范围、本地状态和授予（或拒绝）访问权限，授权服务器会将用户代理发送回 URI
(2) 授权服务器验证资源所有者（通过用户代理）并确定资源所有者是允许还是拒绝客户端的访问请求。
(3) 假设资源所有者授予访问权限，授权服务器使用之前提供的重定向 URI，将用户代理重定向回客户端。重定向 URI，包括授权代码和客户端之前提供的任何本地状态。
(4) 客户端通过包含在上一步中收到的授权码，从授权服务器的令牌端点请求access token。发出请求时，客户端向授权服务器进行身份验证。客户端包含用于获取授权的重定向 URI验证码。
(5) 授权服务器对客户端进行身份验证，验证授权码，并确保接收到的重定向 URI与步骤 (3)中用于重定向客户端的 URI 匹配。如果有效，授权服务器将返回access token和optional refresh token。
六、访问受保护资源
客户端通过access token访问受保护资源，而资源服务器必须验证access token的有效期和所覆盖的资源范围。
七、飞书的移动应用登录-OAuth2.0实现
第一步：获取 code
第二步：获取 access_token
第三步：获取用户身份信息
第四步：刷新已过期的 access_token
参考：
