Azure AD OAuth认证后dashboard.aspx页面重定向异常求助

这种本地调试正常、发布到服务器就失效的场景真的很磨人，结合我之前踩过的Azure AD OAuth坑，给你梳理几个关键排查方向：

1. 核对Azure AD应用注册的重定向URI配置 #

• 别只加http://domainame.com/dashboard.aspx，还要确认是否包含OAuth中间件的默认回调路径：比如ASP.NET OWIN常用的http://domainame.com/signin-oidc（如果用的是OpenID Connect），很多时候认证流程会先跳转到这个默认路径，再由应用转发到目标页面。
• 重点检查HTTP/HTTPS一致性：如果生产服务器用的是HTTPS，Azure里的重定向URI必须全部改为HTTPS地址——本地调试用HTTP没问题，但生产环境协议不匹配会直接导致重定向失败，而且往往没有显性报错。

2. 验证代码中的回调与跳转配置 #

• 如果用的是OWIN中间件，检查UseOpenIdConnectAuthentication里的RedirectUri参数，确保它和Azure中配置的某个重定向URI完全一致，别留着本地调试时的http://localhost:xxxx/这类硬编码地址。
• 你在后台添加的重定向语句可能被OAuth的默认流程覆盖：比如认证成功后，中间件会自动跳回用户最初请求的页面。可以尝试在OnAuthorizationCodeReceived事件中明确指定跳转目标，示例代码如下：

  context.HandleCodeRedemption();
  context.Response.Redirect("/dashboard.aspx");
  

3. 排查服务器与浏览器的请求日志 #

• 服务器端：查看IIS日志，确认Azure是否真的发送了回调请求，有没有出现404、403或302异常。如果回调请求被服务器防火墙、URL过滤规则拦截，页面自然会无响应。
• 浏览器端：按F12打开控制台，切换到「网络」标签，观察登录后的跳转请求。如果看到Azure返回了error=invalid_redirect_uri这类错误，那就是重定向URI配置不匹配；如果有CORS报错，还要检查Azure应用的跨域配置。

4. 检查页面授权与Web.config配置 #

• 确认dashboard.aspx的授权规则：是否在页面的Page_Load或配置中限制了仅认证用户访问？如果页面设置为匿名访问，或当前用户权限不足，可能跳转后显示空白页，看起来像没响应。
• 核对web.config中的authentication节点：如果同时启用了Forms认证和OAuth，可能会出现冲突，建议统一为OAuth认证模式。

5. 排查URL重写与路由规则 #

• 检查服务器上的IIS URL重写规则：比如HTTP转HTTPS的规则是否正确处理了回调路径？有没有重写规则把dashboard.aspx的请求转向了其他页面？可以临时禁用重写规则测试是否恢复正常。

内容的提问来源于stack exchange，提问作者Trent Adams