SSO成功后菜单接口仍报令牌非法

SSO登录成功后，系统菜单接口直接返回“令牌不合法”。用户已经完成单点登录流程，认证状态正常，但进入系统内部页面时却无法正常加载菜单。继续追踪发现，菜单接口的响应明确提示令牌校验失败。

这个现象并不复杂，却很容易让人误入歧途。SSO环节一切正常，说明认证服务本身没有问题；但系统内部却把令牌判定为非法，导致后续所有依赖该令牌的接口都无法正常工作。开发者一开始自然会把怀疑点放在菜单接口的实现上，以为是接口代码出了bug。

实际表现是：浏览器端已经携带了SSO返回的令牌发起请求，后端却在权限校验阶段直接拒绝。错误信息干净利落，没有额外上下文，给排查增加了难度。这种“认证通过却业务失败”的情况，在遗留系统中并不罕见。它暴露出的不是单一接口缺陷，而是新旧认证机制之间的断层。

从用户角度看，登录成功后页面白屏或菜单为空，体验极差。从技术角度看，这类问题往往隐藏在调用链深处，需要逐层剥离才能定位。信号中明确提到，现象不复杂，但排查过程却指向了业务逻辑本身而非接口实现。

接口本身并无异常，问题藏在调用链

排查初期，开发者把问题指向了菜单接口本身。接口返回“令牌不合法”，最直接的判断就是接口的校验逻辑有问题。很多人会先检查接口代码的令牌解析部分、签名验证部分，甚至怀疑是不是Redis缓存出了问题。

但进一步调试后发现，接口本身的代码逻辑是正确的。它按照当前定义的规则去校验令牌，签名、过期时间、格式都符合预期。问题出在调用链的上游——菜单接口所依赖的令牌是由旧业务逻辑生成的，或者说旧逻辑在某个关键节点拦截并重新处理了令牌。

通过日志追踪和断点调试，开发者逐步排除了接口层故障。接口接收到的令牌格式与SSO新流程产生的令牌不匹配，但接口代码并没有bug，它只是忠实地执行了既有的校验规则。信号明确提到，一开始以为是接口问题，后来发现不是，它更像是一个业务问题。

这个转折很重要。它提醒我们，在复杂系统中，表象往往指向错误的方向。接口报错不等于接口有错。调用链中任何一个老旧模块如果没有跟上新认证机制的变化，都可能让整个流程失败。排查过程从接口代码审查转向了业务流程梳理，这一步的转变避免了在错误方向上浪费更多时间。

旧权限校验逻辑未同步SSO令牌规则

问题最终定位到旧权限校验逻辑上。这部分代码仍然使用早期的令牌验证方式，包括特定的前缀、存储位置和校验算法。新SSO流程产生的令牌在格式、签名方式或存储位置上已经发生变化，但旧校验代码没有做出相应调整。

旧逻辑在读取令牌时，仍然期望从特定Header或Cookie中获取老格式的字符串。新令牌虽然通过了SSO认证，却在进入旧权限模块时被直接判定为非法。两者在令牌结构上的不兼容直接导致了校验失败。

这种不兼容不是显性的报错，而是静默拒绝。旧代码没有抛出清晰的“版本不匹配”异常，只是简单返回“令牌不合法”。这让开发者很难第一时间发现根源。信号中指出，这更像是一个业务问题，只不过伪装成了接口问题。

旧权限校验逻辑在系统中存在多年，已经成为事实标准。新SSO集成时，团队可能只关注了新认证服务的接入，却忽略了下游所有依赖旧令牌规则的模块。这正是遗留系统常见的陷阱：新功能上线看似成功，实际却被老代码在暗处拦截。

新认证机制被遗留代码悄然拦截

旧业务逻辑对新SSO功能的破坏是悄无声息的。没有明显的编译错误，没有启动时的警告，SSO登录表面上成功了，但只要进入需要权限校验的页面，旧代码就会毫不留情地把新令牌拒之门外。

这种隐性破坏在遗留系统中特别危险。因为旧代码往往散落在多个模块中，开发者很难一眼看出哪些地方还在使用老的令牌校验。新认证机制看似已经替换，但实际上只替换了一半，另一半被遗留代码悄然接管并破坏。

从这个案例可以看出，遗留代码对新特性的破坏往往不是主动攻击，而是被动不兼容。旧逻辑不知道新令牌长什么样，就只能按自己的规则拒绝。这种破坏没有明显日志，排查起来需要大量时间。信号中的排查过程正是从接口表象一路追到业务逻辑深处的典型案例。

类似情况在很多老系统中反复出现。新功能开发时，大家关注的是新代码是否正确，却很少有人系统性地检查旧代码是否会与新机制冲突。结果就是新功能上线后，部分场景莫名其妙地失败。

重构旧校验代码需先建立兼容边界

要安全替换旧权限逻辑，首先需要建立清晰的兼容边界。不能简单地把旧校验代码全部删除，而应该先定义新旧令牌的共存规则，比如通过令牌前缀或版本字段来区分不同来源的令牌。

排查过程中发现的切入点是：找出所有调用旧权限校验的入口点，然后逐一插入兼容逻辑。新SSO令牌走新校验路径，旧令牌继续走原有路径。边界清晰后，重构风险才能得到控制。

具体做法包括：增加令牌版本标识，在校验入口处进行路由；为新令牌单独编写校验服务；逐步迁移调用方到新服务。每次迁移一个模块，都需要验证新旧路径都能正常工作。

风险控制的关键是小步迭代。不要一次性重构所有旧代码，而是每次只替换一个调用链路，观察线上表现。信号中的排查经验表明，只有先把问题边界划清楚，重构才能安全推进，否则很容易引入新的兼容性bug。

测试策略必须覆盖新旧认证并存场景

测试阶段必须专门设计覆盖新旧认证并存的用例。只测试新SSO流程是不够的，还需要构造旧系统遗留的令牌，验证它们是否仍能正常通过校验。

针对性测试用例至少应该包括：新SSO令牌的完整流程、旧格式令牌的兼容校验、新旧令牌同时存在时的优先级判断、令牌格式异常时的错误处理。缺少任何一类，都可能让类似冲突在上线后再次出现。

在遗留系统维护中，测试策略需要从“验证新功能正确”升级到“验证新旧机制不冲突”。这意味着测试环境要能同时模拟新认证服务和老业务模块。自动化测试中应该增加跨版本兼容测试套件，每次重构后自动运行。

这个案例提醒我们，测试不能只看表面成功。SSO登录成功不代表整个系统可用。只有把新旧逻辑冲突场景纳入常规测试，才能真正防止同类问题反复发生。

遗留系统集成新功能需建立变更审计

长期维护遗留系统时，必须建立严格的变更审计机制。每次引入新认证机制，都要系统性地梳理所有依赖旧令牌的代码路径，并在代码审查阶段重点检查兼容性。

具体做法包括：维护一份令牌使用依赖图，记录哪些模块还在消费老格式令牌；代码审查清单中增加“新旧认证兼容性”检查项；引入静态分析工具，扫描可能调用旧校验函数的地方。

变更审计还应该包含上线后的监控指标，比如“令牌非法错误”在特定接口的发生率。一旦指标异常升高，立即触发告警和回滚。信号中的问题如果在集成SSO时就做好审计，可能在上线前就能发现。

遗留系统集成新功能的最大风险不是新代码本身，而是旧代码对新机制的无声抵抗。只有把变更影响范围摸清、审计流程固化，才能让新功能真正落地，而不会被遗留逻辑悄然破坏。

通过这次排查，我们看到技术债务不是抽象概念，而是真真切切地影响新功能交付。及早识别、建立边界、覆盖测试、持续审计，是维护遗留系统时必须坚持的实践。

参考来源