公钥加密是否可以用于保护此 OpenId Connect 工作流程的最后一站

Question

• 桌面客户端
• 受保护的资源服务器
• 授权服务器 (Google)
• 用户代理（浏览器）

---

1. Desktop Client 生成 Pub/Priv 密钥对，并将带有 webbrowser.open_new() 的用户代理定向到 Protected Resource Server OAuth 启动页面，该页面将 Public Key 存储在 Auth_URI 重定向的 State 参数字段中。
2. User-Agent 使用 Authorization Server 成功进行身份验证，并在 state 参数字段中使用 Auth_Code 和 Public Key 重定向回 Protected Resource Sever。
3. Protected Resource Server 使用机密客户端密钥交换 Auth_Code 并验证 id_token。
4. 如果 id_token 有效（发生服务器端处理），则它会在环回时重定向到侦听 Desktop Client，其中查询参数包含仅可由启动应用程序访问的加密值。

这是一个与 PKCE 非常相似的过程，但我让客户端机密在服务器上保持机密，而不是将其嵌入到 Desktop Client 中。

我担心一个恶意的第 3 方应用程序能够拦截初始 OAuth_URI 重定向并修改其值。一旦设备/浏览器受到威胁，这是否是可以减轻的威胁？ PKCE 会遇到同样的问题，我没有看到任何解释提到我的担忧是一个特定的问题，所以我假设它很好。

Answer 1

重定向篡改

针对恶意重定向篡改的标准保护在这些新兴标准中：

• PAR
• JAR
• JARM

在高度安全的情况下，您可能需要遵循 profiles 强制执行其中一些 - 一些配置文件可能包含金融级建议，例如 FAPI 2.0 Client Requirements，其中包括 PAR。

桌面应用程序

桌面应用程序的一个已知问题是恶意应用程序可以发送相同的客户端 ID 并使用相同的重定向 URI 来触发完整的流程。我认为您无法完全避免这种情况，任何努力都可能只是混淆视听。

您担心的可能是这个问题，目前无法解决，因为您的应用运行的任何代码也可能被恶意应用运行，包括使用 PAR / DPop 或其他高级选项。

客户证明

您所追求的行为是client attestation，在这种情况下，恶意方无法在不以加密方式证明其身份的情况下尝试身份验证。例如，iOS 应用可以发送其 App Store 签名密钥的所有权证明。

移动和网络应用程序可以通过拥有基于 HTTPS 的重定向 URI 的域来实现合理数量的客户端证明，但这些不能用于桌面应用程序。很高兴能在不久的将来看到改进的桌面应用客户端证明选项。

怎么办？

一般来说，我会说根据经过专家审查的标准保留您的代码。这应该意味着您在某些地方使用库，但您的代码仍然很简单。

此外，您的桌面应用程序将与其他桌面应用程序一样安全，而无需尝试解决此问题。此外，如今用户被社会化为不再运行任意 EXE，而只运行正确签名的应用程序，其代码签名证书可识别他们并链接到已批准该应用程序的机构（我们希望如此）。