OAuth2原生应用回环重定向是否存在安全攻击向量？

场景背景 #

基于OAuth 2.0授权码流程+PKCE，采用回环重定向URI的Windows原生WPF客户端应用，涉及以下参与者：

• MyApp：合法WPF应用，客户端ID为MyApp-ClientId，请求权限范围MyAppScope，重定向URI为http://localhost:5000，属于公开客户端，无需客户端密钥
• MaliciouseApp：试图窃取令牌的恶意应用
• MyAppUser：授权资源访问的用户

合法授权流程 #

• MyApp在http://localhost:5000注册监听器
• MyApp使用MyApp-ClientId发起授权流程
• MyAppUser登录授权服务器并确认允许MyApp-ClientId访问MyAppScope
• 授权服务器用singlesignon Cookie存储用户登录状态
• 针对MyAppScope的授权在服务器端保留30天
• 授权服务器重定向至http://localhost:5000，MyApp注销监听器
• MyApp使用授权码换取访问令牌（ACCESS_TOKEN）

恶意攻击流程 #

• MaliciouseApp在http://localhost:5000注册监听器
• MaliciouseApp使用MyApp-ClientId发起授权流程
• MyAppUser已通过singlesignon Cookie保持登录状态
• 授权服务器已存在MyApp-ClientId对MyAppScope的有效授权
• 授权服务器重定向至http://localhost:5000，MaliciouseApp注销监听器
• MaliciouseApp尝试使用获取到的授权码换取访问令牌

攻击可行性与关键安全机制说明 #

这个攻击向量不可行，核心原因是遗漏了PKCE流程中的核心校验机制：

1. PKCE的code_verifier与code_challenge校验
   合法应用发起授权请求时，会生成随机的code_verifier，通过哈希算法（如SHA-256）生成code_challenge，并将code_challenge和哈希方法随授权请求发送给服务器。
   换取令牌时，应用必须提交对应的code_verifier，服务器会重新计算哈希值与存储的code_challenge比对，只有匹配才会颁发令牌。
   恶意应用即便抢到了重定向过来的授权码，也没有合法应用发起请求时生成的code_verifier，在令牌换取步骤会被服务器直接拒绝。

2. 端口占用冲突的防护（次要机制）
   Windows系统中，http://localhost:5000的端口同一时间只能被一个进程绑定。如果合法应用已经占用该端口，恶意应用无法重复绑定；反之恶意应用先绑定的话，合法应用启动时会报错，用户能直接察觉到异常。

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