为什么Azure AD B2C中的重定向URL完全合格？

Question

为什么重定向网址必须完全匹配？域级别的匹配是否足以获得适当的安全性？

如果我有数百条路径怎么办？

示例网址:

1. https://myawesomesite.com
2. https://myawesomesite.com/account/profile
3. https://myawesomesite.com/games/fungame/points
4. https://www.myawesomesite.com/games/fungame/points

...

我必须将上面的4个重定向网址输入到我的B2C应用配置中.

Answer 1

所有身份验证请求都包含两个重定向URL,这是常见的(也是最简单的):

1. 在"redirect_uri"参数中传递的一个(通常称为回复URL),该参数必须在 Azure AD B2C中注册,所有身份验证响应都从Azure AD B2C返回到依赖方应用程序.这方面的一个例子是https://www.myawesomesite.com/oidc-signin.
2. 在"状态"参数中往返的另一个(通常称为返回URL),该参数不必在Azure AD B2C中注册,在依赖方应用程序处理完身份验证之后,最终用户将返回该参数响应.这方面的一个例子是https://www.myawesomesite.com/games/fungame/points.

身份验证处理程序(如ASP.NET Core身份验证中间件)会为您管理这些重定向URL.

例如,当认证处理程序创建认证请求时,它https://www.myawesomesite.com/games/fungame/points在"状态"请求参数中编码当前受保护的URL(例如).

为确保此URL未被篡改,应使用加密或签名保护"state"参数.

当身份验证处理程序处理身份验证响应时,假设它是成功的响应,它会创建一个身份cookie,并将最终用户重定向https://www.myawesomesite.com/oidc-signin到"state"响应参数中最初受保护的URL.

Answer 2

这在实际上讨论RFC 6819 "的OAuth 2.0威胁模型和安全注意事项"章节4.1.5,4.2.4和5.2.3.5.

4.1.5.威胁:在客户端打开重定向器

开放重定向器是一个端点,使用参数自动将用户代理重定向到参数值指定的位置,而不进行任何验证.如果授权服务器允许客户端仅注册部分重定向URI,则攻击者可以使用客户端操作的开放重定向器来构建重定向URI,该URI将通过授权服务器验证但将发送授权"代码"或访问令牌到攻击者控制下的端点.

影响:攻击者可以访问授权"代码"或访问令牌.

对策:

o要求客户注册完整的重定向URI(第5.2.3.5节)."

第5.2.3.5节讨论了这种情况可能过于严格并且出于替代解决方案的情况.

通常,该state参数也可用于确定性地重定向,如Chris所建议的那样.