2. SSO协议基础与选型
在企业SSO建设中，协议选型往往决定了后续会话安全治理的上限。很多团队把SAML、OIDC、OAuth 2.0当作可以互换的“登录方式”，结果在会话生命周期、令牌撤销、跨域登出等环节反复踩坑。要做出正确选型，必须先厘清三者的定位差异：OAuth 2.0是授权框架，不是认证协议；OIDC是在OAuth 2.0之上构建的认证层；SAML则是以XML断言为核心的企业级认证与授权标准。理解这一点，才能理解它们各自的会话机制与安全边界。
一、三者的会话机制本质差异
SSO的“会话”实际上由两段组成：身份提供方（IdP）侧的中心会话，以及服务提供方（SP/应用）侧的本地会话。用户首次登录时，IdP建立中心会话并签发凭证；应用验证凭证后建立自己的本地会话。后续访问其他应用时，只要IdP中心会话仍有效，就能免密签发新凭证，这就是SSO的免登基础。
SAML的凭证是XML格式的Assertion断言，通过浏览器POST或Redirect绑定传递。断言中携带NameID、属性声明、Conditions（如NotBefore/NotOnOrAfter）和SubjectConfirmation。SP验证签名后建立本地会话，会话时长通常由SP自己的Cookie决定，与断言有效期解耦——这是SAML会话治理中最容易被忽视的错配点。
OIDC的凭证是ID Token（JWT格式），配合Access Token和Refresh Token使用。ID Token用于认证，Access Token用于访问资源，Refresh Token用于在中心会话有效期内静默续期。OIDC还提供end_session_endpoint和front-channel/logout机制，使跨应用登出比SAML更易实现。
OAuth 2.0本身不定义认证，只定义授权。它通过Access Token让客户端访问受保护资源，但Token不包含“用户是谁”的认证语义。若直接用OAuth 2.0做登录，会引入混淆代理（Confused Deputy）和Token注入风险。因此现代实践中，OAuth 2.0必须与OIDC配合，或至少使用经过严格校验的ID Token。
二、选型的核心判断维度
选型不是比“谁更先进”，而是看应用形态、身份源现状、安全要求、运维能力四个维度。传统企业内网应用、已有ADFS或Okta等SAML IdP的，继续用SAML成本最低；新建的Web、移动、SPA应用，OIDC是更自然的选择；纯API授权场景，OAuth 2.0的Client Credentials或授权码模式更合适。
一个常见的误区是“新项目一律上OIDC”。如果企业IdP只支持SAML，强行引入OIDC会多出一层协议转换代理，反而增加会话断点和排障难度。反过来，如果应用需要移动端原生体验、需要Refresh Token静默续期，SAML的浏览器重定向模型会非常别扭。
三、会话安全边界的关键控制点
SAML侧最需要关注的是XML签名包装攻击（XSW）。攻击者构造包含多个Assertion的XML，让SP验证了签名正确的那个，却使用了另一个未签名的断言。防御方法是严格按Schema解析、只取签名覆盖范围内的Assertion、禁用DTD。此外，断言有效期（NotOnOrAfter）通常只有几分钟，而SP本地Cookie可能长达数小时，这中间的窗口就是会话治理的盲区。
OIDC侧的核心是ID Token校验完整性。必须校验签名、iss、aud、exp、nonce，缺一不可。很多实现只验签名不验aud，导致其他应用的Token可以拿来登录本应用。授权码流必须配合PKCE，防止授权码拦截。隐式流（Implicit Flow）因Token暴露在URL中，已被OAuth 2.1废弃。
OAuth 2.0侧最危险的是把Access Token当身份凭证。Access Token是给资源服务器看的，不是给登录入口看的。如果登录逻辑只检查“Token有效”就放行，攻击者可以用自己申请的、指向其他用户的Token完成越权登录。正确做法是：认证必须走OIDC的ID Token，OAuth 2.0只负责授权。
四、企业选型决策参考
| 判断维度 | 优先SAML | 优先OIDC | 仅OAuth 2.0 |
|---|---|---|---|
| 应用形态 | 传统Web、桌面客户端 | SPA、移动App、API网关 | 纯后端服务间调用 |
| IdP现状 | 已有ADFS/Okta SAML | 已有Azure AD/Keycloak OIDC | 无用户登录需求 |
| 会话续期 | 依赖IdP重定向 | Refresh Token静默续期 | Client Credentials |
| 跨域登出 | SLO实现复杂 | end_session_endpoint较成熟 | 不涉及 |
| 典型风险 | XSW、断言重放 | Token校验缺失、PKCE未启用 | 混淆代理、Scope过大 |
五、实操建议：从选型到落地
落地时建议先做一次应用清单盘点，按“是否支持OIDC、是否有移动端、是否涉及敏感数据”打标签。对于同时支持SAML和OIDC的IdP（如Azure AD、Okta、Keycloak），新应用优先OIDC，存量SAML应用保持不动，通过IdP统一管理中心会话。这样既避免大规模迁移风险，又能让新应用享受OIDC的会话治理能力。
会话超时策略上，建议IdP中心会话设为8小时（覆盖一个工作日），应用本地会话设为30分钟空闲超时。OIDC应用通过Refresh Token在中心会话有效期内续期，SAML应用则依赖IdP的会话Cookie。两者都要配置绝对超时，防止Refresh Token被无限续期。
最后要强调：协议选型只是起点，真正的会话安全取决于令牌校验是否完整、会话超时是否合理、登出是否彻底。SAML、OIDC、OAuth 2.0各有其位，理解它们的会话机制差异，才能在架构设计阶段就把安全边界划清楚。