Azure Ad - 隐藏在授权后面的重定向 Uri

Question

我遇到了一个可以观察到无限重定向循环的问题。我的项目基于官方 MS 示例 - active-directory-b2c-dotnet-webapp-and-webapi

"Redirect URI"（在 Azure 门户中定义）是否必须是可公开访问的端点？

如果在我的控制器中用 [Authorize] 属性装饰它会发生什么？

所以基本上在这个例子中Redirect Uri（设置为网站根目录，即localhost:1234/）也将是控制器中一个动作的路由，这需要授权。

[Authorize]
public class ControllerA : Controller
{
    [Route("~/")]
    public ActionResult Index()
    {
    }
}

它会导致无限重定向循环吗？

删除路由属性可以解决问题，但与此同时，我觉得这不是问题的真正原因。

我想 OWIN 授权在应用程序堆栈中比控制器的授权更高，所以我认为 OWIN 授权中间件会首先解析来自 Azure Ad 的响应，而不是强制执行 [Authorize] 属性策略并预先拒绝它。

Answer 1

您当然可以通过这种方式创建一个无限循环场景，但它最终会被 Azure AD short-circuited。几次循环后，它将停止重定向并显示错误。

redirect_uri 不必是可公开访问的 URI，例如，它可以与 http://localhost 一起使用。它只需要可由客户端访问。毕竟，"redirect" 只是服务器发出的 HTTP 响应。它实际上是由客户端执行的。

一般来说，您用于授权（即接收重定向）的控制器不应在 class 级别由 [Authorize] 装饰。通常，您只会装饰少数需要登录用户的方法。也就是说，只要用 [AllowAnonymous].

修饰回调端点，你当然可以用 [Authorize] 修饰 class

Answer 2

问题的核心和解决方案在以下文档中描述 - System.Web response cookie integration issues. I've implemented 3rd solution (reconfigure the CookieAuthenticationMiddleware to write directly to System.Web's cookie collection) and it has resolved the issue. What lead me to discover that the cookies were the issue is another Whosebug's question，它描述了与我观察到的非常相似的症状。

事实上，默认路由 [Route("~/")] 被映射到需要授权的控制器方法之一，并且它也匹配我在 Azure 门户中设置的 redirect_uri 是不是罪魁祸首。在我看来，这证明 redirect_uri 调用将由 OWIN 身份验证中间件直接处理，它甚至不会到达控制器的方法。

Azure Ad - 隐藏在授权后面的重定向 Uri

Azure Ad - Redirect Uri hidden behind authorization

c#

openid-connect

azure-ad-b2c

asp.net-core