马力在知群最近我在给 sourcefare 做企业级改造，最头痛的问题就是账号体系乱七八糟。项目管理、文档中心、流水线、制品库这几个模块各自为政，每个系统一套用户名密码，用户天天记混，管理员开账号关账号跑到崩溃。正好赶上团队引入 soular 做统一认证登录，把 sourcefare 完整对接了一遍，整个过程踩了不少坑也沉淀了不少方法。这篇就把我实际操作中的方案选型、对接步骤、代码实现和排障记录完整整理出来，给准备做统一认证集成的朋友一个可以直接参照的实操样本。
先说结论：sourcefare 集成 soular 之后，用户不再需要为每个模块单独注册账号，一次登录全部通行，管理员只需要在 soular 里统一维护用户状态和权限，效率和安全性都上了一个台阶。如果你正在做类似的系统集成、企业内部平台建设、或者打算把老系统接入统一身份认证，这篇内容应该能帮你少走很多弯路。
1. 项目背景与统一认证选型：为什么 sourcefare 一定要接 soular
1.1 sourcefare 的现状与痛点
sourcefare 并不是那种只有一个后台服务的小项目，而是一套包含多个子系统的研发协同平台。项目初期各模块独立交付，每个模块都自己维护一套用户表，登录逻辑也各自实现。等到系统上线跑了一段时间，问题就暴露得很明显。
用户侧最直接的感受是密码记不住。项目管理系统一套密码、文档中心一套密码、CI/CD 平台又是一套密码，而且不同系统的密码策略还不一样，有的要求大小写字母数字，有的必须带特殊符号，用户只能在本地建个文本文件把密码全记下来。这本身就是巨大的安全隐患，一旦哪个系统的数据库泄露，用户习惯复用密码，其他系统也会跟着遭殃。
管理员侧更痛苦。新员工入职要在四五个系统里分别开账号，离职时要逐个禁用，漏掉任何一个都是安全隐患。部门调整、人员转岗时，各系统里的角色权限要跟着改，全靠人工操作，效率极低还容易出错。
做过企业内部系统的人应该都懂这种痛。我当时的判断是：如果继续放任各系统各自为政，后面每接入一个新的子系统，就要重复一遍账号体系搭建和权限维护的工作，技术债会越滚越大。统一认证这件事已经不只是“锦上添花”，而是必须尽早落地的刚需。
1.2 统一认证方案选型：为什么选 soular 而不是 LDAP 或自研
在做方案调研时，我们重点对比了三类路线：传统 LDAP/OpenLDAP+SSO 方案、完全自研认证中心、以及直接采用 soular 这类现成的统一认证平台。
LDAP 在传统企业 IT 里应用很广，很多公司用它做组织架构和账号数据的统一存储。但 LDAP 本身只是个目录服务，不是为 Web 登录设计的，要做 SSO 还得叠加 Kerberos、CAS 或者商用 SSO 网关，改造工作量和复杂度都不低。尤其是 sourcefare 这种纯 Web 形态的系统，LDAP 原生的绑定认证方式体验并不好，登录页跳转和会话管理都要自己造轮子。
自研认证中心的路子我们也考虑过，评估之后放弃了。认证中心涉及密码存储、会话管理、token 签发与校验、审计日志，任何一个环节出问题都是安全事故。我们团队的核心精力应该放在业务系统上，不值得为认证这件事投入大量人力长期维护。
最后选中 soular，主要看中几点：它基于 OIDC/OAuth2.0 这套成熟协议栈，不搞私有协议，后续其他系统对接成本低；自带用户管理和应用管理界面，不需要我们自己写管理后台；支持与下游应用做标准 SSO 会话同步；而且 soular 是 Java 生态，跟我们 sourcefare 的技术栈一致，遇到问题可以直接看源码排查，二次开发也比较方便。
1.3 统一认证后带来的实际变化
对接完成后，sourcefare 的账号体系从原来的多套并存收敛为一套。用户只需要在 soular 里登录一次，就能在所有已接入的子系统间免登录跳转。新员工入职时管理员只需在 soular 里创建一个账号并分配好应用权限，sourcefare 的各个模块在用户首次登录时自动完成账号初始化。离职员工在 soular 里禁用账号后，所有子系统立即失去登录能力，不再存在“漏禁”的隐患。
更重要的是登录行为可审计了。soular 记录每一次登录成功/失败的详情，包括时间、IP、User-Agent，一旦出现异常登录可以快速追溯。这对安全合规来说是刚需，以前各系统各自记录、格式不统一，真要查日志的时候非常痛苦。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 上手前必做的四项准备：soular 账号体系与 sourcefare 配置对齐
2.1 soular 认证机制的核心逻辑
在动手写代码之前，先把 soular 的认证机制弄清楚，后面集成才不会懵。soular 核心走的是 OIDC（OpenID Connect）协议，基于 OAuth2.0 的授权码模式扩展了身份层。
整个登录流程用大白话讲是这样的：用户在 sourcefare 点击“统一认证登录”，系统把用户引导到 soular 的登录页；用户在 soular 输入用户名密码登录成功后，soular 生成一个一次性授权码（authorization code），并通过浏览器重定向方式回调到 sourcefare 指定的地址；sourcefare 后端拿这个授权码去 soular 的 token 接口换 access_token 和 id_token；再拿 id_token 或调用用户信息接口拿到用户身份，就能在本地建立会话了。
这个机制的关键在于授权码是一次性的、短时的，即使被截获也无法长期使用。id_token 里带着用户的基本信息，sourcefare 可以通过签名校验其真实性，避免每次都要去 soular 查用户信息。
2.2 soular 控制台创建应用：注册资料要一次拿全
在 soular 管理后台创建应用是第一步，这一步资料拿不全，后面配置就得反复改。我在 soular 的“应用管理”里新增了一个应用，类型选择 OIDC，填写应用名称 sourcefare，然后设置回调地址。
回调地址是灵魂配置。soular 登录成功后只会把授权码回调到预先登记的地址上，如果地址不一致直接拒绝回调，错误信息一般显示“redirect_uri mismatch”或者“invalid request”。我填的是后端接口地址：https://sourcefare.example.com/api/auth/soular/callback，这个地址必须是完整的 URL，包含协议、域名、端口和精确路径。
创建完成后 soular 会生成 clientId 和 clientSecret。clientId 相当于应用的身份证号，clientSecret 是应用和 soular 之间的通信密钥，这个务必保存好，它等同于密码，泄露了别人可以冒充你