这是我参与8月更文挑战的第2天，活动详情查看：8月更文挑战
RFC 6749
OAuth2.0的标准是RFC 6794 文件。该文件对OAuth有详细的解释。
角色
RFC 6794文件中定义了四种角色
资源所有者(resource owner)
资源的拥有者，只需要对客户端允许或拒绝授权。
资源服务器(resource server)
即服务提供商存放用户生成的资源的服务器。给客户端提供注册接口和开放资源的接口。它与授权服务器，可以是同一台服务器，也可以是不同的服务器。
客户端(client)
客户端就是向资源服务器发请求获取资源和向授权服务器发出授权请求。
授权服务器(authorization server)
成功后，授权服务器向客户端发出访问令牌，验证资源所有者并获取授权。
流程
sequenceDiagram
Client(客户端)->>Resource Owner(资源拥有者): ① Authorization Request
Resource Owner(资源拥有者)-->>Client(客户端): ② Authorization Grant
Client(客户端)->>Authorization Server(授权服务器): ③ Authorization Grant
Authorization Server(授权服务器)-->>Client(客户端): ④ Access Token
Client(客户端)->>Resource Owner(资源拥有者): ⑤ Access Token
Resource Owner(资源拥有者)-->>Client(客户端): ⑥ Protect Resource
① 用户打开客户端以后，客户端要求用户给予授权。
② 用户同意给予客户端授权。
③ 客户端使用上一步获得的授权，向认证服务器申请令牌。
④ 认证服务器对客户端进行认证以后，确认无误，同意发放令牌。
⑤ 客户端使用令牌，向资源服务器申请获取资源。
⑥ 资源服务器确认令牌无误，同意向客户端开放资源。
四种授权模式
注意：不管哪一种授权方式，第三方应用申请令牌之前，都必须先到系统备案，说明自己的身份，然后会拿到两个身份识别码：客户端 ID（client ID）和客户端密钥（client secret）。这是为了防止令牌被滥用，没有备案过的第三方应用，是不会拿到令牌的。
授权码(authorization-code)
授权码模式是功能最完善，流程最严密，安全性最好的授权模式。这种模式和其他模式的最大区别，是授权过程中，由客户端的后台服务器端参与，即要求客户端是有后台服务器端处理能力的服务。授权码通过前端传送，令牌则是储存在后台服务器，而且所有与资源服务器的通信都在后台服务器完成。这样的前后端分离，可以避免令牌泄漏。
隐藏式(implicit)
隐含模式授权过程不需要后台服务器端参与，直接在浏览器中向授权服务器申请令牌，跳过了"授权码"这个步骤。所有步骤在浏览器中完成，令牌对访问者是可见的，且客户端不需要认证。有些 Web 应用是纯前端应用，没有后端。这时就不能用上面的方式了，必须将令牌储存在前端。RFC 6749 就规定了这种方式，允许直接向前端颁发令牌。
密码式(password)
资源所有者密码凭据模式中，用户向客户端提供自己的用户名和密码。客户端使用这些信息，向授权服务器索要授权。
如果你高度信任某个应用，RFC 6749 也允许用户把用户名和密码，直接告诉该应用。该应用就使用你的密码，申请令牌。
客户端凭证(client credentials)
客户端模式应用于客户端自己想要与授权服务器以及资源服务器进行互动。
令牌
访问令牌(Access Token)
访问令牌是用于访问受保护资源的凭据。一个访问令牌是一个字符串，表示颁发给客户。该字符串通常对客户端不透明。代表访问的特定范围和持续时间，由资源所有者，由资源服务器强制执行并授权服务器。
刷新令牌(Refresh Token)
假如访问令牌无效或者过期，刷新令牌是用于刷新访问令牌的凭据。刷新令牌由授权服务器颁发给客户端，发布刷新令牌是可选的授权服务器。如果授权服务器发出刷新令牌，它在发布访问令牌时包含在内刷新令牌是一个字符串，表示授予给资源所有者的客户端。
