Azure AD SAML2 SSO配置：Reply URL缓存致旧用户登录异常

我之前碰到过完全一样的情况——旧测试账号会死死咬住缓存的SAML断言或重定向URI，哪怕你已经在Azure AD里修正了Reply URL。不用重建应用的话，你可以试试这些可行的解决办法：

1. 撤销用户的现有刷新令牌和会话 #

Azure AD可能还存着指向错误Reply URL的旧会话数据。你可以强制用户从头重新认证：

• 进入Azure门户 > Azure Active Directory > 用户 > [受影响的用户] > 登录日志
• 找到和你的SAML应用相关的近期失败登录记录，然后点击顶部菜单的撤销会话
• 或者用Microsoft Graph API撤销用户的所有刷新令牌：

  Invoke-MgRevokeUserSignInSession -UserId "用户ID"
  

  这会让所有活跃会话失效，强制用户走完整的SAML认证流程，自动获取修正后的Reply URL。

2. 清除Azure AD中应用针对该用户的缓存数据 #

有时候应用本身在Azure AD里存了用户的缓存数据。要重置这个：

• 进入Azure门户 > Azure Active Directory > 企业应用 > [你的SAML应用] > 用户和组
• 把受影响的测试用户从应用中移除，等5-10分钟后再重新添加
• 这会让Azure AD从头重新配置用户的SAML设置，覆盖所有缓存的旧URL。

3. 检查浏览器中残留的SAML断言数据（不止基础缓存） #

哪怕你清了常规浏览器缓存，有些浏览器会把SAML相关数据存在单独的地方：

• Chrome：打开chrome://settings/siteData，搜索你的Azure AD域名（比如login.microsoftonline.com），删除所有关联数据
• Edge：打开edge://settings/siteData，和Chrome操作一样
• Firefox：打开about:preferences#privacy，在Cookie和站点数据下选择清除数据，确保勾选了Cookie和缓存网页内容，然后清除。

4. 确认SAML应用的Reply URL配置已完全更新 #

再仔细检查一遍，确保你已经从应用配置里移除了旧的错误Reply URL：

• 在Azure AD企业应用中，进入单点登录 > 基本SAML配置
• 确保只列出了正确的、在用的Reply URL（删掉所有旧的）
• 同时确认**标识符（实体ID）**也是正确的，这里不匹配有时候也会导致意外重定向。

5. 先用无痕/隐私浏览模式测试 #

让用户先用无痕窗口尝试登录，这样可以绕过所有本地浏览器缓存，直接使用Azure AD的最新配置。如果这样能正常登录，说明问题确实出在本地或缓存的会话数据上。

这些步骤应该能解决重定向问题，不用重建整个应用。大部分情况下，要么是Azure AD里缓存的用户会话，要么是浏览器残留的数据导致旧Reply URL一直生效。

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