Azure ad b2c 为什么在Azure AD B2C中重定向URL是完全限定的？

为什么必须完全匹配？域级别的匹配不足以保证适当的安全性吗

如果我有几百条路呢

示例URL：

我必须在我的B2C应用程序配置中输入上述4个重定向URL。

所有身份验证请求都包含两个重定向URL是常见的（也是最简单的）：

在“redirect_uri”参数中传递的一个（通常称为回复URL），必须向Azure AD B2C注册，所有身份验证响应都将从Azure AD B2C返回到依赖方应用程序。这方面的一个例子是

https://www.myawesomesite.com/oidc-signin

另一个（通常称为返回URL）在“state”参数中往返，不必向Azure AD B2C注册，最终用户在依赖方应用程序处理身份验证响应后返回。这方面的一个例子是

https://www.myawesomesite.com/games/fungame/points

身份验证处理程序（如）为您管理这些重定向URL

例如，当身份验证处理程序创建身份验证请求时，它对当前受保护的URL进行编码（例如

https://www.myawesomesite.com/games/fungame/points

）在“状态”请求参数中

为确保此URL不被篡改，应使用加密或签名保护“state”参数

---

当身份验证处理程序处理身份验证响应时，假设它是一个成功的响应，它将创建一个标识cookie并从

https://www.myawesomesite.com/oidc-signin

到“state”响应参数中最初受保护的URL。

中实际讨论了这一点“OAuth 2.0威胁模型和安全注意事项”部分，以及

4.1.5.威胁：在客户端上打开重定向程序

打开的重定向程序是一个端点，它使用一个参数自动 将用户代理重定向到参数值指定的位置 没有任何验证。如果授权服务器允许客户端 要仅注册重定向URI的一部分，攻击者可以使用开放式 客户端操作的重定向器，用于构造重定向URI 将通过授权服务器验证，但将发送 控制下端点的授权“代码”或访问令牌 袭击者的尸体

影响：攻击者可以访问授权“代码”或访问令牌

对策：

o要求客户端注册完整重定向URI（）

讨论限制性太强的情况，并提供其他解决方案

---

通常情况下，

state

参数也可以按照Chris的建议用于确定重定向。但是，您必须确保这样的解决方案也不会最终成为一个开放的重定向器，因此

状态

参数要么需要保护（例如加密/签名），要么与cookie一起使用。

您的Aweasome应用程序是否处理同一端点上的所有身份验证响应（例如/oidc signin）？否。假设我有100条唯一路径，其中99条经过身份验证。用户可以将99条路径中的任何一条添加书签。@chrispadget如果他们点击一个经过身份验证的页面，它应该重定向到B2C并返回到该页面。如果我拥有myawesomesite.com域，并且我有一个开放的重定向器，允许该域上的任何重定向URL，那么攻击者如何能够利用重定向uri进行攻击？它仍然必须重定向到我的域。常见的情况是重定向url接受一些查询参数，攻击者可以利用这些参数重定向到他们的站点。威胁模型假设用户代理“未经任何验证”被重定向。您所建议的是某种约束或验证。Azure AD试图通过一种适用于大多数情况的方法实现平衡，但仍然限制通配符和查询参数。（请注意，这些漏洞今天仍然存在，特别是在复杂的应用程序中：）感谢您编辑我的回复spottedmahn。我昨晚只有一个手机页面，它似乎没有全功能的编辑器。啊，“查询参数”，很好！感谢您的详细回复！后续问题：如果“状态”将用户发送到另一个域（例如，另一个地理区域中的同一应用程序），则该过程将重复（IP重定向回该地理实例的/oidc登录），但用户不必再次提供凭据（SSO），但必须等待交互完成。据我所知。。。