FAPI 2.0 还是普通 OAuth：银行 API 要的究竟是哪套安全要求？
在为只写 OAuth 或 FAPI 2.0 的银行 API 需求报价前，先比较协议说法、安全属性、符合性证据与改造影响。
重点监测信号
- 依赖方写明具体 FAPI 或 OAuth Profile 及部署角色，而不是只说符合 OAuth
- 授权服务器与客户端已对 PAR、PKCE 和发送方约束令牌方法达成一致
- 符合性结果或端点测试已绑定发布环境与负责人
“符合 OAuth”和“生产环境要求 FAPI 2.0”不是同一套银行 API 要求的两个名字。OAuth 2.0 提供授权框架；FAPI 2.0 Security Profile 为高价值 API 选择并收紧相关机制，包括经客户端认证的推送授权请求、PKCE 和发送方约束 access token。 项目需要明确具体 Profile 和证据，而不是只证明 token endpoint 会返回结果。
这条差别对金融 API 身份系统售前工程师很重要。他们在已获授权的开放银行、银行开发者和身份技术 Telegram 群里看到类似消息时，晚一天可能错过符合性测试档期或集成发布；只看到 OAuth 就报价，也可能漏掉依赖方要求的授权服务器、客户端和资源服务器改造。
下面是一段用于解释的复合对话，不是真实银行请求或测试结果：
“沙箱 OAuth 登录已经通了。合作方说生产必须 FAPI 2.0。是不是改一下 scope 就行？”
对话没有给出 API 角色、授权服务器、客户端类型、Profile 版本、当前流程、客户端认证、令牌约束方法、符合性测试、失败项和生产负责人。
这不是新旧品牌之争，而是框架与受约束 Profile 的比较
RFC 6749定义 OAuth 2.0 的角色和授权方式，也有意把许多选择留给具体部署。“我们使用 OAuth”可以表示一个正常运行的 authorization code 流程，但没有说明高价值生态要求的安全属性。
OpenID Foundation 的 FAPI 2.0 Security Profile建立在 OAuth 与相关标准之上。其引言说明，该 Profile 规定客户端取得发送方约束令牌并安全访问资源服务器的过程，面向高价值应用程序编程接口（API）。银行或开放银行生态还可能增加本地规则，因此“FAPI 2.0”仍需对应具体文件、版本和当地 Profile。
| 证据问题 | 普通 OAuth 说法可以证明什么 | FAPI 2.0 Security Profile 期望什么 |
|---|---|---|
| 授权请求 | 系统支持某种 OAuth 授权流程 | authorization code 流程，并使用经客户端认证的 Pushed Authorization Requests（PAR） |
| 授权码被截取 | 由具体 OAuth 部署选择防护方式 | 使用 S256 challenge method 的 Proof Key for Code Exchange（PKCE） |
| access token 被窃 | 可能使用 bearer token | 使用双向 TLS 或 Demonstrating Proof of Possession（DPoP）的发送方约束令牌 |
| 客户端认证 | 取决于客户端与部署 | confidential client 和 Profile 指定的认证选择 |
| 验收证据 | 一个成功端点或集成测试 | Profile 指定行为，加上本生态认可的符合性证据 |
这张表并不是说普通 OAuth “不安全”，而是说明笼统 OAuth 说法无法证明更窄的 Profile。
Profile 证据还要按角色区分。客户端测试无法证明授权服务器的全部行为；授权服务器 trace 也不能证明资源服务器会拒绝缺少指定密钥或证书的被盗令牌。即使同一家供应商承担多个角色，也应分别记录客户端、授权服务器和资源服务器的证据。
沿一条授权请求检查四个位置
最短的有效差距测试不是比较产品功能表，而是跟完一条请求。
检查点一：提交授权请求
FAPI 2.0 授权服务器必须支持按 RFC 9126执行、经过客户端认证的 Pushed Authorization Requests（PAR），并拒绝没有通过 PAR 发送的授权请求。客户端先通过已认证的后端通道提交授权参数，再把返回的 request_uri 带到授权端点。
检查点二：授权码
Profile 要求使用 S256 的 PKCE，还把授权码最长有效期设为 60 秒。沙箱能跳转并返回 code，不能证明这两项都被执行。
检查点三：客户端与 access token
授权服务器只能签发发送方约束 access token，并选择 RFC 8705 的双向传输层安全（mutual TLS）或 RFC 9449 的 DPoP。客户端认证和令牌发送方约束是两个问题：例如 Profile 对客户端认证列出 mutual TLS 或 private_key_jwt，而对令牌约束列出 mutual TLS 或 DPoP。
检查点四：资源请求与验收证据
资源服务器要按选定方法验证令牌及其发送方约束。之后，团队还要提供合作方认可的证据对象：符合性测试结果、端点 trace、认证记录或生态专用测试。一次本地 smoke test 不能被写成认证。
Passkey 回退场景处理的是身份验证恢复，而不是 API 授权；SOC 2 入驻证据文章说明了如何把保证要求绑定到对方真正接受的记录。
从第一个失败检查点确定改造范围
如果 PAR 缺失，项目可能涉及授权服务器 metadata、PAR endpoint、客户端认证和请求方式。如果 PKCE 已有，但令牌仍是 bearer-only，主要工作可能变成密钥或证书生命周期以及资源服务器验证。如果运行时行为全部通过，但合作方拒绝现有证据，项目可能只需补测试和符合性材料，而不是重做协议。
TOP Prospect 可以合并用户主动连接且有权访问的 Telegram 群片段，保留原文、来源和时间，删除明显重复，并把候选需求排进人工复核队列。它不能检查端点、持有客户端密钥、运行银行的符合性测试、认证 FAPI，也不能替生态选择 Profile。价格页说明了发现边界。支付 BD 文章处理的是商户需求，不是协议证据。
回到开头那段沙箱对话。只有请求、授权码、令牌和资源服务器四个检查点已经满足对方点名的生产 Profile，“只改 scope”才有可能成立。任何一项失败，都应围绕那个对象和负责人划定项目。真正要比较的不是 OAuth 与 FAPI 两个产品，而是现有端点证据与依赖方要求的安全属性。
常见问题
FAPI 2.0 会取代 OAuth 2.0 吗？
不会。它建立在 OAuth 2.0 与相关标准上，通过收窄选择和增加要求来保护高价值 API。
成功拿到 OAuth access token 就证明符合 FAPI 2.0 吗？
不能。它没有证明 PAR、S256 PKCE、发送方约束令牌和其他 Profile 行为。
FAPI 2.0 必须使用双向 TLS，不能使用 DPoP 吗？
不是。Profile 允许双向 TLS 或 DPoP，但各自还有详细要求。
什么情况下可以为实施项目报价？
至少写明角色、Profile 版本、令牌约束方法、证据、环境、失败测试和发布负责人。
常见问题
FAPI 2.0 会取代 OAuth 2.0 吗？
不会。FAPI 2.0 Security Profile 建立在 OAuth 2.0 和相关标准上，通过收窄选择并增加要求来保护高价值 API。
成功拿到 OAuth access token 就证明符合 FAPI 2.0 吗？
不能。令牌响应成功不能证明系统使用了经客户端认证的推送授权请求、S256 的 PKCE、发送方约束令牌、签发者检查以及所选 Profile 的其他要求。
FAPI 2.0 必须使用双向 TLS，不能使用 DPoP 吗？
不是。Security Profile 允许按 RFC 8705 使用双向 TLS，或按 RFC 9449 使用 DPoP 来约束 access token 的发送方，但仍需满足相应服务器与客户端要求。
什么情况下可以为实施项目报价？
至少写明 API 角色、授权服务器、客户端类型、Profile 与版本、发送方约束方法、符合性证据、环境、失败测试和发布负责人。
资料来源与延伸阅读
值得关注的潜在线索 Signal 是怎样被发现的
了解 Top商业线索怎样发现和整理值得核实的 Signal、保留 Telegram 原始上下文、去掉重复消息并安排查看顺序。是否跟进以及下一步做什么，仍由用户决定。
