Java应用单点登录场景下SAML是否仍为可行的技术选型？

你踩的坑纯粹是搜资料没分清废弃老组件和在维护的新组件，跟SAML本身生态是否停摆没有关系。

先给你拍板几个实锤 #

• 现在你能叫得上名的企业级IdP，不管是国外的Azure AD、Okta，还是国内的各类政企、高校统一身份平台，全把SAML 2.0当标配对接协议，存量B端系统里SAML的对接需求比OIDC还多，谈淘汰至少十年内都不可能。
• SAML 2.0的核心规范2005年就定完了，快二十年没改过核心逻辑，本身稳得离谱，这也是为什么很多基础逻辑的示例代码看着十年没更新——因为确实不需要改。

你碰到的依赖失效、漏洞多的问题，全是找错了组件包 #

你举的那几个有问题的组件，全是早就被替换掉的历史遗留包：

• OpenSAML 3.x确实停更留了一堆漏洞，但现在官方一直在迭代的是OpenSAML 4.x，由Shibboleth团队维护，安全补丁出得很勤，根本不存在大量未修复高危漏洞的情况。
• 你搜到的spring.security.opensaml是2019年之前的第三方独立扩展，2019年就被Spring Security官方收编做成内置模块了，老的独立包仓库坐标早就下架了，照着老博客引当然找不到包。现在Spring技术栈直接引入内置的spring-security-saml2-service-provider就行，从Spring Security 5.2到最新的6.x版本一直持续更新，官方文档全是最新内容，正常运行完全没问题。

各技术栈当前维护状态正常的SAML库参考 #

• Java栈：底层核心用OpenSAML 4.x，用Spring框架就直接上官方内置的SAML2模块，别找网上零散的第三方野生扩展。
• Python栈：用OneLogin维护的python3-saml，版本更新及时，漏洞修复快，很少有依赖冲突问题。
• .NET栈：要么用微软官方自带的SAML支持组件，要么用ITfoxtec.Identity.Saml2，都是长期维护状态。
• Node.js栈：做服务提供方对接直接用passport-saml，要处理底层SAML逻辑用saml2-js，维护状态都正常。

最后提个选型建议 #

别直接照搬2020年之前个人博客里的依赖配置和示例代码，这类内容十有八九还在引用已经废弃的老版本包。你用什么技术栈就直接翻对应官方文档的SAML2章节，选用最近12个月内发布的稳定版本，基本碰不到依赖消失、大量漏洞未修的问题。
当然SAML本身确实有明显缺点：XML加解密、签名校验逻辑重，配置流程比OIDC繁琐很多，现在中小团队做面向C端的身份系统基本都优先选OIDC，但只要是做B端企业对接场景，SAML的兼容性和存量优势非常明显，短时间内完全不存在被淘汰的可能。

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