前置核心概念：先分清「认证」与「授权」
这是理解两个协议的核心前提，90%的混淆都源于对这两个概念的误解：
- 认证（Authentication）：验证「你是谁」，核心是身份核验。比如刷身份证进站，证明你是车票对应的本人。
- 授权（Authorization）：验证「你有权限做什么」，核心是权限管控。比如进站后，你只能进入对应车次的车厢，无权进入未购票的商务座。
一、OAuth 2.0 是什么
OAuth 全称 Open Authorization（开放授权），是2012年发布的行业标准授权协议（RFC6749），也是目前互联网资源授权的事实标准。
核心定位与解决的问题
它的诞生，是为了解决一个经典的安全痛点： 早期第三方应用想要访问用户在其他平台的资源（比如APP想获取你的微信头像、工具想访问你的GitHub仓库），只能让用户把账号密码交给第三方，这会带来严重的密码泄露、权限滥用风险。
OAuth 2.0 用「令牌（Token）」替代「密码」，实现了有限、安全、可控的资源授权：用户无需向第三方泄露密码，只需通过授权服务器，给第三方颁发一个有时间限制、权限范围受限的访问令牌，第三方只能凭令牌访问约定好的资源，无法触碰用户的账号核心信息。
核心要素
- 四大核心角色
- 资源所有者：即用户，拥有资源的控制权
- 客户端：第三方应用/服务，想要访问用户的资源
- 授权服务器：负责验证用户身份、颁发令牌的服务（比如微信开放平台的授权服务）
- 资源服务器：存储用户受保护资源的服务（比如微信的用户信息接口）
- 核心产出：Access Token（访问令牌），唯一用途是向资源服务器证明「当前请求拥有约定的资源访问权限」，用于调用受保护的API接口。
- 标准授权流程：支持授权码流程（最安全，主流）、PKCE流程（适配无后端的单页应用/APP）、客户端凭证流程（适配服务间调用）、刷新令牌流程等。
核心局限性
OAuth 2.0 是一个纯授权协议，只解决「你能做什么」，完全不解决「你是谁」：
- 它没有定义用户身份信息的标准格式，Access Token本身不携带用户身份信息，客户端无法仅凭令牌确认当前用户的身份；
- 没有统一的用户唯一标识规范，不同厂商的实现千差万别，无法实现跨平台的标准化身份认证、单点登录（SSO）。
二、OIDC 是什么
OIDC 全称 OpenID Connect，是2014年由OpenID基金会发布的开放身份认证协议，它完全构建在 OAuth 2.0 协议之上，是 OAuth 2.0 的超集，而非替代方案。
核心定位与解决的问题
OAuth 2.0 只解决了授权，没有标准化的身份认证能力，行业需要一套统一的规范，来实现跨平台、可互操作的用户身份核验，OIDC 应运而生。
它的核心定位是：在 OAuth 2.0 的授权流程基础上，增加了标准化的身份认证层，彻底解决「你是谁」的问题，同时完全兼容 OAuth 2.0 的所有授权能力。
核心新增能力（区别于纯OAuth 2.0的核心）
- 强制的身份凭证：ID Token OIDC 流程中，授权服务器除了返回 Access Token，必须返回 ID Token（身份令牌）：
- 它是标准化的 JWT 格式，自带数字签名，防篡改、可自校验；
- 内置标准化的身份声明：包括用户唯一标识
sub、签发者iss、受众aud、过期时间exp等核心字段，也可扩展name、email、avatar等用户信息； - 用途是给客户端（前端/APP）做身份核验，客户端拿到 ID Token 即可直接确认用户身份，无需额外调用接口。
- 标准化的 UserInfo 端点 OIDC 规范了统一的用户信息接口，客户端可凭合法的 Access Token 调用该接口，获取完整的、格式统一的用户信息，彻底解决了不同厂商接口格式不兼容的问题。
- 标准化的流程与扩展能力 规范了身份认证的完整流程，强制要求授权请求必须携带
openidscope（这是触发OIDC流程的核心标识），同时定义了单点登录（SSO）、会话管理、登出、前端令牌校验等标准化能力，可实现跨应用的统一身份管理。
三、OAuth 2.0 与 OIDC 的核心区别
| 对比维度 | OAuth 2.0 | OIDC (OpenID Connect) |
|---|---|---|
| 核心定位 | 开放授权协议 | 基于OAuth 2.0构建的开放身份认证协议 |
| 核心解决问题 | 第三方应用如何安全获取用户资源的访问权限，解决「你能做什么」 | 标准化的用户身份核验，解决「你是谁」，同时兼容完整的OAuth 2.0授权能力 |
| 核心凭证产出 | 仅产出Access Token（访问令牌），用于调用受保护的资源接口 | 除Access Token外，必须产出ID Token（身份令牌），标准化JWT格式，直接携带可校验的用户身份信息 |
| 核心标识 | 无强制scope要求，按授权需求配置 | 授权请求必须携带openid scope，作为OIDC流程的法定标识 |
| 标准化能力 | 仅定义授权流程与令牌机制，无身份信息、用户唯一标识的统一标准 | 定义了标准化的用户身份字段、UserInfo端点、SSO单点登录、会话管理、登出等全流程规范 |
| 协议层级 | 底层基础协议 | 基于OAuth 2.0的上层应用层协议，是OAuth 2.0的超集，100%兼容OAuth 2.0 |
| 典型使用场景 | API接口防护、第三方应用资源访问（如工具获取GitHub仓库权限、应用获取云存储资源） | 用户登录认证、跨应用SSO单点登录、第三方账号登录（微信/Google登录网站）、统一身份管理 |
四、常见误区澄清
- 误区：OAuth 2.0 是登录协议 纠正：纯OAuth 2.0 无法实现身份认证，我们日常使用的「微信登录、Google登录」，本质是OIDC（或厂商基于OAuth 2.0扩展的类OIDC身份能力），而非纯OAuth 2.0。
- 误区：OIDC 和 OAuth 2.0 是竞争关系 纠正：OIDC 是OAuth 2.0 的扩展与超集，没有OAuth 2.0 就没有OIDC，所有OIDC流程都是合法的OAuth 2.0流程，但反向不成立。
- 误区：ID Token 和 Access Token 可以混用 纠正：两者用途完全隔离。ID Token 仅给客户端做身份核验，不能用于调用API；Access Token 仅给资源服务器做接口授权校验，不能用于用户身份认证。
补充关联
如 Logto，本质就是一个标准的OIDC 身份提供商（IdP），它完整实现了OAuth 2.0的授权能力与OIDC的身份认证能力，让开发者无需从零实现复杂的协议细节，即可快速搭建符合行业标准的认证授权体系。