双向生成RSA密钥对的PKCE实现方案可行性及性能咨询

可行性与落地价值 #

你提出的「服务端、客户端各自生成RSA公私钥对实现双向校验」的思路，不属于标准PKCE规范定义的实现逻辑，本质是自定义了一套双向非对称认证流程，理论上可以跑通，但几乎没有落地价值，完全无法替代现有成熟的PKCE或OAuth2客户端认证方案。

现有流程的设计遗漏与安全缺陷 #

• 最致命的问题是完全无法防御中间人攻击。整套流程没有任何公钥身份校验机制：步骤2客户端明文上传公钥时，中间人可以直接替换成自己生成的公钥发给服务端；步骤4服务端返回加密随机值、自身公钥时，中间人再替换成自己的公钥发给客户端。后续所有加解密操作对中间人完全透明，攻击者可以全程转发、篡改内容而不被双方发现，安全性反而远低于标准PKCE——标准PKCE的code_verifier从来不会在公网信道明文传输，授权码和挑战值强绑定，中间人即使截获授权码，拿不到code_verifier也无法兑换令牌。
• 没有对齐PKCE的核心安全目标。PKCE的核心作用是防御授权码拦截攻击，校验逻辑必须和「授权请求→下发授权码→兑换令牌」的完整链路强绑定。你设计的流程是独立的密钥协商逻辑，既没有把校验结果和授权码、客户端会话上下文做绑定，也没有定义客户端密钥的生命周期规则：如果客户端固定存储公私钥对，App被反编译、终端被入侵后密钥会直接泄露；如果每次授权流程都生成新密钥对，额外的交互轮次会大幅拉长授权耗时。
• 存在明显的重放攻击风险。流程中生成的随机密钥没有绑定任何上下文标识（比如请求时间戳、会话ID、授权码哈希值），攻击者只要截获步骤5中客户端回传的、经服务端公钥加密的密文，不需要解密知道明文内容，直接重放该密文就能通过服务端校验。

计算开销评估 #

这套流程的算力开销远高于标准PKCE，完全属于不必要的性能浪费：

• 标准PKCE仅需要两端做SHA-256哈希运算，单次运算耗时在微秒级，几乎没有性能损耗，即使是低端IoT设备也能流畅运行。
• 你设计的流程中，单次授权两端各需要生成1次RSA密钥对、完成1次RSA公钥加密、1次RSA私钥解密。仅RSA 2048位密钥生成这一项操作的耗时就是哈希运算的数百倍，在服务端高并发场景下会带来非常明显的CPU压力，移动端低端设备上运行时甚至可能出现用户可感知的卡顿。且每次流程生成的RSA密钥对仅单次有效，没有任何复用价值，纯无效算力消耗。

替代方案建议 #

如果确实需要在OAuth2流程中使用非对称密钥做双向身份校验，直接用现有公开标准即可：要么基于mTLS实现双向证书认证，要么用DPoP（OAuth 2.0 持有证明）机制绑定客户端非对称密钥，这些方案已经完整解决了中间人防御、上下文绑定、重放防护的问题，所有主流授权框架都有现成实现，经过了长期公开安全审计，落地成本和安全性都远好于自定义流程。

内容的提问来源于stack exchange，提问作者Fran Turkovic