很多企业为了打通各系统的登录，会用SAML协议搭建SSO单点登录，省了员工记密码的麻烦，但最近不少开发朋友反馈，部署后遇到了一个头疼的问题——用户点登录，刚跳转到统一认证平台（IdP），登录完又跳回原系统，紧接着又弹IdP登录框，无限循环，这就是典型的SSO无限重定向故障。遇到这种情况别慌，我们可以从SAML响应里的两个核心参数入手，逐层定位根因，哪怕是刚接触SSO的新手也能一步步排查。

一、先搞懂故障的核心逻辑

1.1 SAML里的那两个关键参数

SAML就像公司发的“身份快递”，IdP是发件人（统一认证），服务提供商（SP，比如OA、CRM）是收件人，那两个关键参数就是快递的“收件地址”和“代收点”——Destination就是这个快递最终要送到的地址（比如SP的登录回调地址），ACS（断言消费服务）就是SP专门收这个身份快递的“代收点接口”，如果这俩参数不匹配或者错了，SP收不到正确的身份信息，就会一直让你重定向去登录，导致无限循环。

1.2 常见的故障场景

举两个实际例子：某电商公司把旧OA系统换成了新的，SAML的SP端改了ACS的路径，但IdP那边没同步更新SAML响应里的Destination和ACS字段，结果用户登录IdP后，SAML响应里的地址还是旧OA的，新OA收不到这个快递，就一直让用户重新登录，形成循环；还有一家制造业的财务系统对接SSO，测试阶段用的是环境端口8080，上线后改成了8081，但IdP里的Destination还是填了8080，上线后用户登录就一直跳循环，直到对比两边端口才发现问题。

二、逐层排查的具体步骤（附示例）

2.1 第一步：校验SAML响应里的Destination参数

这一步非常简单，就是看看IdP返回的SAML响应里的Destination，是不是和SP配置的登录回调地址完全一致。我们用Node.js作为单一技术栈，举一个实际的SAML响应示例：

<!-- 这是IdP返回的SAML响应XML片段，标注了关键参数 -->
<samlp:Response Destination="https://new-oa.com/sso/acs" ID="_123456" IssueInstant="2024-05-20T10:00:00Z" Version="2.0" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
  <!-- 这里的Destination是核心，必须和SP的ACS地址完全匹配 -->
  <saml:Assertion ID="_789012" IssueInstant="2024-05-20T10:00:00Z" Version="2.0" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
    <saml:Subject>
      <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">user@company.com</saml:NameID>
      <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
        <saml:SubjectConfirmationData InResponseTo="_abcdef" NotOnOrAfter="2024-05-20T10:05:00Z" Recipient="https://new-oa.com/sso/acs"/>
        <!-- 这里的Recipient和Destination必须一致，是SAML协议的强制要求 -->
      </saml:SubjectConfirmation>
    </saml:Subject>
  </saml:Assertion>
</samlp:Response>

排查的时候，直接用浏览器按F12打开网络面板，找到IdP返回的这个XML内容，复制Destination的值，和SP端的ACS配置对比，哪怕多一个斜杠、少一个端口号，都会导致参数不匹配，SP直接拒绝处理，触发重定向。

2.2 第二步：校验SP端的ACS端点配置

Destination参数没问题后，就要看SP端有没有正确配置ACS接口，这部分我们用Node.js的passport-saml库来演示，这是现在中小公司搭建SAML SPO常用的库：

// Node.js 单一技术栈的SSO SP端核心代码
const express = require('express');
const passport = require('passport');
const { Strategy: SamlStrategy } = require('passport-saml');
const app = express();

// SAML核心配置，path就是ACS的路径，必须和SAML响应里的Destination路径完全一致
const samlConfig = {
  path: '/sso/acs', // 这个路径不能多斜杠、不能大小写错，比如写成/Sso/Acs就匹配不上
  entryPoint: 'https://idp.company.com/sso/login',
  issuer: 'https://new-oa.com',
  cert: 'MIIC...（这里省略IdP的公开证书，用于校验签名）'
};

// 初始化SAML策略
passport.use(new SamlStrategy(samlConfig, (profile, done) => {
  // 这里是处理成功登录的回调，只有ACS正常工作才会走到这里
  return done(null, profile);
}));

// 定义ACS端点，接收IdP返回的SAML响应
app.post('/sso/acs',
  passport.authenticate('saml', { failureRedirect: '/login', failureFlash: true }),
  (req, res) => {
    // 登录成功，跳转到OA首页
    res.redirect('/dashboard');
  }
);

app.listen(3000, () => console.log('OA服务启动在3000端口'));

这里的坑很常见：比如你把path写成了/sso/acs/（多了末尾斜杠），或者SP服务跑在3000端口但你配置成了8080，SAML响应里的Destination就会指向错误的地址，SP找不到对应的接口，自然会一直触发重定向。排查这一步时，直接用POST工具（比如Postman）向/sso/acs发一个模拟的SAML响应，看有没有返回404或者报错，就能快速定位问题。

2.3 其他容易忽略的小细节

虽然核心是Destination和ACS，但还有几个小问题会间接导致无限重定向：比如SAML响应的时间戳过期（一般是5分钟内有效）、IdP的签名验证不通过，不过这些问题通常不会触发无限循环，更多是直接登录失败。另外，浏览器缓存旧的SAML响应也会导致问题，排查时一定要用无痕模式测试，或者清掉浏览器的SSO相关缓存。

三、应用场景与技术总结

这个排查方法适用于所有用SAML协议的SSO场景，不管是自建的IdP还是用Okta、Auth0这类云IdP，也不管是对接OA、CRM还是内部业务系统，只要遇到无限重定向，都可以按这个步骤来。SAML的优点是安全性高，适合企业级的身份认证，支持跨平台对接；缺点是配置复杂，参数多，调试起来比OIDC麻烦。排查时要注意：两边的配置必须完全一致，一定要看原始SAML响应的内容，不要被前端显示的信息误导，测试时用无痕模式避免缓存干扰。总结一下，SSO无限重定向的核心原因就是SAML响应的“地址”和SP的“代收点”不匹配，按步骤对比就能快速解决。