1. OAuth2.0协议概述：核心概念、角色定义、令牌类型、授权流程全景、支付场景适用性
1.1 核心概念：什么是OAuth2.0
OAuth2.0 是一套授权委托协议，它允许一个应用（客户端）在资源拥有者（用户）的许可下，安全地访问资源服务器上受保护的资源，而无需直接暴露用户的长期凭证（例如密码）。在支付SDK场景中，OAuth2.0 是第三方商户应用请求支付授权、获取用户支付令牌的基础机制。
关键洞察： OAuth2.0 的核心是“分离权限与身份”——访问令牌只代表授权范围，不代表用户身份；支付场景中尤其需要区分“谁授权”与“能做什么”。
1.2 角色定义
| 角色 | 支付场景中的对应实体 | 职责 |
|---|---|---|
| 资源拥有者（Resource Owner） | 支付用户（付款方） | 拥有资金/卡券资源，决定是否授权第三方应用代扣、查询余额等操作 |
| 客户端（Client） | 商户App / 支付SDK集成方 | 代表用户请求授权，获取并保管令牌，发起支付请求 |
| 授权服务器（Authorization Server） | 支付平台（如微信支付、支付宝）授权中心 | 验证用户身份、颁发授权码、发放访问令牌和刷新令牌 |
| 资源服务器（Resource Server） | 支付平台资源API（如查询余额、发起扣款） | 校验令牌有效性，返回受保护的资源（支付结果、账户信息） |
支付SDK常见角色映射： 商户App既是“客户端”也是“资源拥有者代理”；支付平台同时承担“授权服务器”和“资源服务器”的角色。
1.3 令牌类型
- 授权码（Authorization Code）：临时代码，有效期短（通常5分钟），用于换取访问令牌；适用于有后端服务的商户App。
- 访问令牌（Access ）：核心凭证，代表用户授予的权限；在支付API调用中随请求发送（通常放在HTTP Authorization头中）。
- 刷新令牌（Refresh ）：长期凭证（但可撤销），用于在访问令牌过期后获取新令牌，避免用户频繁授权。
- Bearer令牌：按RFC 6750定义的令牌类型，持有即使用；支付SDK必须通过TLS保护传输。
1.4 授权流程全景（以授权码模式为例）
1.5 支付场景适用性分析
OAuth2.0 在支付SDK中主要解决以下问题：
- 免密代扣：用户授权后，商户可在限额内自动扣款，无需再次输入密码。
- 多端统一授权：同一用户在不同设备（手机、平板、Web）上均可通过OAuth令牌关联同一支付账户。
- 令牌生命周期管理：刷新令牌使支付SDK能够在令牌过期时静默续期，保证用户体验。
- 最小权限原则：支付平台可为不同应用颁发不同范围的令牌（如仅可扣款、不可查询余额）。
1.6 常用类比：酒店房卡
把OAuth2.0想象成入住酒店：
- 用户 = 住客，拥有房间资源。
- 前台（授权服务器）验证住客身份后，发放一张房卡（访问令牌）。
- 清洁工（客户端）持有房卡，只能在规定时间（范围）内进入房间（资源），且无法打开其他房间。
- 房卡过期后，住客可去前台续期（刷新令牌），或重新办卡。
常见误区： 不要将访问令牌视为用户身份。在支付场景中，令牌只代表“允许执行某些操作”，不代表“该操作由谁授权”。例如，一个商户App的访问令牌可能被泄露，攻击者只能用它做授权范围内的事，但无法冒用用户身份登录。
1.7 练习题
- OAuth2.0中的“授权码”和“访问令牌”在支付场景中分别有什么不同有效期和用途？
- 如果商户App没有后端服务器（纯前端/移动端），应当使用哪种OAuth2.0授权模式？为什么需要PKCE？
- 请说明为什么支付SDK通常不允许客户端直接使用“资源拥有者密码凭证”模式（password grant）？
1.8 应用边界
| 适用边界 | 说明 |
|---|---|
| 适用 | 需要用户明确授权的支付操作（如首次绑定、自动扣款签约、查询账户信息）。 |
| 不适用 | 无用户参与的纯服务端支付（如退款、对账、平台内部转账），应使用或JWT认证。 |
| 边界注意 | 令牌撤销机制：用户解绑或注销后，支付平台必须立即撤销相关令牌，防止滥用。 |
| 安全红线 | 访问令牌绝不能通过URL参数传递，必须使用Authorization Header；刷新令牌应存储在后端安全存储中。 |
进阶提示： 支付SDK往往在OAuth2.0基础之上叠加“支付密码”或“生物识别”作为第二因子，提高资金安全级别。OAuth2.0仅处理授权层，不处理交易层签名。