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

【问题标题】：Azure Ad - Redirect Uri hidden behind authorizationAzure Ad - 隐藏在授权后面的重定向 Uri
【发布时间】：2018-09-05 23:14:26
【问题描述】：

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

“重定向 URI”（在 Azure 门户中定义）是否必须是可公开访问的端点？

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

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

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

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

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

我认为与控制器的授权相比，应用程序堆栈中的 OWIN 授权更高，因此我认为 OWIN 授权中间件会首先解析来自 Azure Ad 的响应，而不是强制执行 [Authorize] 属性策略和提前拒绝。

【问题讨论】：

portal中注册的redirect uri通常指的是auth中间件直接处理的路径，而不是MVC控制器。

标签： c# asp.net-core openid-connect azure-ad-b2c

【解决方案1】：

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

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

一般来说，您用于授权（即接收重定向）的控制器不应在类级别由 [Authorize] 修饰。通常，您只会装饰少数需要登录用户的方法。也就是说，你当然可以用[Authorize] 装饰类，只要你用[AllowAnonymous] 装饰你的回调端点。

【讨论】：

经过更多调试后发现，每次应用程序重新启动后，第一次登录尝试总是有效（即使当前设置），只有以下请求开始触发无限循环。此行为似乎不是由剩余的 cookie 引起的，因为我始终在隐身模式下在多个浏览器中对其进行了测试。在这一点上，它一定是我的代码中的另一个问题 - 我将花更多时间进行调试。
显然只是在 answer 中建议的 Global.asax 中添加 protected void Session_Start() 方法似乎可以解决问题，这让我相信它一定是在 OWIN Authentication 中间件中处理 cookie 的一些模糊问题.这似乎是一个很老的问题，但是将整个 OWIN 堆栈从 3.0.0 升级到 4.0.0 并不能解决它。

【解决方案2】：

问题的核心和解决方案在以下文档中描述 - System.Web response cookie integration issues。我已经实现了第三种解决方案（重新配置 CookieAuthenticationMiddleware 以直接写入 System.Web 的 cookie 集合）并且它已经解决了这个问题。导致我发现 cookie 是问题的原因是另一个 StackOverflow 的 question，它描述了与我观察到的症状非常相似的症状。

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

【讨论】：