为什么OAuth2.0需要授权令牌，可否省略授权码兑换令牌步骤

+----------+
| 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)

问题一：为什么OAuth2.0需要使用授权令牌？ #

• 隔离用户核心凭证：不需要将用户的账号密码等敏感认证信息提供给第三方客户端，从根源上避免用户凭证大范围泄露的风险；同时令牌可单独配置权限范围、有效期，即便出现泄露，影响范围和时效都可控。
• 实现服务解耦：资源服务器只需要校验令牌的有效性即可完成鉴权，不需要和授权服务器共享用户的全量认证数据，适配跨业务、跨平台的权限管控需求。
• 降低传输泄露风险：授权码走前端用户代理（浏览器）链路传递，本身是一次性、超短时效的，就算被浏览器历史、站点日志、Referer记录，没有客户端密钥也无法兑换为有效令牌；而令牌走客户端后端与授权服务器的直连链路传递，不会暴露在前端公开链路中，安全性更高。

问题二：步骤C环节授权服务器能否直接向重定向URI发起POST请求返回Access Token，省略D、E步骤？ #

不能，核心原因如下：

• 兼容性极差：该方案仅支持有公网可访问服务端的Web应用，移动端APP、本地桌面应用、无后端的单页应用都没有能力接收授权服务器主动发起的POST请求，完全不符合OAuth2.0适配多端场景的设计目标。
• 缺少客户端身份校验能力：现有流程中步骤D、E要求客户端携带授权码+客户端凭证（密钥/签名等）主动请求兑换令牌，授权服务器可直接校验客户端的身份合法性；如果授权服务器主动发令牌，无法确认重定向URI对应的接收方是正规注册的合法客户端，攻击者只要伪造授权请求把重定向URI改成自己的地址，就能直接骗取令牌，完全没有防护能力。
• 不符合用户感知要求：现有授权流程所有跳转都在用户的浏览器中完成，用户可明确感知到自己完成授权后回到了目标客户端站点；如果授权服务器后台静默发POST请求，用户完全不知道令牌是否被发送到非法站点，出现安全问题也无法及时感知。

内容的提问来源于stack exchange，提问作者Zelin