SSO 和 OAuth 2.0 的区别（2026 年最清晰对比版）
简单一句话总结：
- SSO（单点登录） 是一种用户体验机制：用户一次登录，就能访问公司/组织内的多个系统。
- OAuth 2.0 是一种授权框架/协议：允许用户授权第三方应用访问自己在某个服务上的资源（而不把账号密码给第三方）。
它们经常一起出现，但本质上是解决不同问题的两个东西。
核心区别对比表（2026 年视角）
| 维度 | SSO（单点登录） | OAuth 2.0 | 谁更像谁？ |
|---|---|---|---|
| 核心目的 | 一次登录，多系统免登录（统一身份认证） | 授权第三方应用访问用户资源（不暴露密码） | 完全不同 |
| 解决的问题 | 内部多个系统重复登录的痛苦 | “用微信/QQ/谷歌登录”这种场景 | — |
| 典型场景 | 企业内部系统（如 OA、HR、财务、邮箱、CRM） | 第三方 App 用微信登录、用 GitHub 授权访问仓库 | — |
| 是否传递密码 | 通常不传明文密码（内部统一身份源） | 绝对不传密码，只传 access token | OAuth 更安全 |
| 用户身份归属 | 身份属于组织/公司内部（企业身份提供者 IdP） | 身份属于第三方平台（如微信、Google、GitHub） | — |
| 授权范围 | 通常全域（登录后能访问公司所有允许的系统） | 细粒度（scope）：只给读邮箱、只给改资料等 | OAuth 更精细 |
| 协议标准 | 没有统一标准，常见实现：SAML、CAS、OpenID Connect、Kerberos | 国际标准协议（RFC 6749 + 扩展） | OAuth 是标准 |
| 现代主流实现 | OpenID Connect（OIDC）+ OAuth 2.0 | OAuth 2.0（常与 OIDC 一起用） | 高度重叠 |
| Token 类型 | 通常是 Session Cookie 或 JWT | Access Token（短期） + Refresh Token（长期） | 不同用途 |
| 典型流程 | 用户 → IdP 登录 → 发票据 → 各系统验证票据 | 用户 → 第三方 App → 授权服务器 → 同意 → 回调给 App token | 流程完全不同 |
| 谁持有用户凭证 | 组织自己的身份系统（AD、LDAP、Keycloak 等） | 资源拥有者（如微信、Google） | — |
2026 年真实场景分类（最容易混淆的几种情况）
| 你看到的现象 | 其实是什么？ | 为什么很多人分不清？ |
|---|---|---|
| 公司内网一次登录，所有系统都免登录 | 经典 SSO（可能基于 SAML/OIDC） | — |
| 用微信扫码登录某个小游戏/网站 | OAuth 2.0（微信作为授权服务器） | — |
| 用 Google 账号登录 Notion/Jira/Slack | OAuth 2.0 + OpenID Connect | 因为同时实现了“登录”和“授权” |
| 阿里内网/腾讯 TAPD/字节飞书一次登录全家桶 | 企业级 SSO（通常基于 OIDC） | 底层很可能用了 OAuth 2.0 框架 |
| “企业微信登录”某个第三方 SaaS | OAuth 2.0（企业微信做 IdP） | 看起来像 SSO，其实是标准 OAuth 授权流程 |
2026 年最扎心的结论（从业者共识）
- 纯 SSO：现在已经很少单独存在了，大部分现代“单点登录”其实是 OpenID Connect（OIDC） 在做，而 OIDC 是建立在 OAuth 2.0 之上的身份层。
- 所以你今天看到的绝大多数“公司级/平台级单点登录”，底层基本都是 OAuth 2.0 + OIDC 的组合。
- 真正“只用 OAuth 2.0 不带 OIDC”的场景，主要就是纯授权（比如第三方 App 只想读你的 Google 日历，不需要知道你是谁）。
一句话总结区别：
- 想解决“我不想每个系统都登录一次” → SSO（现代实现基本是 OIDC）
- 想解决“这个 App 想用我的微信资料，但我不想把微信密码给他” → OAuth 2.0
你现在是在做企业内部 SSO，还是在做第三方登录/开放平台授权？
可以告诉我具体场景，我能给你更针对性的技术选型和注意事项～
