Role
Role 是 OAuth 2.0 框架的重要概念，其为参与 OAuth 2.0 过程的所有组件。分为如下几种：
1）资源所有者（Resource Owner）：拥有受保护资源并可以授予对其访问权限的用户或系统。
2）客户端（Client）：客户端是需要访问受保护资源的系统。要访问资源，客户端必须持有适当的访问令牌。
3）授权服务器（Authorization Server）：该服务器接收来自客户端的访问令牌请求，并在成功验证并得到资源所有者同意后发出这些请求。授权服务器公开两个端点：授权端点（处理用户的交互式身份验证和同意）和令牌端点（参与机器对机器交互）。
4）资源服务器（Resource Server）：保护用户资源并接收客户端访问请求的服务器。它接受并验证来自客户端的访问令牌，并向其返回适当的资源。
交互流程
/1_Terms_and_Fundamentals/diagram.png)
注 1，该交互流程仅用于演示与使用，在不同的配置中，会存在额外的步骤。
0）Client 需要预先获取 Client ID 与 Client Secret 参数。
1）Client 请求 AS 并附带 Client ID、Client Secret、Scope、endpoint URI 参数。
可接受的 Scope 值以及它们与哪些资源相关，取决于 Resource Server。
2）AS 验证 Client，并判断 Client 是否能够访问 Scope 定义的范围。
3）当 AS 通过验证后，RO 与 AS 互动，RO 授予访问权限。
4）AS 重定向到客户端（假定 endpoint URI 为客户端自身），并携带 AC AT RT 参数
1）Authorization Code grant：授权服务器向客户端返回一次性授权代码，然后将其交换为访问令牌。对于可以在服务器端安全地进行交换的传统 Web 应用程序来说，这是最佳选择。授权代码流可能由单页应用程序 (SPA) 和移动/本机应用程序使用。然而，在这里，客户端秘密无法安全存储，因此在交换期间的身份验证仅限于仅使用客户端 ID。更好的替代方案是下面带有 PKCE 授予的授权代码。
2）Implicit Grant：访问令牌直接返回给客户端的简化流程。在隐式流程中，授权服务器可以将访问令牌作为回调 URI 中的参数或作为对表单发布的响应返回。由于潜在的令牌泄漏，第一个选项现已弃用。
3）Authorization Code Grant with Proof Key for Code Exchange (PKCE)：此授权流程类似于授权代码授予，但具有额外的步骤，使其对于移动/本机应用程序和 SPA 来说更加安全。
4）Resource Owner Credentials Grant Type：此授权要求客户端首先获取资源所有者的凭据，并将其传递给授权服务器。因此，它仅限于完全信任的客户端。它的优点是不涉及到授权服务器的重定向，因此适用于重定向不可行的用例。
5）Client Credentials Grant Type：用于非交互式应用程序，例如自动化流程、微服务等。在这种情况下，应用程序本身通过使用其客户端 ID 和密钥进行身份验证。
6）Device Authorization Flow：允许应用程序在输入受限的设备（例如智能电视）上使用。
7）Refresh Token Grant：涉及用刷新令牌交换新访问令牌的流程。
5）然后 Client 通过 Access Token 来访问 RS 服务。
Access Tokens and Authorization Code
Resource Owner 授权访问后，OAuth 2 Authorization Server 可能不会直接返回 Access Token。相反，为了更好的安全性，可以返回 Authorization Code，然后将 Authorization Code 交换为 Access Token。
Refresh Token
此外，Authorization Server 还可以随 Access Token 一起颁发 Refresh Token 。与 Access Token 不同，Refresh Token 通常具有较长的到期时间，并且可以在 Access Token 到期时更换为新的访问令牌。由于 Refresh Token 具有这些属性，因此客户端必须安全地存储它们。