Postwoman项目中OAuth 2.0 PKCE授权流程的实现问题分析

Postwoman项目（现更名为Hoppscotch）是一个开源的API开发工具，它提供了OAuth 2.0授权功能支持。然而，在实际使用中发现其OAuth 2.0实现存在一个关键问题：不支持PKCE（Proof Key for Code Exchange）授权码流程。

PKCE授权流程简介

PKCE是OAuth 2.0的一个扩展，专门为公共客户端（如单页应用、移动应用等）设计的安全增强机制。它通过以下方式工作：

1. 客户端生成一个随机字符串（code_verifier）
2. 对该字符串进行哈希转换（code_challenge）
3. 在授权请求中包含code_challenge
4. 在获取令牌时提供原始的code_verifier

这种机制可以防止授权码被截获后用于获取访问令牌，特别适用于无法安全存储客户端密钥的场景。

Postwoman中的实现问题

Postwoman当前的OAuth 2.0实现存在两个主要问题：

1. 强制要求客户端密钥：即使在PKCE流程中，系统也会强制要求提供客户端密钥（client_secret），并将"undefined"作为值发送。这与PKCE的设计初衷相违背，因为PKCE正是为了不需要客户端密钥的场景而设计的。

2. 验证逻辑缺陷：输入验证存在时序问题，只有在浏览器刷新后才会正确执行验证。这导致用户可能在未填写必要字段的情况下尝试生成令牌。

技术影响分析

这个问题在使用Azure AD（现为Microsoft Entra ID）等身份平台时尤为明显。这些平台会明确拒绝包含客户端密钥的PKCE请求，返回"Client is public so neither 'client_assertion' nor 'client_secret' should be presented"的错误。

从安全角度看，强制要求公共客户端提供密钥实际上降低了安全性，因为开发者可能会将密钥硬编码在客户端代码中，这明显违反了OAuth 2.0的安全最佳实践。

解决方案建议

要解决这个问题，需要对Postwoman的代码进行以下修改：

1. 条件性验证：在PKCE流程中，应将客户端密钥设为可选而非必填字段。

2. 参数动态处理：只有在用户实际提供了客户端密钥时，才将其包含在令牌请求中。

3. 验证流程优化：修复输入验证的时序问题，确保在首次尝试生成令牌时就能正确验证所有必填字段。

这些修改将使得Postwoman能够正确支持PKCE流程，同时保持与各种OAuth 2.0提供商（包括Azure AD）的兼容性。

总结

Postwoman作为一个API开发工具，正确实现OAuth 2.0的各种流程至关重要。特别是PKCE这种专为公共客户端设计的安全流程，应该得到完整支持。通过上述修改，可以显著提升工具在OAuth 2.0授权方面的功能和安全性，为开发者提供更完善的API测试体验。