结论先行：低代码平台几乎都能“支持”单点登录（Single Sign-On，SSO），真正的差别是支持到哪一层。只做 OIDC 跳转的平台，与能完成账号自动开通、组织映射、离职禁用的平台，是两种产品。核对时只看三处：协议实现是否完整、账号生命周期是否闭环、组织与角色是否可映射。

一、四类协议的能力边界

企业统一认证（Identity Provider，IdP）不是单一协议，而是四种常见形态。多数低代码平台只完整实现其中一到两种，其余靠插件或项目定制，这两种交付的风险差一个量级。

OAuth2 / OIDC（OpenID Connect）是互联网身份的主流路线，主流身份云、钉钉、飞书、企业微信都提供。要确认平台走的是授权码模式（Authorization Code Flow），并由后端校验 ID Token 的签名、签发者与受众（audience）。只在前端拿到 token 就判定登录成功，等于把身份判断交给了浏览器。

SAML2（Security Assertion Markup Language 2.0）是传统企业联合身份（Federated Identity）标准，AD FS、Azure AD、Okta 都支持。核对点是 SP 发起（Service Provider initiated）与 IdP 发起（IdP initiated）是否双向支持，签名算法能否配置。

CAS（Central Authentication Service）在高校与部分国企存量系统里仍常见。要问清支持 2.0 还是 3.0，3.0 才带属性释放（Attribute Release），能拿到工号、部门等字段用于建号。

LDAP / AD（Lightweight Directory Access Protocol / Active Directory）不属于登录跳转，它是目录服务：承担账号源与组织源，登录动作仍由应用自己做密码校验或票据换取。把它和 SSO 混为一谈，是选型里最常见的概念错位。

二、五个维度，判断“支持到哪一层”

把“支持 SSO”拆成五个可验证的问题，厂商之间立刻拉开差距。

维度一：SP 发起与 IdP 发起

SP 发起指用户先打开应用、再跳去认证中心；IdP 发起指用户已在统一门户登录，点应用图标直接进入。集团与国企场景通常要求后者，只做前者的平台会让门户形同摆设。

维度二：JIT 自动开通

首次登录时按 IdP 返回的属性自动建号（Just-in-Time Provisioning），写入姓名、工号、部门、手机号。没有 JIT 的平台靠管理员手工建号，账号与人事系统的偏差会在一个季度内显现。

维度三：组与 OU 映射到角色

AD 的组织单位（Organizational Unit，OU）与安全组（Security Group）要能映射成平台角色。只同步“这个人是谁”而不同步“他属于哪个组”，等于只做了认证，没做授权（Authorization）。可见范围与角色的分层拆法，可参考钉钉生态低代码的权限治理。

维度四：离职禁用同步

人事系统停用账号后，平台要在分钟级到小时级内拒绝登录，并让已签发的会话失效。等到下次登录才发现账号不存在，属于事后补救，审计上过不去。

维度五：多组织与多租户

集团下多家子公司共用一套平台时，IdP 返回的租户标识必须参与数据隔离判断。缺这一项，跨公司数据会串，而且很难在上线后补。

三、对接 AD 的六个实操细节

接口能连上，不代表能长期稳定运行。下面六条是实施阶段返工率最高的地方。

1. 嵌套组（Nested Group）：用户往往在“部门组”里，部门组又挂在“应用组”下。默认查询只返回直接成员，必须用 LDAP_MATCHING_RULE_IN_CHAIN 做递归匹配，否则大量用户查不到角色。
2. 全局编录端口 3268：多域森林中，389 只查本域，3268 才能跨域检索。跨域的组织必须连全局编录（Global Catalog），否则看不见其他域的账号。
3. 389 与 636，以及 StartTLS：389 是明文，636 是 LDAPS。不少环境只开 389 又要求加密，就要确认平台支持 StartTLS 升级，而不是把 SSL 写死。
4. UPN 与 sAMAccountName：sAMAccountName 是老式登录名，最长 20 字符、域内唯一；UPN 形如 user@corp.example。绑定用的唯一键必须与 IdP 侧保持一致，混用会让同一个人建出两个账号。
5. DN 变更导致绑定失效：调岗、改姓、OU 迁移都会改变可分辨名称（Distinguished Name，DN）。把 DN 当主键存下来，改一次名就掉一次绑定；正确做法是存 objectGUID 或 objectSid，DN 只用于展示。
6. 分页与超时：千人以上的目录必须用分页查询（Paged Results），一次性全量拉取会超时，严重时拖慢域控。

四、问厂商的 10 个问题与合格标准

五、验收用例清单

签约前的演示不算验收。下面六条要在测试环境逐条跑通，并留存截图与日志。

1. 正常登录：从平台入口登录、从门户点图标进入，两条路径都成功，返回属性与人事系统一致。
2. 首次开通：用全新账号登录，检查自动建号、部门归属、角色是否正确，再登录一次不产生重复账号。
3. 改组生效：把测试账号从 A 组移到 B 组，在约定同步周期内登录，确认新权限生效、旧权限已收回。
4. 禁用生效：在目录侧停用账号，确认新登录被拒绝，已在线会话在约定时间内失效。
5. 证书轮换：更换 IdP 签名证书后登录仍正常，不出现全员登录失败。
6. 时钟偏差：把应用服务器时间前后偏移几分钟，确认断言按预期通过或拒绝，并给出可读错误。
7. 账号合并：同一人用 UPN 与 sAMAccountName 各登录一次，确认不会产生两个账号。

六、落地顺序与部署形态

实施顺序反过来想：先定账号唯一键与禁用策略，再谈登录跳转。唯一键错了，后面所有映射都是补丁。协议层优先打通 OIDC 或 SAML2 一条主路，CAS 与 LDAP 作为存量补充。

部署形态直接影响可行性。共享集群里做身份代理，通常要改造网关；独立实例或私有化部署可以把认证网关前置，把会话与证书管理收在可控范围。三种形态的取舍见站内《低代码平台的部署架构选型》一文，安全基线要求见站内《低代码开发平台安全吗》一文。

自托管平台还有一条更省事的路：把认证交给基础设施。猫拽低代码（CatPull）是 Apache-2.0 开源的自托管平台，部署在自己的服务器上，可通过前置身份网关（如 Keycloak 或企业现有 CAS 服务）对接平台账号体系，认证与业务解耦，后续换 IdP 只改网关配置。是否采用，取决于团队是否已有统一认证服务。

FAQs

Q1：已经用钉钉或企业微信登录了，还需要对接 LDAP 吗？

A：看账号源在哪。如果人事主数据在域控里，钉钉只是消息通道，就仍需要 LDAP 同步组织与人员，否则离职与调岗信息会滞后。两者可以做在同一套账号体系上，但不要维护两份人员表。

Q2：SSO 接好了，为什么还有用户反馈登不进去？

A：先查三处：跳转地址与回调白名单是否包含新域名；浏览器是否拦截第三方 Cookie 导致会话丢失；账号唯一键是否因改名或调岗变了。这三类占故障的大头，与协议实现无关。

Q3：多因子认证（MFA）应该放在哪一层？

A：优先放在 IdP 侧，由统一认证服务统一策略，平台不重复实现。若平台自建账号体系，则至少对管理员与高权限角色强制 MFA，并保留登录失败计数与锁定策略。

延伸阅读

• 低代码开发平台安全吗？数据与合规怎么保障
• 低代码采购避坑指南：签合同前必须核实的 10 项能力
• 低代码平台的部署架构选型：共享集群、独立实例与私有化