IdP发起SSO：把仪表盘点击变成标准登录

IdP发起的单点登录（IdP-initiated SSO）常被视为集成中的“边缘场景”——用户从身份提供商的仪表盘点击应用图标，本应直接进入应用，却因流程差异导致体验割裂或额外开发。WorkOS 提出了一种简洁的思路：通过配置一个登录端点，将 IdP 发起的点击转换为标准的 SP 发起登录（SP-initiated sign-in），从而复用现有的认证逻辑。

IdP-initiated SSO 示意

为什么 IdP 发起的 SSO 需要“转换”

在标准的 SP 发起流程中，用户从你的应用开始登录，被重定向到 IdP 完成认证，再带着断言返回。而 IdP 发起流程则相反：用户先在 IdP 的仪表盘（如 Okta、Azure AD 的应用面板）点击应用图标，IdP 直接向你的应用推送一个 SAML 断言或 OIDC 令牌。

这带来两个问题：其一，你的应用需要单独处理这种“被动”到达的断言，通常涉及额外的端点、校验和安全考量；其二，它绕过了应用自身的登录入口，难以统一会话管理和审计。WorkOS 的方案正是针对这一痛点——不是让应用去适配 IdP 发起流程，而是把后者“翻译”成前者。

SAML 断言与 OIDC 令牌是两种主流身份联合协议中承载身份信息的核心载体。SAML（安全断言标记语言）以 XML 格式的断言传递用户身份和属性，通常由 IdP 签名后通过浏览器 POST 绑定推送给 SP，SP 需验证签名、检查时效和受众等条件。OIDC（OpenID Connect）则基于 OAuth 2.0，以 JSON 格式的 ID Token（JWT）传递身份信息，通常通过授权码流程或隐式流程获取。两者在传输方式、签名机制和属性结构上差异显著，这也是 IdP 发起流程需要额外处理逻辑的原因：应用必须能解析并验证来自 IdP 的“被动”断言，而非自己主动发起请求后获得的响应。

核心机制：用 connection_id 衔接标准流程

据 WorkOS 的说明，开发者只需配置一个登录端点，当 IdP 的仪表盘图标被点击时，WorkOS 会接收 IdP 发来的请求，并自动将其转换为一次正常的 SP 发起登录。转换后的流程会将应用所需的 connection_id 交给你的应用，后续认证步骤与常规登录完全一致。

这意味着你的应用不需要维护两套认证路径。所有登录——无论是用户主动从应用发起，还是从 IdP 面板点击进入——最终都汇聚到同一套 SP 发起的处理逻辑中。connection_id 在这里扮演了关键角色：它标识了本次登录应使用的企业连接，确保 WorkOS 能正确路由到对应的 IdP 配置。

这一设计的好处在于降低集成复杂度。开发者不必为 IdP 发起场景编写独立的断言解析、签名验证和用户匹配代码，只需关注标准的登录回调即可。

connection_id 是企业 SSO 集成中用于标识特定身份连接的唯一标识符。在 WorkOS 等 SSO 平台中，每个企业客户通常对应一个连接（connection），其中封装了该客户所用 IdP 的元数据、证书、协议配置和属性映射规则。当应用收到带有 connection_id 的登录请求时，平台即可据此路由到正确的 IdP 配置，完成后续的 SAML 或 OIDC 交互。在 IdP 发起场景中，IdP 本身并不知晓应用的内部连接标识，因此转换层需要将 IdP 的身份映射回对应的 connection_id，再以标准 SP 发起流程的形式交给应用，从而实现两种流程的无缝衔接。

对开发者和企业的实际意义

对于构建 B2B SaaS 的团队而言，企业客户往往期望员工从 IdP 仪表盘无缝进入应用。如果应用不支持 IdP 发起流程，用户可能会遇到“点击图标后要求再次登录”的尴尬，或者被导向一个错误页面。WorkOS 的方案把这一体验缺口补上，同时不增加应用的认证负担。

从安全角度看，将 IdP 发起请求转换为标准流程，也有助于统一会话策略。应用可以继续使用已有的会话管理、多因素认证策略和审计日志，而不必为 IdP 发起路径单独开一个“后门”。不过，开发者仍需确保转换端点本身受到适当的防护，例如校验请求来源和签名，避免被滥用。

多因素认证（MFA） 是在密码之外增加一层验证（如短信验证码、TOTP 令牌、硬件密钥）的安全机制。在 SSO 场景中，MFA 通常由 IdP 在认证阶段执行，SP 侧则可能对高敏感操作追加二次验证。将 IdP 发起流程转换为标准 SP 发起流程后，应用可以继续沿用统一的会话策略和 MFA 策略，而不必为 IdP 发起路径单独设计一套验证逻辑。这降低了因流程分叉导致的安全策略遗漏风险，但也要求转换端点本身具备足够的防护，例如校验 IdP 签名、限制请求来源和防止重放攻击。

实施要点与注意事项

根据 WorkOS 的描述，集成工作集中在端点和连接映射上。开发者需要在 WorkOS 中配置好企业连接（connection），并在应用中提供一个登录端点来接收转换后的请求。当 IdP 发起点击时，WorkOS 负责完成与 IdP 的交互，并将带有 connection_id 的标准登录请求交给应用。

需要留意的是，这种转换依赖于 WorkOS 作为中间层。对于已经使用 WorkOS 的团队，这属于配置层面的增强；对于自建 SSO 的团队，则需要评估是否引入类似的中转逻辑。此外，IdP 发起流程的断言可能包含与 SP 发起不同的属性，转换层需要确保这些信息在标准流程中不丢失，尤其是用户标识和会话上下文。

总体来看，WorkOS 的思路是把复杂留在平台侧，让应用只面对一种登录形态。对于追求快速支持企业 SSO 的 SaaS 产品，这是一个值得关注的模式。