配置Azure AD认证的MVC Web门户认证失败问题求助

我之前也碰到过这种头疼的情况——反复调整Reply URL却还是卡在认证环节，下面这些排查点你可以逐一试试，大概率能找到问题所在：

• 严格匹配Reply URL的每一个字符
  Azure AD对Reply URL的匹配要求近乎苛刻，必须和应用实际跳转的地址完全一致：

  • 协议（HTTP/HTTPS）不能搞混，本地调试时如果用的是HTTPS，就不能配置成HTTP
  • 末尾的斜杠要注意，https://yourapp.com/signin-oidc和https://yourapp.com/signin-oidc/会被判定为两个不同地址
  • 本地调试的端口号必须和项目启动端口完全匹配，比如https://localhost:44312/signin-oidc，端口错一位都不行

• 核对代码中的认证回调路径
  在MVC项目的Startup.cs（.NET 5及以前）或者Program.cs（.NET 6+）里，确认OpenID Connect的回调路径和Azure AD里配置的一致。比如：

  services.AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme)
      .AddMicrosoftIdentityWebApp(options =>
      {
          Configuration.Bind("AzureAd", options);
          // 这里的CallbackPath必须和Azure AD的Reply URL后缀完全对应
          options.CallbackPath = "/signin-oidc";
      });
  

  很多时候问题就出在这里——代码里的路径和Azure门户配置的不一样，光改门户没用。

• 选对Reply URL的类型
  如果你配置的是Web应用/API，Reply URL要选择Web类型；只有单页应用才选SPA类型。类型选错的话，哪怕地址完全正确，认证也会失败。

• 检查Azure AD应用的令牌配置
  确保你的应用已经启用了ID令牌（MVC这类服务器端应用必须依赖ID令牌完成认证），同时确认权限配置正确（比如至少添加User.Read的委派权限）。

• 清除浏览器缓存和旧会话
  反复修改Reply URL后，浏览器里残留的旧认证Cookie或会话可能会干扰新的请求。用隐私模式打开页面测试，或者完全清空浏览器缓存，能排除这个干扰项。

• 查看Azure AD的登录日志找具体错误
  登录Azure门户，找到你的AD应用，进入「监控」->「登录日志」，查看失败的登录记录。日志里会给出具体的错误代码（比如redirect_uri_mismatch）和原因说明，能帮你精准定位问题。

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