SAML 简介

SAML 2.0（Security Assertion Markup Language） 是企业 单点登录（SSO） 的老牌标准：用户在公司 IdP（Identity Provider） 登录一次，携带 SAML Assertion 访问多个 SP（Service Provider） 应用。Java 后端常作为 SP 接入 Okta、AD FS、Keycloak SAML。现代 greenfield 多选 OpenID Connect（见 oauth-oidc），但 SAML 在 政企、高校、legacy ERP 仍广泛存在。

学习目标

• 说清 IdP / SP、Assertion、Metadata 的角色
• 对比 SAML 与 OIDC 在 格式、移动端、API 上的差异
• 知道 Spring 接入 SAML 时 要校验什么

角色与流程（SP 发起）

1. 用户访问 SP → 未登录，302 到 IdP
2. IdP 登录成功 → POST SAMLResponse 到 SP ACS URL
3. SP 验签 Assertion → 建立本地会话（Cookie）或发 JWT
4. 用户访问 SP 资源

Assertion 是 XML，含 NameID（用户标识）、Attribute（部门、邮箱）、NotOnOrAfter（过期）等。

与 OIDC 对比

	SAML 2.0	OpenID Connect
载体	XML Assertion	JWT id_token + JSON
典型场景	企业 Web SSO、B2B	现代 Web / 移动 / API
前端 SPA	重、Redirect POST 多	授权码 + PKCE 友好（oauth-pkce）
API 纯后端	少见直接传 SAML	Bearer access_token 自然
工具链	偏企业 IdP 文档	oauth-essentials 全 track

新 API 优先 OIDC；客户要求「必须接 AD FS SAML」时再上 SAML。

SP 必须校验的项

1. 签名：IdP 公钥（metadata 轮换要跟进）
2. Audience：Assertion 发给本 SP，防转发到其他系统
3. Recipient / ACS URL：与配置的 Assertion Consumer Service 一致
4. NotOnOrAfter / NotBefore：拒绝过期 Assertion
5. InResponseTo：与先前 AuthnRequest ID 对应，防重放

任一失败应 401/403 + 审计日志，不要「解析失败仍登录」。

Spring 生态

• Spring Security SAML2 Service Provider（内置 SAML 登录流）
• 或与 Keycloak / Okta 配 metadata 交换