拦截OAuth授权代码

Question

在我工作的系统中，可以通过OAuth授权代码授予来验证单个页面应用程序(带有后端)的用户，而不需要使用PKCE。

所以：

1. 用户单击登录并重定向到auth服务器。
2. 用户进行身份验证，并使用授权代码重定向回回调url。
3. 客户端将授权代码发送到后端的公共端点。
4. 后端端点提供一个客户端id和机密，以及作为访问令牌&刷新令牌的授权代码，然后在响应中将它们返回给客户端。
5. 客户机现在可以使用访问令牌向我们的API发出经过身份验证的请求。

由于步骤3中的端点是可公开访问的，那么如何阻止攻击者拦截授权代码并通过postman向端点发送请求，以便他们接收令牌而不是我们的客户端？

我的理解是，这就是为什么现在推荐使用PKCE扩展，但我不是专家。

当公共端点在客户端秘密中添加时，它类似于授权服务器根本不请求客户端机密。任何人都可以用代码调用端点，并让它将代码+秘密传递给授权服务器。

这是个弱点还是我什么都不担心？如果没有，那么为什么OAuth需要一个client_secret来授予授权代码呢？

谢谢!

Answer 1

坚持标准流和建议的做法是很好的。如果您创建了自己的流程(从您的工作中创建)，则应该由您来评估安全风险。一般来说，你做的越复杂，它就越脆弱。

因此，我更愿意使用后端启动的基本auth代码流，并直接将其重定向到后端(考虑将其用于后端会话或带有令牌的HTTP专用cookie )。在这个场景中，使用PKCE是可选的，但是如果您可以使用它，它可以提高安全级别。

或者，我可以在不涉及后端的情况下使用带有PKCE的auth代码流作为OAuth2客户端。后端将有一个资源服务器的角色。

您可能使用到您的OAuth2服务器的安全连接。在当前的实现中，缺点是浏览器。因此，如果您关注被窃取的auth代码，请将流更改为标准的auth代码流，并将后端作为OAuth2客户端。但是，如果OAuth2服务器收到具有相同auth代码的另一个/token请求(假设其中一个请求来自攻击者)，那么它应该撤销已经发出的令牌。