Office 365 OAuth2认证跳转login.srf循环登录问题求助

我来帮你梳理这个OAuth2授权流程里的循环跳转问题，这种情况通常和端点使用、配置匹配或权限设置有关，咱们一步步排查：

1. 优先检查授权端点版本 #

你当前使用的是旧版Azure AD v1授权端点 https://login.windows.net/common/oauth2/authorize，而现在Azure门户新注册的应用更适配v2端点 https://login.microsoftonline.com/common/oauth2/v2.0/authorize。旧端点和新应用注册的配置容易出现兼容性问题，尤其是当你的应用是在「应用注册（新）」面板创建时。

另外，v2端点的参数和v1有区别：v1里的resource参数在v2中需要替换为scope，并且要指定具体的权限范围，比如邮件、日历的读写权限，示例如下：

https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=[ClientId]&redirect_uri=http://localhost/MicrosoftAuthDemo/MicrosoftCallBack.ashx&response_type=code&scope=https://outlook.office365.com/Calendars.Read https://outlook.office365.com/Mail.Read&state=c9833f87-892a-4f94-9234-2de9832d1f49

2. 确认重定向URI完全匹配 #

Azure AD对重定向URI的匹配要求非常严格，哪怕是大小写、末尾斜杠的差异都会导致跳转失败，进而回到登录页循环：

• 登录Azure门户，进入你的应用注册页面，找到「认证」板块的「重定向URI」
• 确保配置的URI和你授权链接里的http://localhost/MicrosoftAuthDemo/MicrosoftCallBack.ashx完全一致
• 注意URI的类型要选「Web」，本地开发场景HTTP是被允许的（生产环境必须用HTTPS）

3. 检查API权限配置 #

如果应用没有配置对应的Office 365权限，或者权限未完成同意流程，也会导致无法跳转到授权同意页，进而触发循环：

• 进入应用注册的「API权限」板块，确认已添加「Office 365 Exchange Online」的相关委托权限（比如Calendars.Read、Mail.Read）
• 如果是企业租户应用，需要管理员完成「管理员同意」；如果是个人应用，第一次登录时会自动弹出用户同意页（前提是权限已配置）

4. 验证租户匹配度 #

你的授权链接里用了common租户，这允许任何Azure AD或个人Microsoft账户登录。但如果你的应用注册时设置的「支持的账户类型」是「仅限此组织目录中的账户」（单租户），那么用common就会导致租户不匹配，触发循环：

• 进入应用注册的「概述」页面，查看「支持的账户类型」
• 如果是单租户，把授权链接里的common替换成你的租户ID或租户域名

5. 清除浏览器缓存/会话 #

有时候旧的登录会话、Cookie会干扰新的授权流程，尤其是之前登录过其他租户的账号时。建议清除浏览器的缓存和Cookie后，重新发起授权请求。

如果以上步骤都排查过还是有问题，可以补充下Azure应用注册里的关键配置信息（比如支持的账户类型、重定向URI列表、API权限的同意状态），这样能更精准定位问题。

内容的提问来源于stack exchange，提问作者Yusril Maulidan Raji