谁负责 OAuth 中的重定向答案

【问题标题】：Who is reponsible for redirect in OAuth谁负责 OAuth 中的重定向
【发布时间】：2020-05-09 15:02:27
【问题描述】：

使用 IdentityServer4 的 OAuth 中的重定向如何详细工作？直接调用身份服务器重定向 URL（在可能无法环回的情况下）或者浏览器是否从身份服务器以重定向作为参数获得响应并且浏览器进行重定向？

是否存在可以更改身份服务器的响应以重定向到其他站点的已知问题？这样就可以盗取验证码了。

【问题讨论】：

【解决方案1】：

IdentityServer4 在浏览器中重定向。是的，有一个已知问题是身份服务器的响应可以更改为重定向到其他站点。还有一些方法可以减轻这些风险。您可以使用 PKCE 和 nonce。

【讨论】：

我将授权代码流与 PKCE 一起使用。我认为 Nonce 仅用于隐式授权？
您也可以在授权代码流中使用 Nonce。它不像隐式授权那样是强制性的，但您也可以使用它。它可以帮助防止重放攻击。我在我的授权代码流程中使用了所有内容：PKCE、Nonce 和 State。
本质上 PKCE 是用来绑定身份验证的。代码请求到令牌请求。所以公共客户不能窃取代币。随机数用于 CSRF 攻击。 OP 关于重定向 URL 操作的原始问题目标。无论如何，他们都有一些联系。
没有任何充分的理由不实施所有这些。 PKCE稍微复杂一点，但在授权码流中是必须的，Nonce简单易实现，需要状态来恢复自己的状态，保持api无状态。

【解决方案2】：

而不是重定向到另一个恶意端点（这将暴露授权代码），更有可能拥有Cross-site request forgery (CSRF) attack。为此 OAuth 2.0 规范为您提供 state 参数 (more on this)。

关于重定向到恶意端点的可能性，为此，

第二点很难利用（但可能）。因为根据 OAuth 2.0 定义，您在 register your client 时注册重定向 URL

授权服务器将用户代理重定向到客户端的重定向端点之前建立的在客户端注册过程中或当授权服务器发出授权请求。

所以这意味着您的身份服务器已被破坏或您的注册被利用。而且您将不得不担心用户被重定向到恶意网站，这可能会提取其他重要细节而不是暴露授权代码。

攻击者可以在合法客户端创建帐户并发起授权流程。当攻击者的用户代理被发送到授权服务器授予访问权限，攻击者获取由合法客户端提供的授权 URI 并替换客户端的重定向 URI 与受控制的 URI 攻击者。然后攻击者诱使受害者跟随操纵链接以授权访问合法客户端。

【讨论】：