2. OAuth2.0核心角色：资源所有者、客户端、授权服务器、资源服务器的定义与职责
OAuth2.0协议定义了四个核心角色，它们之间的交互构成了整个授权框架的基础。理解每个角色的定义、职责以及它们之间的边界，是设计安全API契约的第一步。任何角色职责的混淆都可能导致授权绕过或凭据泄露。
2.1 角色总览与交互关系
四个角色在授权流程中各自承担明确的职责，并通过标准化的HTTP请求与令牌传递进行协作。下图展示了它们之间的核心交互关系：
架构要点： 在微服务架构中，授权服务器和资源服务器通常是独立的服务实例。授权服务器负责令牌的生命周期管理，资源服务器负责保护具体的业务API。这种分离使得安全策略可以集中管控，而业务服务只需关注令牌验证。
2.2 角色定义与职责详解
下表从定义、核心职责、典型实现和关键约束四个维度，对四个角色进行对比分析：
| 角色 | 定义 | 核心职责 | 典型实现 | 关键约束 |
|---|---|---|---|---|
| 资源所有者 | 能够授予对受保护资源访问权限的实体。通常是最终用户。 |
|
浏览器中的用户、移动App用户、IoT设备管理员 | 不直接与客户端共享凭据；授权行为可撤销 |
| 客户端 | 代表资源所有者发起受保护资源请求的应用程序。 |
|
Web前端、移动App、后端服务、单页应用 | 不能存储资源所有者凭据；必须保护客户端凭据（如client_secret） |
| 授权服务器 | 颁发访问令牌给经过认证的客户端。 |
|
Keycloak、Auth0、Spring Authorization Server、自建OAuth2服务 | 必须使用TLS；令牌签名密钥需安全存储；支持令牌撤销 |
| 资源服务器 | 托管受保护资源的服务器，能够接受和响应携带访问令牌的请求。 |
|
RESTful API服务、微服务网关、文件存储服务 | 不颁发令牌；必须与授权服务器同步令牌验证逻辑 |
2.3 角色边界与安全隔离原则
OAuth2.0协议的核心安全价值在于严格的角色隔离。以下原则是API契约治理中必须遵守的底线：
- 凭据隔离： 资源所有者（用户）的密码、生物特征等凭据，只能提交给授权服务器。客户端应用程序在任何情况下都不应获取或存储用户凭据。
- 令牌隔离： 访问令牌是客户端访问资源的唯一凭证。资源服务器不应自行颁发令牌，也不应依赖用户凭据进行授权。
- 验证隔离： 资源服务器必须通过授权服务器提供的令牌验证机制（如JWT签名验证、Introspection API）来确认令牌有效性，不能自行假设令牌可信。
- 授权决策隔离： 授权服务器负责决定“谁可以访问什么”，资源服务器负责执行“当前令牌是否允许此请求”。两者职责不可混淆。
常见反模式： 在微服务实践中，部分团队将授权逻辑直接写在业务服务中，导致资源服务器同时承担了授权服务器的职责。这种设计破坏了角色隔离，使得令牌验证策略难以统一更新，且容易因实现不一致引入安全漏洞。正确的做法是将令牌验证逻辑抽象到API网关或独立的授权中间件中。
2.4 角色在微服务架构中的映射
在微服务架构中，OAuth2.0角色的物理部署通常如下：
- 资源所有者： 终端用户，通过浏览器或移动App操作。
- 客户端： 前端应用（SPA、移动App）或BFF（Backend For Frontend）层。
- 授权服务器： 独立部署的认证授权中心，如Keycloak集群或云服务（Auth0、Okta）。
- 资源服务器： 各个业务微服务（订单服务、用户服务、支付服务），通常通过API网关统一接入令牌验证。
下图展示了在微服务网关模式下，角色之间的典型通信路径：
API契约治理实践： 在定义API契约时，每个资源服务器的接口文档中必须明确声明所需的scope和令牌类型。例如，
POST /api/orders 需要 scope: write:orders，且仅接受Bearer令牌。授权服务器根据这些契约配置客户端权限，形成从“授权决策”到“资源访问”的完整契约链路。
2.5 角色职责速查清单
以下清单可用于API契约评审和安全审计，快速检查角色职责是否被正确分配：
- 资源所有者： 是否只能通过授权服务器进行认证？客户端是否直接收集了用户密码？
- 客户端： 是否使用授权码模式（Authorization Code）而非隐式模式？client_secret是否安全存储？是否实现了PKCE？
- 授权服务器： 是否支持令牌撤销？是否提供Introspection端点？令牌签名算法是否为RS256或更优？
- 资源服务器： 是否在每次请求时验证令牌签名和有效期？是否检查了scope和audience？是否缓存了公钥？