1.1. Roles 角色

OAuth 定义了四个角色：

• resource owner 资源拥有者:

一个实体，其能够授予受保护的资源的访问权限。当 resource owner 是一个人，他被称之为一个终端用户。

• resource server 资源服务器

一个服务，其托管受保护的资源，能够接受并响应使用 access token 进行受保护资源的请求。

• client 客户端

一个应用，代表资源拥有者发出受保护资源的请求，并使用其授权。术语 “client” 并不表示任何特别的实现特征（例如，不论该应用在服务器，桌面，或者其他设备上执行）。

• authorization server

一个服务，在成功认证了 并获得了授权之后，颁发 access_token 给 client。

OAuth 定义了四种授予类型:

• authorization code，授权码
• implicit，隐藏式
• resource owner password credentials，密码
• client credentials，凭证式

authorization code

企业微信的授权与 code 很类似，但有所不同。企业微信 code 并不是换取 access_token，而是换取 userid。也就是，一般的 OAuth2，code 与 user 有关联，code 换取的 access_token 与 user 也有关联，用户可以通过 access_token 访问自己权限下的信息。

resource owner password credentials，密码

A 网站直接要求用户提供 B 网站的用户名和密码。拿到之后，A 直接向 B 请求令牌。

client credentials，客户端凭证式

适用于没有前端的命令行应用。

这种方式给出的令牌，是针对第三方应用的，而不是针对用户的，即有可能多个用户共享同一个令牌。

企业微信的 access_token 获取类似于这种方式

(A) client 通过将 resource owner 的 user-agent 重定向到 authorization 后端，开始流程。client 包含它的 client identifier，requested scope，local state，以及一个 redirection uri，一旦授权（或者拒绝）该访问，授权服务器会把 user-agent 发回该 uri。

client 可以认为是第三方应用的页面（上面具有一个授权按钮），用户点击该按钮，就会跳转到授权服务器，同时会附带一些参数。

(B) 授权服务器认证 resource owner，并确定 resource owner 是授权还是拒绝 client 的范围请求。

(C) 假设 resource owner 授权访问，授权服务器使用之前提供的 redirection uri 将 user-agent 重定向回 client。redirection uri 包含 authorization code 以及之前 client 提供的任何本地状态。

code 的实现可以是 UUID、UUID+MD5 等

(D) client 通过前面步骤获得的 authorization code 从授权服务器的 token 后端请求 access token。当发出请求时，client 使用授权服务器认证。client 包含 redirection URI ，用于获取进行验证的授权码。

(E) 授权服务器认证客户端，验证授权码，确保接受到的 redirection URI

10. Security Considerations

10.4. Refresh Tokens

Authorization Server 可以（MAY）给 Web 应用客户端和本地应用客户端颁发 Refresh Token。

Refresh Token 必须（MUST）在运输和存储的过程中保密，并且仅仅在 Authorization Server 和颁发了 Refresh Token 的客户端之间共享。Authorzation Server 必须（MUST） 维护 Refresh Token 和颁发了 Refresh Token 的客户端之间的绑定关系。Refresh Token 必须（MUST）只能使用 TLS 传输。??

每当客户身份可以验证时，Authorzation Server 必须（MUST）验证 Refresh Token 和客户身份之间的绑定关系。当无法进行客户端认证时，Authorization Server 应当（SHOULD）调配其他方案，以检测 Refresh Token 滥用。

例如，Authorization Server 可以使用 Refresh Token 循环，每个 access Token 刷新响应就在循环中颁发一个新的 Refresh Token。前一个 Refresh Token 失效，但是还会被 Authorization Server 保留。如果一个 Refresh Token 被渗透了，随后都被攻击者和合法客户端使用，其中一个会出现无效的 Refresh Token，它将告知授权服务器违规。

授权服务器必须确保 Refresh Token 不能被生成，篡改，或者猜测以生成有效的刷新令牌。