这是一篇写给开发者、架构师、以及正在做登录 / 单点登录 / 第三方授权 / 开放平台接入的同学的文章。

如果你总觉得 OAuth 2.0、OIDC、JWT、SSO 这些概念看起来都眼熟，但一到真正讲原理、画架构、做落地时就容易混，这篇文章就是给你准备的。

很多人第一次接触 OAuth 2.0 和 OIDC，都会有一种很强烈的感觉：

好像知道它们和登录有关；
好像很多“第三方登录”都在用；
但一问“它们到底解决了什么问题”，又容易说不清；
再进一步问“为什么 OAuth 2.0 不等于登录协议、OIDC 又为什么是 OAuth 2.0 的增强层”，就更容易混乱。

所以这篇文章我不打算一上来堆规范名词，而是按照一个更容易理解的顺序来讲：

OAuth 2.0 到底是什么
OIDC 又是什么
它们各自的架构图和流程图
它们最大的区别到底在哪
各自的优缺点
实际项目里应该怎么选、怎么落地

如果你只想先记住一句话，那就是：

OAuth 2.0 解决“授权”问题，OIDC 解决“认证”问题。

再展开一点：

OAuth 2.0 关心的是：一个应用能不能在用户授权后访问另一个系统的资源；
OIDC 关心的是：在这个过程中，如何标准化地确认“这个用户是谁”。

也就是说：

OIDC = OAuth 2.0 + 身份层

一、先别急着讲协议，先把三个概念分清

很多人学 OAuth 2.0 和 OIDC 时之所以越学越乱，不是因为协议本身太难，而是因为一开始就把几个关键概念混在了一起：

认证 Authentication
授权 Authorization
登录态 Session / Token

如果这三个概念不分开，后面你会发现每个词都“似懂非懂”。

1. 什么是认证 Authentication

认证解决的是一个最基础的问题：

你是谁？

比如：

你是否已经登录；
你是不是这个账号的拥有者；
这个 Google 账号 / 企业账号对应的是不是你本人。

认证的重点，不是你能做什么，而是先确认“你是谁”。

2. 什么是授权 Authorization

授权解决的问题是：

你能做什么？

比如：

你能不能访问这个接口；
你能不能读取订单；
一个第三方应用能不能代替你读取联系人信息。

认证和授权经常连在一起出现，但它们不是一回事。

3. 什么是登录态

登录态解决的问题是：

系统之后怎么持续认出你？

常见方式有：

Cookie + Session
Access Token
JWT

注意，登录态是“持续识别”的机制，它也不是 OAuth 2.0 本身。

二、OAuth 2.0 到底是什么

2.1 用一句人话解释

如果不讲标准定义，直接用工程师最容易理解的话来解释：

OAuth 2.0 是一套“授权框架”，它的目的，是让第三方应用在不拿走用户密码的前提下，获得对某些资源的受限访问能力。

这里面有两个词特别关键：

第三方应用
受限访问

也就是说，OAuth 2.0 的重点从来不是“帮你做一个登录页面”，而是：

让一个系统在被授权后，安全地访问另一个系统的资源。

2.2 它为什么会出现

在 OAuth 2.0 出现之前，很多第三方集成其实非常粗暴：

用户想让 B 应用访问 A 平台的数据；
最简单的办法，就是把自己在 A 平台的账号密码直接给 B；
B 再拿着这个账号密码去访问 A。

这种做法问题非常大：

用户把密码直接交给第三方，风险极高；
第三方拿到的是“完整账号能力”，权限太大；
没法精细控制“只允许读头像，不允许读联系人”；
想撤销某个第三方应用的权限也很麻烦；
用户通常也不知道自己到底授权了什么。

OAuth 2.0 的出现，本质上就是为了替代这种危险模式。

它的核心思想可以概括成一句话：

用户不给第三方密码，而是由授权服务器发一个受限令牌给第三方。

这个令牌就是我们后面常说的 access token。

2.3 OAuth 2.0 解决的到底是什么问题

理解 OAuth 2.0，最重要的是别把它想成“登录协议”，而要把它想成：

一种受控的资源访问委托机制。

比如这些场景：

一个日历应用想读取你的 Google Calendar；
一个企业集成系统想访问你的公司开放 API；
一个网站想让你“使用某平台账号授权接入”；
一个第三方应用想读取你的 GitHub 仓库信息。

这些场景的共同点都是：

资源属于用户；
请求方不是资源本身，而是另一个应用；
用户需要“同意”；
且这个同意最好是可限制、可撤销、可审计的。

这就是 OAuth 2.0 的舞台。

三、OAuth 2.0 的角色模型

OAuth 2.0 不难，难的是第一次看术语时会觉得太抽象。实际上只要把角色对上现实世界，就很清楚了。

1. Resource Owner：资源所有者

通常就是用户本人。

比如：

你的头像
你的邮箱
你的订单数据
你的日历
你的联系人信息

2. Client：客户端应用

就是那个“想获得授权”的应用。

比如：

一个网站
一个移动 APP
一个第三方 SaaS
一个内部集成系统

3. Authorization Server：授权服务器

它负责做两件大事：

让用户登录；
让用户决定是否授权；
然后签发 token。

这通常就是：

Google Identity
企业统一身份中心
微信开放平台授权中心
你自己搭建的认证平台

4. Resource Server：资源服务器

它负责真正保存资源，并在收到 token 后决定要不要把资源返回出去。

例如：

用户信息接口
订单接口
文件接口
日历接口

你会发现，OAuth 2.0 的精髓就是把“身份确认 / 授权同意 / 资源访问”拆开了。

四、OAuth 2.0 的架构图

先看一张整体架构图：

如果把这张图翻译成一句更容易懂的话，就是：

用户先去授权中心完成身份确认和授权，然后客户端拿着授权结果换到 token，最后再用 token 去请求真正的资源。

这里最关键的一点是：

客户端拿到的是 token，不是用户密码。

这正是 OAuth 2.0 的核心价值所在。

五、OAuth 2.0 是怎么工作的

5.1 最主流的流程：Authorization Code Flow

OAuth 2.0 有几种模式，但今天真正最值得理解、也最常用的一种，是：

Authorization Code Flow

它为什么重要？因为现在几乎所有现代 Web、APP、SSO 方案，最后都绕不开它，或者绕不开它的增强版本。

5.2 这套流程怎么理解

你可以把它理解成一个“先拿授权凭条，再换正式通行证”的过程。

第一步：客户端把用户带去授权服务器

客户端会构造一个授权请求，通常会带上这些参数：

client_id
redirect_uri
scope
state
response_type=code

这一步的意思是：

“我是哪个客户端、我要什么权限、用户同意后你回调到哪里。”

第二步：用户在授权服务器登录并确认授权

用户不是在客户端输入密码，而是在授权服务器完成登录。

然后授权服务器会告诉用户：

这个应用想读取你的头像；
想读取你的邮箱；
是否允许。

用户确认后，流程继续。

第三步：授权服务器返回一个 `code`

授权服务器会回调客户端的 redirect_uri，并附带：

code
state

这里的 code 可以理解成一个短期、一次性、临时可交换的授权凭条。

第四步：客户端用 `code` 去换 `access_token`

注意，这一步通常是客户端后端去做，而不是前端直接做。

客户端向授权服务器发起 token 请求，提交：

grant_type=authorization_code
code
client_id
client_secret（机密客户端）
redirect_uri

验证通过后，授权服务器会返回：

access_token
refresh_token（可选）
expires_in
token_type

第五步：客户端带着 `access_token` 去访问资源服务器

访问方式通常是：

http

Authorization: Bearer <access_token>

第六步：资源服务器校验 token，并决定是否返回资源

如果 token 合法、未过期、scope 足够，就返回对应资源。

整个过程看上去步骤不少，但思想非常统一：

先授权，再换 token，再凭 token 访问资源。

5.3 时序图

六、为什么现在大家都在讲 PKCE

如果你这两年看 OAuth 2.0 相关资料，经常会看到一句话：

Authorization Code + PKCE 是现代推荐方案。

那 PKCE 到底是干什么的？

答案很简单：

它是为了防止授权码 code 被截获后被冒用。

传统 Authorization Code Flow 里，如果有人中途偷到了 code，就可能尝试拿它去换 token。

PKCE 的做法是：

客户端先生成一个随机的 code_verifier；
再根据它计算出 code_challenge；
发起授权请求时先把 code_challenge 交给授权服务器；
后面换 token 时再把 code_verifier 交过去；
授权服务器比对两者关系，只有匹配才能发 token。

所以即使 code 被偷了，没有 code_verifier 也没法换到 token。

这对于：

SPA
移动端 APP
公有客户端

尤其重要。

七、OIDC 又是什么

如果说 OAuth 2.0 是“授权世界”的核心框架，那么 OIDC 就是“登录世界”在 OAuth 2.0 之上的标准化补全。

7.1 先说结论

OIDC，全称 OpenID Connect，它是：

建立在 OAuth 2.0 基础上的身份认证协议。

换句话说，OIDC 并不是推翻 OAuth 2.0，而是在它上面再补了一层：

OAuth 2.0 负责授权；
OIDC 负责告诉你用户是谁。

7.2 为什么 OAuth 2.0 还不够

这是理解 OIDC 的关键。

OAuth 2.0 只定义了这样一件事：

客户端怎么拿到 token；
token 怎么用来访问资源。

但它没有严格标准化这些问题：

用户唯一标识字段到底叫什么？
用户资料怎么拿？
登录结果应该长什么样？
客户端如何标准化地确认“这个用户就是某某人”？

所以如果你直接拿 OAuth 2.0 做登录，现实里常常会出现这些情况：

每个平台用户信息接口长得都不一样；
字段名不一样；
登录语义不一致；
安全校验容易缺项；
结果就是“能跑通，但不标准”。

OIDC 出现，就是为了解决这个问题。

它在 OAuth 2.0 之上补了一个非常关键的能力：

标准化身份断言。

八、OIDC 增加了哪些核心能力

OIDC 最重要的不是“发了更多 token”，而是它把“身份”这件事标准化了。

8.1 ID Token

OIDC 最大的标志之一，就是它会返回一个：

id_token

这个 token 通常是一个 JWT，它描述的是：

这个用户是谁，这个身份断言是谁签发的，它签发给谁，以及什么时候过期。

里面常见字段有：

sub：用户唯一标识
iss：签发者
aud：接收方
exp：过期时间
iat：签发时间
nonce：防重放
name
email

其中最重要的不是 name、email 这种展示信息，而是：

sub
iss
aud
exp
nonce

因为这些字段真正决定了这个身份断言是否可信。

8.2 UserInfo Endpoint

OIDC 还定义了一个标准的用户信息接口：

userinfo

客户端可以拿着 access_token 去请求这个接口，统一拿到用户资料。

这就避免了“每个平台用户资料接口都不一样”的混乱局面。

8.3 标准 Scope

OIDC 要求请求中带上：

openid

这代表“这不是普通 OAuth 授权，而是一个 OIDC 认证请求”。

此外还有一些常见 scope：

profile
email
phone
address

8.4 标准 Claims

OIDC 把很多常见用户属性标准化成 claims，这让不同身份平台之间的对接成本大幅下降。

九、OIDC 的架构图

和 OAuth 2.0 相比，OIDC 看起来变化不大，但实际上多出来的这两件事非常关键：

返回 id_token
提供标准化的 userinfo 接口

这两件事，正是 OIDC 能成为“现代登录 / SSO 标准”的原因。

十、OIDC 是怎么工作的

10.1 OIDC 最常用的流程

OIDC 现在最常见、最推荐的做法是：

Authorization Code Flow + PKCE

你可以把它看成是“OAuth 2.0 主流程不变，但额外多了身份结果和身份校验”。

10.2 具体流程怎么走

第一步：客户端发起认证请求

常见参数包括：

client_id
redirect_uri
response_type=code
scope=openid profile email
state
nonce
code_challenge
code_challenge_method=S256

这里面有两个参数尤其要记住：

openid：声明这是 OIDC 请求；
nonce：用于防止 id_token 被重放。

第二步：用户在身份提供方登录并授权

这一步和 OAuth 2.0 很像，只不过这里的语义更偏“登录 + 授权”。

第三步：返回授权码 `code`

用户完成后，客户端收到回调。

第四步：客户端用 `code` 换 token

这一步返回的，不再只有 access_token，通常还会多一个：

id_token

返回示例：

json

{
  "access_token": "xxx",
  "id_token": "yyy",
  "refresh_token": "zzz",
  "token_type": "Bearer",
  "expires_in": 3600
}

第五步：客户端校验 `id_token`

这一步是 OIDC 最关键、也最容易被忽略的地方。

至少要校验：

签名是否合法；
iss 是否正确；
aud 是否是当前客户端；
exp 是否过期；
nonce 是否匹配；
sub 是否存在。

第六步：获取用户资料

客户端可以：

直接从 id_token 获取部分基础信息；
或者再通过 userinfo 接口获取完整资料。

第七步：建立本地登录态

实际项目里，绝大多数系统不会直接把第三方登录结果当作完整业务登录态，而是会：

根据 sub 查本地绑定关系；
找到对应本地用户；
再建立自己的 session 或业务 token。

这一步非常关键，因为它决定了“身份平台”和“业务用户体系”能否真正解耦。

10.3 OIDC 时序图

十一、OAuth 2.0 和 OIDC 到底有什么区别

这是全文最核心的问题。

很多人不是没看过定义，而是看过之后依然分不清。原因在于：

它们流程长得很像；
经常一起出现；
很多平台对外文档里也会把两者混着说。

所以这里我给你一个最直接的理解方式。

11.1 本质区别

OAuth 2.0

它解决的是：

客户端有没有被授权访问资源。

也就是说，它的核心关注点是：

token 怎么发；
token 怎么用；
scope 是什么；
权限是否足够。

OIDC

它解决的是：

这个用户到底是谁，客户端如何可信地知道这个身份。

也就是说，它关注的是：

登录结果怎么表达；
身份断言长什么样；
用户信息怎么标准化返回；
客户端如何校验这个身份结果。

11.2 一张对比表

对比项	OAuth 2.0	OIDC
本质	授权框架	认证协议
关注点	资源访问授权	用户身份认证
是否标准化用户身份	否	是
核心令牌	access_token	access_token + id_token
是否有标准用户信息接口	没有统一要求	有 UserInfo Endpoint
是否适合直接做标准登录	不建议单独使用	适合
典型场景	开放 API、第三方授权	SSO、社交登录、统一身份认证

11.3 你可以这样记

如果非要压缩成一句特别好记的话，可以直接记成：

OAuth 2.0 发“访问凭证”，OIDC 发“访问凭证 + 身份证明”。

十二、两者各自的优缺点

12.1 OAuth 2.0 的优点

第一，生态成熟

它已经是开放平台、第三方授权领域的事实标准。

第二，适用范围广

它适合：

Web
APP
SPA
后端服务调用
IoT 设备

第三，权限模型灵活

可以通过：

scope
audience
resource

做更细粒度的访问控制。

第四，特别适合做开放平台

如果你的目标是“让第三方应用安全访问我的 API”，OAuth 2.0 很合适。

12.2 OAuth 2.0 的缺点

第一，它不是登录协议

这是最大的问题。

很多人拿 OAuth 2.0 硬做登录，最后就会出现：

能跑通；
但对身份的定义不标准；
用户信息接口五花八门；
安全校验容易漏。

第二，理解和实现门槛不低

它涉及：

client
redirect
code
token
scope
state
refresh

如果对这些概念不清楚，很容易只会“照抄 SDK”。

第三，容易误用

比如：

不校验 state
不用 PKCE
token 保存在不安全位置
继续使用已不推荐的 implicit flow

12.3 OIDC 的优点

第一，它把“身份”标准化了

这几乎是它最大的价值。

第二，它非常适合登录和 SSO

像这些场景都很适合：

企业统一登录
多系统单点登录
社交账号登录
统一身份中心

第三，它降低了多平台对接差异

因为：

id_token 有标准；
userinfo 有标准；
claims 有标准。

对接时不需要每个平台重新猜字段含义。

12.4 OIDC 的缺点

第一，它比纯 OAuth 2.0 更复杂

你还要理解：

id_token
nonce
discovery
JWK
claims

第二，接入门槛更高

很多团队不是流程不会接，而是“知道要接，但不知道哪些校验绝对不能省”。

第三，依然可能被错误实现

比如：

不校验 id_token
不校验 nonce
把 access token 当身份断言使用
直接把第三方 token 当本地长期登录态

十三、实际项目里应该怎么选

讲到这里，很多人最关心的问题其实已经不是“定义”，而是：

那我项目里到底该选哪个？

13.1 如果你是在做开放 API / 第三方授权

比如：

让外部应用访问你的订单接口；
做企业开放平台；
做服务间委托授权。

优先考虑：

OAuth 2.0

因为你的重点是“资源访问控制”。

13.2 如果你是在做登录、统一登录、第三方登录

比如：

网站登录
APP 登录
企业统一身份认证
Google / Apple / 企业账号登录

优先考虑：

OIDC

因为你的重点是“用户身份确认”。

13.3 如果你是在做新系统

最推荐的默认答案通常是：

OIDC + Authorization Code Flow + PKCE

这是现在最主流、最现代、也最稳妥的一套组合。

它适合：

Web
SPA
移动端
SSO
第三方登录

十四、实践里怎么落地才靠谱

这一部分尽量不讲空话，只讲工程上真正有用的建议。

14.1 Token 应该怎么设计

Access Token

建议：

短时效；
只用于访问资源接口；
过期时间通常控制在几分钟到几十分钟。

Refresh Token

建议：

长时效；
用来刷新 access token；
尽量支持 rotation；
严格保护存储位置。

ID Token

建议：

只用于身份声明；
不要直接拿去访问业务 API；
也不要把它当成万能 session 替代品。

14.2 安全上最容易踩的坑

如果你只想记住最重要的安全清单，可以记这几条。

1）一定校验 `state`

它是防回调篡改、防 CSRF 的关键参数之一。

2）APP 和 SPA 必须使用 PKCE

这是现代 OAuth / OIDC 接入的基本要求。

3）`redirect_uri` 必须严格白名单

不能模糊匹配，更不能允许任意跳转。

4）token 一定要短时效

否则一旦泄露，损失会被放大。

5）refresh token 要重点保护

推荐方式：

浏览器场景放在 HttpOnly Cookie；
移动端放系统安全区；
支持 rotation；
支持撤销。

6）OIDC 里必须认真校验 `id_token`

至少包括：

签名
iss
aud
exp
nonce

7）不要直接把第三方 access token 当本地长期登录态

更稳妥的做法是：

用第三方身份完成认证；
映射本地用户；
再发你自己的本地 session 或业务 token。

十五、业务系统怎么设计本地用户体系

这也是很多团队刚开始接第三方登录时最容易忽略的点。

很多人以为接完 OIDC 就结束了，但实际上真正的业务系统通常都会保留自己的用户体系。

为什么？因为：

你的权限模型在本地；
你的业务数据在本地；
你的组织关系、角色、菜单、数据权限都在本地；
第三方身份只负责“证明这个人是谁”。

所以一个常见且推荐的设计是：

1. 用户主表

保存本地业务用户，比如：

user_id
nickname
mobile
email
status
created_at

2. 外部身份映射表

保存第三方身份绑定关系，比如：

provider
external_sub
user_id
bind_time
last_login_time

这样设计有几个明显好处：

一个本地用户可以绑定多个外部身份；
支持解绑和重新绑定；
支持账号合并；
支持统一业务用户视角。

这也是为什么很多成熟系统都会把“身份认证平台”和“业务用户平台”分开。

十六、一个更实用的落地架构

这个架构的核心思想，其实非常适合现代系统：

身份统一交给 IdP 管理；
Web / SPA / APP 都通过 OIDC 完成登录；
网关负责统一校验 token 或透传身份；
用户服务负责本地账号映射；
业务服务只关心：用户 ID、角色、权限。

这样做最大的好处是：

协议细节和业务逻辑解耦。

后面你换 IdP、接更多登录源、支持更多终端，都不会把业务代码拖进认证协议细节里。

十七、如果是新项目，我的建议是什么

如果你现在是从零开始做一个新系统，我会给出一个非常明确的建议：

建议一：登录 / SSO 优先用 OIDC

尤其是：

统一登录
多系统接入
第三方身份登录
Web + APP 混合场景

默认优先考虑：

OIDC + Authorization Code + PKCE

建议二：开放平台 / API 授权优先用 OAuth 2.0

如果你的核心是：

第三方调用 API
外部应用集成
机器对机器授权

那就优先把：

client 管理
scope 设计
token 生命周期
审计和撤销

做好。

建议三：如果不想自己造轮子，就接成熟 IdP

这往往是最理性的工程选择。

你可以考虑：

Keycloak
Auth0
Okta
Azure AD
企业自建统一身份平台

你自己重点做：

客户端接入；
本地用户映射；
权限体系；
审计与业务联动。

十八、几个特别常见的误区

误区 1：OAuth 2.0 就是登录协议

不是。

更准确地说：

OAuth 2.0 是授权框架；
OIDC 才是标准化认证协议。

误区 2：拿到 access token 就等于知道用户是谁

也不对。

access token 的重点是：

访问资源

而不是：

标准化地表达身份

身份更应该看：

id_token
userinfo

误区 3：JWT 就等于 OAuth 2.0

完全不是一回事。

JWT 是一种 token 格式；
OAuth 2.0 是授权框架。

OAuth 2.0 可以用 JWT，也可以不用 JWT。

误区 4：接完第三方登录，就直接把第三方 token 当本地永久登录态

这个做法风险很大。

更好的方式通常是：

第三方完成认证；
映射本地用户；
建立自己的登录态。

误区 5：流程跑通了，就说明接入没问题

不是。

很多接入“能用”，但并不“安全”。

比如这些校验一旦缺失，就可能埋下隐患：

state
nonce
redirect_uri
id_token 签名
token 过期时间

十九、如果你要做一次技术分享，可以怎么总结

如果你需要在面试、评审、技术分享里快速说明白这两个协议，可以直接用下面这段话：

OAuth 2.0 是授权框架，解决第三方应用如何在用户授权下访问资源；OIDC 是建立在 OAuth 2.0 之上的认证协议，它增加了 id_token、userinfo 和标准身份声明，用来标准化登录和单点登录。

在实践中，做开放 API 和第三方资源访问时更偏向 OAuth 2.0；做网站登录、APP 登录、企业统一登录和 SSO 时更推荐 OIDC。现代系统通常采用 Authorization Code + PKCE，并配合短期 access token、可轮换 refresh token，以及严格的 state、nonce、redirect_uri 校验来保证安全。

这段话足够用来：

回答面试；
做评审汇报；
解释技术选型。

二十、最后做个总结

如果把整篇文章再压缩成最关键的几点，你可以记住这些：

1. OAuth 2.0 是什么

它是授权框架；
它解决的是“能不能访问资源”。

2. OIDC 是什么

它是认证协议；
它建立在 OAuth 2.0 之上；
它解决的是“用户是谁”。

3. 两者的区别

OAuth 2.0 偏授权；
OIDC 偏身份认证；
OIDC 比 OAuth 2.0 多了 id_token、userinfo、标准 claims。

4. 现在主流怎么做

推荐使用 Authorization Code + PKCE；
做登录和 SSO，优先 OIDC；
做 API 授权，优先 OAuth 2.0。

5. 落地时真正重要的是什么

不是“把流程跑通”，而是把这些细节做好：

state
nonce
redirect_uri 白名单
access token 短时效
refresh token 轮换
id_token 严格校验
本地用户体系映射

最后送你一句最适合记忆的话：

OAuth 2.0 管授权，OIDC 管身份；做 API 授权优先 OAuth 2.0，做登录和 SSO 优先 OIDC。

附：速记对比表

主题	OAuth 2.0	OIDC
本质	授权框架	认证协议
解决的问题	能否访问资源	用户是谁
关键令牌	access_token	access_token + id_token
用户信息标准	无统一标准	有统一标准
适用场景	API 授权、开放平台	登录、SSO、社交登录
是否推荐直接用于登录	不建议单独使用	推荐

如果后续你还想继续扩展这篇文章，最适合补的两个方向通常是：

Spring Security / Java 落地实战版
OAuth 2.0、OIDC、JWT 三者关系姊妹篇