当前位置：首页 > news >正文

别再把 OIDC 和 OAuth 2.0 搞混了：写给开发者的通俗指南

news 2026/6/12 8:22:55

🔑 别再把 OIDC 和 OAuth 2.0 搞混了：写给开发者的通俗指南

在现代 Web 开发中，我们几乎每天都在和“第三方登录”打交道。无论是“使用 GitHub 登录”还是“使用微信扫码”，背后都离不开两个如雷贯耳的名字：OAuth 2.0和OIDC (OpenID Connect)。

这两个概念经常像连体婴儿一样同时出现，导致很多开发者误以为它们是同一个东西。但事实上，它们解决的是两个截然不同的核心问题：授权（Authorization）与认证（Authentication）。

今天，我们就用最通俗的语言，彻底理清它们的恩怨情仇。

1. OAuth 2.0：只认“门禁卡”，不认人

OAuth 2.0 诞生得比较早，它的核心使命只有一个：授权（Authorization）。也就是说，它用来决定“你能做什么”。

🏢 核心类比：酒店的电子房卡
想象你去住酒店，前台给你发了一张电子房卡。你可以用这张卡刷开 302 房间的门，也可以刷开酒店健身房的门。
但是，门禁系统并不知道你是谁。它只认卡不认人。就算这卡是你捡来的，只要卡是真的，门就会开。

在 OAuth 2.0 的世界里，这张“房卡”叫做Access Token（访问令牌）。
当你的应用拿到 Access Token 后，就可以代表用户去调用第三方平台的 API（比如读取他的 GitHub 仓库，或者操作他的百度网盘）。至于屏幕前的这个用户叫什么名字、长什么样，纯粹的 OAuth 2.0 是不管的。

2. OIDC：站在巨人肩膀上的“身份证”

随着时间推移，开发者们发现了一个大问题：我们需要单点登录（SSO）！我们需要知道用户到底是谁！

早期，大家只能拿着 OAuth 2.0 的 Access Token 去强行客串“认证”功能——拿着 Token 去调一次对方的/user接口，看看返回什么名字。但这导致了极大的混乱，因为每个大厂的接口格式都不一样。

为了解决这个问题，OIDC (OpenID Connect)诞生了。它不是来替代 OAuth 2.0 的，而是构建在 OAuth 2.0 之上的一个扩展协议。它专门负责：认证（Authentication）。

🪪 核心类比：带照片的员工胸牌
OIDC 就像是你在公司佩戴的员工胸牌。上面印着你的名字、部门、照片，并且盖了公司行政部的公章。
保安（第三方应用）只要低头看一眼你的胸牌，就能瞬间确认你的身份，根本不需要打电话给行政部确认。

在 OIDC 的世界里，这张“胸牌”叫做ID Token。它通常是一个JWT (JSON Web Token)。

解码一个典型的 ID Token，你会看到类似这样的标准化信息：

{"iss":"https://accounts.google.com",// 颁发者：证明这是 Google 盖章的"sub":"10023948576",// 用户的唯一 ID"name":"刘伟清",// 用户的真实姓名"email":"developer@example.com",// 用户的邮箱"exp":1680000000// 凭证过期时间}

3. 终极拷问：为什么有了 Access Token，还要搞个 ID Token？

很多开发者会问：“既然我能用 Access Token 去请求 API 拿到用户信息，为什么 OIDC 非要多发明一个 ID Token 呢？”

核心原因在于性能和标准化：

零网络延迟：
使用 Access Token，你的服务器必须发起一次 HTTP 网络请求去问第三方平台“这人是谁”。而 ID Token 是一个自带签名的 JWT。你的应用拿到它后，在本地直接解码校验即可，省去了一次耗时的网络往返。
天下同文：
如果没有 OIDC，你接 GitHub 登录要解析login字段，接 Twitter 要解析screen_name。而 OIDC 强制规定了所有平台必须使用标准的字段名（如name,email等），让你的一套代码可以吃遍天下。

4. 总结：我到底该用哪个？

在实际的架构设计中，请对号入座：

👉 场景 A：机器与机器通信 (M2M) / 纯后端调用
你的需求：你的后端服务需要定时去调用另一个微服务的接口。
你的选择：纯 OAuth 2.0。这里根本没有“人类用户”，不需要验证身份，只要用客户端凭证换个 Access Token 即可。
👉 场景 B：单纯的第三方登录 (SSO)
你的需求：你开发了一个独立论坛，只想让用户“微信扫码一键登录”自动注册账号。
你的选择：OIDC。你只需要拿到 ID Token 解析出用户的基本信息即可，拿完就走，不需要后续权限。
👉 场景 C：既要认人，又要干活（最常见）
你的需求：你的工具需要用户使用 Google 登录，并且还要帮用户自动往 Google 日历里写日程。
你的选择：OIDC + OAuth 2.0 混合双打。认证时拿到 ID Token 建立本地会话，同时拿到 Access Token 去请求 Google Calendar API。