四种角色把资源与授权分开

资源所有者能够授权访问，客户端代表它请求资源，授权服务器发出令牌，资源服务器保存并提供受保护资源。同一部署可以合并部分角色，但客户端并不因名称叫“客户端”就必然只是浏览器脚本，也可以是服务器程序。

访问令牌交给资源服务器使用，授权码则通常用于向令牌端点换取令牌，两者用途不同。令牌可以带有或引用权限范围；OAuth并未要求所有访问令牌必须采用JWT格式，资源服务器怎样理解它还取决于系统采用的令牌机制。

参考：[1]

授权码流程有分开的回传与交换

在授权码流程中，客户端把用户导向授权服务器，后者进行适当认证并取得授权，再通过重定向把授权码送回客户端。客户端随后向令牌端点提交授权码，取得可用于资源请求的令牌，而不把授权码本身当作长期资源凭证。

RFC 9700要求防止授权码注入和滥用，并要求公开客户端使用PKCE；对机密客户端也建议采用PKCE。PKCE把一次授权请求与相应令牌交换绑定，不能靠给所有请求固定填写同一个挑战值来达到这种事务关联。

参考：[1] [2]

范围受限，旧流程也有新限制

scope表达请求及授予的访问范围，授权服务器可以按政策缩小它；资源服务器仍要核对令牌的目标、资源和动作。令牌成功签发或能够解码，不代表每个服务都应接受它，也不表示用户账户的全部权利已交给客户端。

2012年文档列出的流程不能都当作现行推荐。2025年安全最佳实践明确不得使用资源所有者密码凭据授权，并建议避免把访问令牌直接放在授权响应中的隐式流程，除非满足相应防护条件。OAuth本身也不提供完整的终端用户身份层，OpenID Connect另作规范。

参考：[1] [2] [3]