PKCE与客户秘密

Question

如果我正在开发一个静态服务的web应用程序客户端，我需要使用隐式授权流(这不再是可取的)，或者在PKCE中使用授权代码授予流。考虑到我正在开发一个由服务器动态服务的web应用客户端，我可以在不使用OAuth 2.0的情况下利用授权代码授予流--回调和随后的令牌请求将在服务器端处理，客户端的秘密可以安全地存储在服务器上。

但是，在这种情况下，我仍然可以利用PKCE (服务器可以生成必要的代码验证器而不是客户端应用程序)。所以我的问题是，使用一种方法比另一种方法有什么好处(提供客户端机密与利用PKCE)。在这种情况下，一个比另一个更安全吗？

Answer 1

归根结底，您的授权代码是否有可能泄漏。

PKCE的目的是防止泄露的“授权代码”S发挥作用。当您请求授权代码时，PKCE要求您发送当前的散列。当您赎回代码时，您必须提供原始(未散列)当前。

这意味着，观察授权代码请求和响应的恶意参与者(XSS或CSRF漏洞)无法赎回代码，因为他们不知道当前的代码。

编辑:此外，client_secret意味着只有您的服务器可以赎回授权代码。但是，任何人都可以向您的服务器发送消息！如果授权代码被泄露，那就意味着您不知道是谁向您的服务器发送授权代码--是最初请求的人还是某个窃听应用程序？如果不检查当前，您的服务器最终可能会使用其client_secret来为窃听者赎回授权代码。

Answer 2

在OAuth 2.0安全最佳实践之后，您应该使用PKCE：

客户端必须防止攻击者将授权代码注入(重放)到授权响应中。为此，公共客户端必须使用PKCE RFC7636。对于机密客户端，建议使用PKCE RFC7636。

如果您有任何理由不使用PKCE，那么使用OpenID连接"nonce“可以是另一种选择。

使用4.5.3.2节中描述的额外预防措施，机密客户端可以使用ID令牌OpenID中的"nonce“参数和相应的声明。

这既适用于公共客户/本地应用程序/SPA，也适用于机密客户端。

注意:虽然PKCE是作为保护本地应用程序的机制设计的，但这个建议适用于所有类型的OAuth客户端，包括web应用程序。