1. OAuth2.0 协议基础：四种授权模式原理与适用场景

OAuth2.0 是业界标准的授权框架，允许第三方应用在用户（资源所有者）授权的前提下，获取对受保护资源（如支付订单、用户信息）的有限访问权限，而无需暴露用户的长期凭证（如密码）。理解其四种授权模式是构建安全微服务链路与支付订单接入的基石。

1.1 核心角色与授权流程

在深入模式之前，先明确 OAuth2.0 的四个核心角色：

• 资源所有者（Resource Owner）：通常指用户，拥有受保护资源（如支付记录）的访问决定权。
• 客户端（Client）：需要访问资源的第三方应用，如移动支付 App、前端 Web 应用。
• 授权服务器（Authorization Server）：负责验证用户身份并颁发访问令牌（Access Token）的中间件。
• 资源服务器（Resource Server）：托管受保护资源的服务，如订单查询 API，通过验证令牌来响应请求。

1.2 四种授权模式详解

根据客户端类型（是否机密、是否有后端服务器）和安全需求，OAuth2.0 定义了四种授权模式。下表从核心原理、令牌获取方式、安全等级和典型场景进行对比。

1.3 授权码模式（推荐用于支付安全）

授权码模式是支付订单安全接入的首选模式。其核心优势在于：令牌（Access Token）始终通过安全的服务器端通道传输，浏览器或移动端仅接触一次性的、短生命周期的授权码。

• 流程步骤：
  1. 用户访问客户端，客户端构造授权请求，将用户重定向到授权服务器。
  2. 用户登录并授权，授权服务器生成授权码，通过重定向 URL 返回给客户端。
  3. 客户端后端使用授权码 + Client Secret 向授权服务器换取 Access Token。
  4. 授权服务器验证授权码和客户端身份，返回 Access Token（和可选的 Refresh Token）。
  5. 客户端使用 Access Token 调用资源服务器 API。
• 安全要点： 授权码必须是一次性的、短时效（通常 1-5 分钟）；必须使用 PKCE（Proof Key for Code Exchange）扩展来防止授权码拦截攻击，尤其是在移动端。

1.4 隐式模式（已不推荐）

隐式模式最初为纯前端应用设计，但因其令牌直接暴露在浏览器 URL 中，存在严重的安全风险。OAuth 2.0 Security BCP（最佳实践）已明确不推荐使用隐式模式。

• 风险： 访问令牌可能被浏览器历史记录、Referer 头、中间人攻击等方式窃取。
• 替代方案： 对于 SPA，应使用授权码模式 + PKCE，通过后端代理或 BFF（Backend for Frontend）模式来安全获取令牌。

1.5 密码模式（仅限信任场景）

密码模式要求客户端直接处理用户密码，这违背了 OAuth2.0 的“不暴露凭证”核心原则。仅适用于客户端与授权服务器属于同一组织、且无法使用重定向的场景（如旧版桌面应用、迁移过渡期）。

• 限制： 客户端必须存储用户密码，增加了凭证泄露风险；不支持多因素认证（MFA）等高级安全特性。
• 支付场景： 绝对禁止在支付订单接入中使用密码模式，因为这会直接暴露用户的支付密码或登录凭证。

1.6 客户端凭证模式（服务间通信）

客户端凭证模式不涉及用户，仅用于服务到服务的通信。客户端使用自己的身份（Client ID + Client Secret）向授权服务器申请令牌。

• 典型用途： 微服务架构中，订单服务调用支付服务进行扣款；定时任务刷新缓存；API 网关内部路由鉴权。
• 安全实践： Client Secret 必须安全存储（如使用密钥管理服务、环境变量、Vault）；令牌应设置合理的有效期，并支持轮换。

1.7 模式选择决策树

在实际微服务与支付系统设计中，可参考以下决策逻辑快速选择授权模式：

• 是否有用户参与？
  • 是 → 客户端是否有后端服务器？
    • 是 → 授权码模式（推荐）
    • 否（纯前端 SPA） → 授权码模式 + PKCE
  • 否（服务间调用） → 客户端凭证模式
• 特殊场景： 遗留系统迁移或第一方高度信任应用，可谨慎使用密码模式，但必须配合 IP 白名单、设备指纹等额外安全措施。