前阵子有人在技术群里抛了个问题:“你都知道哪些登录?”底下回答很快就歪了:有说账号密码登录的,有说短信验证码登录的,有说扫码登录的,也有人直接抛出来“OAuth2.0联合登录”“SSO单点登录”。开始大家聊得挺热闹,等有人问“那 OAuth2.0 联合登录和 SSO 单点登录到底有什么区别”时,群里反而冷场了。这话题我在实际项目里被问过不止一次,尤其是有人把第三方联合登录直接当成单点登录来设计,最后权限全部乱掉。这篇就把这两种登录方式彻底拆开讲清楚:它们各自解决什么问题,核心流程是什么,真实落地的配置应该怎么接,以及后续你在企业系统里对接 NC65、致远OAV8这类产品时会踩到的坑。适合后端开发、架构师,也适合负责企业系统集成的实施同学,内容偏工程实践,不会只堆概念。
1. 先把登录这件事梳理清楚
1.1 登录的本质不是“输入密码”
不管对外做成什么样,登录的逻辑最终都逃不开三件事:确认你是谁、给你发凭证、系统每次认这个凭证。传统表单登录是输入账号密码,服务端验证后写 Session;短信验证码登录本质是拿你手机号作为身份标识,确认你拥有这个手机号后签发凭证;扫码登录则是让 App 端帮你完成身份确认,然后网页端拿到一个临时凭证再换正式登录态。
这些东西落到产品形态上可以千奇百怪,再叠加企业微信、钉钉、Github 之类的第三方登录方式,整个认证体系就越来越复杂。写代码时大家常说的“登录”,其实通常只指“给这个系统做一套 Session 机制”。而单点登录和联合登录,已经远远超过“一个系统认证”的范畴,它们是在解决多个系统、多个业务方之间的身份互信问题。
我习惯把登录需求分成三层来理解:
- 单系统登录:用户只在你这套系统里认证,服务端维护登录态。
- 联合登录:用户用第三方平台身份登录你的系统,本质是“借第三方来验证账号”。
- 单点登录:一个企业或一个产品矩阵内,用户在一个系统登录,其他系统自动可用。
很多人混淆 OAuth2.0 联合登录和 SSO 单点登录,根源就是把“用什么身份验证”和“验证一次后能否访问多个系统”混在了一起。前者决定你信谁,后者决定你认几次。
1.2 OAuth2.0、联合登录、SSO 到底是什么关系
先把定义摆正。OAuth2.0 本身是“授权框架”,它设计出来的目的并不是为了做登录,而是让第三方应用在用户授权之后,有限制地访问用户在其他平台上的资源。说人话就是:用户在自己的系统里,授权某个应用帮他获取资源,但不需要把平台账号密码交给这个应用。
而联合登录,在我们日常语境里基本等于“使用 OAuth2.0 协议做身份认证”。应用把你引导到第三方平台,第三方平台确认你本人后,给应用一个 code,应用再用 code 换 token,最后拿 token 获取用户信息。所以联合登录是基于 OAuth2.0 的一种常见业务形态,但它不是唯一形态。
SSO 单点登录则是一个更大的概念。它关心的是:同一用户在公司内部多个系统之间切换时,能不能只认证一次。实现 SSO 可以用共享 Session,也可以用 CAS、SAML、OIDC 等协议,也可以基于 OAuth2.0 改造。很多企业做“统一身份认证平台”,在 Web 形态下给子系统发 token 来维持登录态,这在工程上层面上和 OAuth2.0 很像,但它的业务目标已经不一样了。
用一句话区分就是:联合登录解决“第三方身份如何被我的系统信任”,SSO 解决“同一个身份体系下,多个系统如何共享认证结果”。如果你要做的是一套公司内部的统一登录平台,优先想的是 SSO 架构;如果你的产品要支持“微信登录”“Github 登录”,优先想的是 OAuth2.0 联合登录。
1.3 选择方案前先问清业务场景
在项目初期,我会先让业务方回答几个问题,这些问题往往直接决定认证方案。
第一个问题是:用户账号从哪来?账号只在自己的用户表里,那就做最基本的账号密码+Session;如果用第三方账号,就是联合登录;如果组织用户来自企业 AD/LDAP 或统一身份源,那么大概率需要 SSO,至少需要一个统一认证中心。
第二个问题是:登录之后要访问几个系统?只访问一个后台管理系统,没必要强行上 SSO;要同时进 ERP、OA、报表、运维平台,还不希望每个系统都登录一遍,那就必须上 SSO。
第三个问题是:系统之间有没没有现成的信任关系?同一家公司自研的多个系统,可以通过中心认证实现 SSO;第三方产品如 NC65、致远OAV8,往往只对外暴露某个接口或配置项,这时候就要判断用哪一种接入方式最省事。
等这几个问题有答案了,后面 OAuth2.0、CAS、OIDC、自定义票据方案的取舍才会有依据。反正我见过最多返工的项目,不是因为协议写得不好,而是压根没搞清楚该做联合登录还是单点登录,就把两套方案叠上去,最后到处都是 session 冲突。
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. OAuth2.0 联合登录的核心流程与落地细节
2.1 授权码模式依然是首选
OAuth2.0 有几种授权模式,名称容易让你晕,实际场景里能稳定用于联合登录的,基本就是授权码模式(Authorization Code)和带 PKCE 的授权码模式。
早期的隐式授权(Implicit)已经不推荐用于纯前端应用,因为它直接把 access_token 放在回调地址里面,token 被浏览器历史、日志、Referer 头泄露的风险很高。密码模式(Resource Owner Password Credentials)要求用户把账号密码直接交给第三方应用,和“联合登录避免泄露密码”的设计初衷冲突,在 Web 联合登录里也少见。客户端模式(Client Credentials)用于服务器之间的机器身份认证,没有真实用户参与,不适合做用户登录。
授权码模式之所以稳,是因为它把“让用户授权”和“换 toke
