🤔 开场白：你真的分清楚了吗？

在面试中，问到 SSO 和 OAuth2.0 的区别，十个人里面起码有八个答错。

有人说："SSO 不就是 OAuth2.0 吗？都是登录嘛。"

有人说："OAuth2.0 就是第三方登录啊，和 SSO 一样一样的！"

😅 然而这两个概念，虽然长得像亲戚，但解决的根本问题完全不同。

一句话总结：

 

🔐 SSO：解决的是「我不想登录那么多次」的问题  🔑 OAuth 2.0：解决的是「我不想把密码给你」的问题

 

接下来，我们用最接地气的方式，把这两个概念彻底讲清楚。

 

 

一、🔐 SSO 单点登录 — "一把万能钥匙"

1.1 什么是 SSO？

SSO（Single Sign-On，单点登录）的核心思想很简单：

你在公司上班，需要用到 OA 系统、HR 系统、报销系统、GitLab……每天早上一个个输密码，你烦不烦？

 

💡 SSO 的答案就是：登录一次，所有系统全通！ 你只需在统一的认证中心登录，之后访问任意子系统，都自动免登录。

 

这就像进入一栋大楼刷了门禁卡，楼里各层的门都自动打开，不用每层单独刷卡。

 

1.2 SSO 的工作原理

经典的 SSO 流程（基于 CAS 或 SAML）如下：

 

▲ SSO 单点登录流程：一次登录，多系统通行

 

• ① 用户访问系统 A，发现未登录，跳转到统一认证中心（IdP）

• ② 用户在 IdP 输入账号密码完成登录，IdP 签发一张「全局票据」（Token）

• ③ 用户带着票据访问系统 A，系统 A 去 IdP 验证票据有效，放行！

• ④ 接着访问系统 B，IdP 发现已登录，直接颁发子票据给系统 B，无需再次登录

• ⑤ 注销时，IdP 通知所有系统同步清除登录态（Single Logout）

 

1.3 代码示意：JWT Token 验证逻辑

// 伪代码：SSO 子系统验证 IdP 颁发的 JWT Token function validateSSOToken(token) {   const payload = jwt.verify(token, SSO_PUBLIC_KEY);   if (payload.exp < Date.now() / 1000) {     throw new Error("Token 已过期，请重新登录");   }   return {     userId: payload.sub,     roles:  payload.roles,     ssoSession: payload.sessionId  // 全局会话 ID，退出时同步注销   }; }

 

1.4 SSO 的使用场景

• 🏢 企业内部多系统统一登录（OA + HR + ERP + GitLab）

• 🏫 高校统一身份认证（教务 + 邮件 + 图书馆）

• ☁️ 云服务商多产品统一登录（阿里云旗下各产品）

 

⚠️ 关键特征：SSO 所有系统在同一信任域内，用户只有「登录/注销」的行为，没有「授权」第三方的概念。

 

 

二、🔑 OAuth 2.0 授权 — "受控的钥匙借用"

2.1 什么是 OAuth 2.0？

OAuth 2.0（开放授权协议）解决的是一个不同的问题：

你想用某个 App 看你的微信好友列表，但你不可能把微信密码给这个 App！

 

💡 OAuth 2.0 的答案：不给密码，只给一张有限权限的「授权令牌」！ 你在微信上点击「授权」，微信颁发一个有效期短、权限受限的 Access Token 给第三方 App。

 

这就像你不把房子钥匙给快递员，而是给他一张只能打开门禁的临时通行证，限时有效。

 

2.2 OAuth 2.0 的四个角色

OAuth 2.0 里有四个关键角色，记住这四个，整个协议就通了：

 

角色	中文名	举例说明
Resource Owner	资源所有者（你）	微信账号的主人
Client	客户端（第三方 App）	想获取好友列表的 App
Authorization Server	授权服务器	微信的授权中心
Resource Server	资源服务器（API）	存好友列表的服务器

 

2.3 OAuth 2.0 核心授权流程

以最常用的「授权码模式」（Authorization Code Flow）为例：

 

▲ OAuth 2.0 授权码模式流程

 

// 授权码模式完整流程（以微信登录为例）   // Step 1：引导用户跳转授权页 GET https://open.weixin.qq.com/connect/oauth2/authorize     ?appid=YOUR_APP_ID     &redirect_uri=https://yourapp.com/callback     &response_type=code     &scope=snsapi_userinfo   // Step 2：用户点击授权后，微信回调携带 code GET https://yourapp.com/callback?code=AUTH_CODE&state=xxx   // Step 3：后端用 code 换取 access_token（不暴露给前端！） POST https://api.weixin.qq.com/sns/oauth2/access_token      ?appid=APP_ID&secret=APP_SECRET&code=AUTH_CODE&grant_type=authorization_code   // Step 4：用 access_token 访问资源 API GET https://api.weixin.qq.com/sns/userinfo     ?access_token=ACCESS_TOKEN&openid=OPENID

 

2.4 OAuth 2.0 四种授权模式

OAuth 2.0 有四种授权方式，不同场景用不同模式：

 

• 🏆 授权码模式（Authorization Code）：最安全，适合服务端 Web App

• 📱 隐式模式（Implicit）：适合纯前端 SPA，已逐渐被 PKCE 替代

• 🔧 密码模式（Password）：用户直接提供账密，仅限高信任场景（不推荐）

• 🤖 客户端凭证模式（Client Credentials）：无用户参与，机器间 M2M 调用

 

2.5 OAuth 2.0 的使用场景

• 📲 第三方登录：微信/QQ/GitHub 登录第三方 App

• 🔗 开放 API 授权：允许第三方读取你的数据（如授权某 App 读取日历）

• 🤝 平台开放生态：开放平台对第三方开发者的 API 授权管理

 

 

三、⚔️ SSO vs OAuth 2.0 — 一张表彻底对比

先看对比图总览：

 

▲ SSO vs OAuth 2.0 核心差异对比

 

对比项	🔐 SSO 单点登录	🔑 OAuth 2.0 授权
核心目标	一次登录，到处通行	授权第三方访问我的资源
使用场景	企业内部多系统统一登录	第三方 App 获取授权
典型例子	钉钉登一次进所有内部系统	微信登录第三方 App
解决的问题	多系统重复登录烦	不暴露密码给第三方
协议依赖	SAML / CAS / OIDC	OAuth 2.0 / JWT
信任关系	同一信任域内的系统	跨信任域的第三方
用户感知	无感，自动跳转通过	需手动点击"授权"按钮

 

3.1 核心差异一句话总结

🎯 SSO = 解决「多系统重复登录」 → 同一公司多产品，用户体验升级  🎯 OAuth 2.0 = 解决「第三方安全授权」 → 跨公司数据共享，权限可控可撤销

 

3.2 它们的关系

很多人问：OAuth 2.0 和 SSO 有没有关系？

答案是：它们不是同一个维度的概念，但可以组合使用！

 

• OpenID Connect（OIDC）= OAuth 2.0 + 身份认证层，常用于实现 SSO

• 企业级 SSO 内部可以用 OAuth2.0 的 Token 机制来实现跨系统凭证传递

• 但 SSO 不等于 OAuth，OAuth 也不等于 SSO，二者目标不同

 

🌟 记忆口诀： SSO → "我只想登录一次" OAuth 2.0 → "我只给你有限授权，密码不奉告"

 

 

四、🚫 常见误区 & 防坑指南

误区 ① SSO 就是用了 OAuth，不需要单独建认证中心

❌ 错误。SSO 需要一个独立的认证中心（IdP），OAuth 是授权框架，不是 SSO 的实现方式。

✅ 正确做法：可以用 Keycloak / CAS / Okta 搭建企业 SSO，其中可以集成 OAuth 2.0/OIDC 协议。

 

误区 ② OAuth 2.0 就是登录，不是授权

❌ 错误。OAuth 2.0 本质是「授权框架」，登录只是一个附带功能（通过 OIDC 扩展实现）。

✅ 正确做法：需要登录功能时，应该用 OpenID Connect（基于 OAuth 2.0 的身份层）而不是裸 OAuth。

 

误区 ③ 把 access_token 存在 localStorage，安全呢

❌ 危险！localStorage 容易被 XSS 攻击盗取 Token，造成账号劫持。

✅ 正确做法：access_token 存 httpOnly Cookie，配合 CSRF 防护；或采用 BFF（Backend for Frontend）模式。

 

// ❌ 危险：Token 暴露在 JS 可访问的地方 localStorage.setItem("access_token", token);   // ✅ 安全：后端设置 httpOnly Cookie，JS 无法读取 res.cookie("access_token", token, {   httpOnly: true,   // JS 不可读   secure: true,     // 仅 HTTPS   sameSite: "Lax"   // 防 CSRF });

 

 

五、📌 总结

我们用一张对比表 + 三句话来收尾：

 

• 🔐 SSO = 企业内统一登录体验，「登录一次，到处通行」

• 🔑 OAuth 2.0 = 跨平台安全授权框架，「不给密码，只给令牌」

• 🔗 OIDC = OAuth 2.0 + 身份认证 = 两者的最优结合拳

 

面试被问到这个问题，你只需要说：

 

「SSO 和 OAuth 2.0 解决的是不同层次的问题。 SSO 关注的是用户在同一信任域内的多系统无感切换； OAuth 2.0 关注的是跨信任域的安全授权委托。 实际上，企业级 SSO 方案（如 Keycloak）常常以 OIDC（OAuth 2.0 扩展）为底层协议。」

​

阅读原文：https://mp.weixin.qq.com/s/1UNeWMQkDxgi9EBMgpdtlw