在高校或大型企业私有化部署心理测评平台时，客户往往会提出一个让初级销售和研发极其头疼的需求：“你们的系统能不设口令吗？我们学校已经有了统一的‘校园门户/一卡通’，我们要求学生登上去之后，点一下你们的图标就能直接进入心理系统。”
对于很多只写过普通账号口令登录（用户名+MD5口令存表里）的团队来说，这仿佛是一个无解的难题。因为心理系统根本拿不到客户内部的明文口令来做校验。
这其实就是业界经典的 SSO（Single Sign-On，单点登录）问题。本文将剥开 SSO 神秘的外衣，探讨在 B 端心理 SaaS 的落地中，最常用的两种单点登录对接方案，并指出其中极易踩坑的致命细节。
方案一：基于 OAuth 2.0 或 OIDC 的标准对接（推荐）
如果客户的 IT 部门非常专业，他们提供的统一身份认证平台（Identity Provider, IdP）通常会支持标准的 OAuth 2.0 或 OIDC 协议。
在这种模式下，心理系统（作为 Service Provider, SP）的登录页不再有输入口令的地方，而是变成一个按钮：“通过校园门户登录”。
其交互流程极其优雅：
- 学生点击按钮，被重定向到学校门户的授权页面（带上心理系统的
client_id）。 - 学生在学校门户输入账号口令（口令全程不经过心理系统，极其安全）。
- 验证成功后，学校门户将学生重定向回心理系统的回调地址，并附带一个临时授权码（Auth Code）。
- 心理系统的后端拿着这个 Auth Code，在后台秘密向学校门户的接口发起请求，换取 Access Token，并进一步获取该学生的
学号和姓名。
正如橙星云研发团队在实战中摸索出的最佳实践：心理系统在拿到 学号 后，会在自己的数据库 users 表中进行匹配（根据学号或关联的 OpenID）。如果该学生是第一次来，系统会静默为他创建一条基本档案记录（即时同步），并立刻颁发自己系统的 JWT 令牌，让其无缝进入测验页面。
方案二：老旧系统的霸王硬上弓——基于非对称加密的 Token 直传
很多传统高校的系统是十几年前外包公司写的，根本不支持什么 OAuth。他们只提供一种简单粗暴的跳转：
在他们的系统中点一个链接，跳转到 https://psy.yourschool.edu/sso/login?token=xxxxxx。
如果这个 token 只是一个简单的 Base64 编码的学号（比如 student_id=2023001），那简直是灾难。任何懂点技术的学生都可以随意篡改 URL 中的学号，瞬间越权登录成班级里其他同学甚至辅导员的账号，查看全校机密心理档案。
强硬防线：时间戳与 RSA 签名
对于这种非标准对接，技术团队必须向客户的 IT 部门强制提出最低安全标准：URL 中的参数必须包含极短有效期，且必须经过非对称加密（RSA）或强哈希签名（HMAC）。
在对接设计中：
- 客户系统在跳转前，拼接一段原文字符串：
学号=2023001&过期时间戳=1690000100。 - 客户使用私钥对这段原文进行签名，并将原文和签名一起作为参数传递过来。
- 心理系统接收到请求后，第一步：立刻使用约定的公钥验证签名，防止任何伪造；第二步：提取时间戳，如果发现当前时间超过了该时间戳（说明这个链接是被截获后重放的），直接拒绝访问；第三步：全部校验通过，才放行并签发本地登录态。
SSO 对接中的隐藏大坑：用户数据的组织隔离
搞定了登录，事情才完成了一半。
最容易被忽视的，是心理平台特有的“组织架构隔离”属性。
当学生第一次通过 SSO 登录时，系统如果只知道他的姓名和学号，是无法为他安排量表的，因为系统不知道他是哪个学院、哪个班级的！
因此，在对接时必须明确要求客户的接口：在返回用户信息的 Payload 中，必须包含其完整的层级部门字段（例如 {"dept": ["计算机学院", "软件工程系", "23级1班"]}）。
后端在静默注册该用户时，需要将这些文本路径转化为心理系统内部的 dept_id。如果发现传过来的班级在系统中还不存在，甚至需要触发自动创建班级节点的补偿逻辑，否则这名学生就会沦为游离在组织架构之外的“孤儿节点”，永远无法出现在班主任的统计报表中。
总结
在 B 端交付中，SSO 单点登录是打通客户生态孤岛的关键桥梁。
它绝不仅仅是一个简单的接口调用，而是对安全签名、重放攻击防御以及底层组织架构映射的一次综合大考。掌握了这些硬核对接策略，技术团队就能在面对极其强势的甲方 IT 部门时，从容不迫地给出无懈可击的安全对接方案。