RFC 声称（图 1）：
(A) 客户端向资源所有者请求授权。这 可以直接向资源所有者提出授权请求 （如图所示），或者最好通过授权间接 服务器作为中介。
这是否意味着根据资源所有者的请求，不使用身份验证协议？ 或者说是什么意思？
这意味着客户端可以通过两种方式请求资源所有者凭据：
不可否认，RFC 让我有点困惑。直接与间接仅意味着正在使用不同的资助类型。
直接意味着客户端将处理资源所有者的密码凭据，将其视为授权，并通过向授权服务器发出请求来将其交换为访问令牌：
1.3.3。资源所有者密码凭证
资源所有者密码凭据（即用户名和密码） 可以直接作为授权来获取访问权限 令牌。仅当存在高风险时才应使用凭证 资源所有者和客户端之间的信任程度（例如， 客户端是设备操作系统的一部分或具有高度特权的 应用程序），并且当其他授权授予类型不是 可用（例如授权码）。
尽管这种授权类型需要客户端直接访问 资源所有者凭据，使用资源所有者凭据 对于单个请求并交换访问令牌。这 grant类型可以消除客户端存储的需要 通过交换资源所有者凭据以供将来使用 具有长期访问令牌或刷新令牌的凭据。
这不是首选，因为它需要信任客户端能够很好地管理凭证。例如，客户端不应该保留凭据，但除非您可以检查其来源，否则您无法真正知道。
间接意味着我们不相信客户端是一个好的管家，而是依赖 HTTP 重定向，这样客户端甚至永远不会看到凭据。只有用户代理才能看到输入的凭据。
来自 RFC：
客户获得授权的首选方式 来自资源所有者（如步骤 (A) 和 (B) 中所述）的方法是使用 授权服务器作为中介，如图所示 第 4.1 节中的图 3.
4.1. Authorization Code Grant
The authorization code grant type is used to obtain both access
tokens and refresh tokens and is optimized for confidential clients.
Since this is a redirection-based flow, the client must be capable of
interacting with the resource owner's user-agent (typically a web
browser) and capable of receiving incoming requests (via redirection)
from the authorization server.
+----------+
| Resource |
| Owner |
| |
+----------+
^
|
(B)
+----|-----+ Client Identifier +---------------+
| -+----(A)-- & Redirection URI ---->| |
| User- | | Authorization |
| Agent -+----(B)-- User authenticates --->| Server |
| | | |
| -+----(C)-- Authorization Code ---<| |
+-|----|---+ +---------------+
| | ^ v
(A) (C) | |
| | | |
^ v | |
+---------+ | |
| |>---(D)-- Authorization Code ---------' |
| Client | & Redirection URI |
| | |
| |<---(E)----- Access Token -------------------'
+---------+ (w/ Optional Refresh Token)
Note: The lines illustrating steps (A), (B), and (C) are broken into
two parts as they pass through the user-agent.
Figure 3: Authorization Code Flow
The flow illustrated in Figure 3 includes the following steps:
(A) The client initiates the flow by directing the resource owner's
user-agent to the authorization endpoint. The client includes
its client identifier, requested scope, local state, and a
redirection URI to which the authorization server will send the
user-agent back once access is granted (or denied).
(B) The authorization server authenticates the resource owner (via
the user-agent) and establishes whether the resource owner
grants or denies the client's access request.
(C) Assuming the resource owner grants access, the authorization
server redirects the user-agent back to the client using the
redirection URI provided earlier (in the request or during
client registration). The redirection URI includes an
authorization code and any local state provided by the client
earlier.
(D) The client requests an access token from the authorization
server's token endpoint by including the authorization code
received in the previous step. When making the request, the
client authenticates with the authorization server. The client
includes the redirection URI used to obtain the authorization
code for verification.
(E) The authorization server authenticates the client, validates the
authorization code, and ensures that the redirection URI
received matches the URI used to redirect the client in
step (C). If valid, the authorization server responds back with
an access token and, optionally, a refresh token.