2025-12-22 03:53:24 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： 本文详细解析了OAuth2.0授权协议的本质、四种授权类型及其应用场景，通过微信登录知乎的实例展示了授权码许可流程的完整步骤。文章阐述了OAuth2.0与OIDC的区别与联系，指出OAuth2.0是授权协议而OIDC是建立在OAuth2.0之上的身份认证协议，通过IDToken解决了身份认证问题。同时解释了访问令牌和刷新令牌的作用，以及JWT与OAuth2.0的关系，澄清了OAuth2.0与单点登录SSO的区别。 综合评分： 85 文章分类： 应用安全,WEB安全,技术标准,安全建设,解决方案

cover_image

极力推荐：万字大白话一次讲透OAuth 2.0如何“安全授权”，OIDC又如何“精准识人”！

原创

筑梦网安

全栈安全

2025年11月16日 23:11 浙江

OAuth 2.0已经成为当今互联网授权体系（如微信登录、微博登录、GitHub登录等）的基石，网上有很多介绍OAuth 2.0的文章，但都无法完整且通俗地回答清楚以下几个问题，导致你看过后仍然云里雾里：

OAuth 2.0 到底是身份认证协议还是授权协议？
OAuth 2.0的四种授权类型应该如何选择？
授权码许可流程中授权码的作用只是用来换取访问令牌么？
有了访问令牌，为什么还需要刷新令牌，是多此一举么？
有了刷新令牌，是不是就可以让访问令牌一直有效了？
OAuth 2.0 与单点登录SSO两者是啥关系？
OAuth 2.0为什么经常与JWT一起搭配使用？
OAuth 2.0与ODIC协议之间是啥关系？

如果以上问题你都能直接答出，恭喜你！以下内容你可以不用看了。

如果不能，接下来预计花你5~8分钟时间，我们来一层层拨开迷雾！

1. 引言

OAuth是Open Auth的缩写，即开放授权的意思，所以OAuth 2.0本质上是一个授权协议。第三方只有获得用户的授权后，才能访问用户的数据。

OAuth 2.0经常被“认为”是一种身份认证协议，主要原因是OAuth 2.0中确实包含了身份认证的内容，即授权服务需要先让用户完成登录，然后才可以进行用户确认授权的操作。

OAuth 2.0是为了解决Web浏览器场景下的授权问题，其核心就是颁发访问令牌、使用访问令牌。既然有2.0，那一定有1.0，只不过OAuth 1.0 已经处于废弃状态，我们无须关注，所以本文主要介绍的是OAuth 2.0。

OAuth 2.0官方支持了四种授权类型：

授权码许可（Authorization Code）：最经典、最安全、应用最广泛。
隐式许可（Implicit）：最不安全，不推荐使用。
资源拥有者凭据许可（Resource Owner Password Credentials）：需要输入用户名和密码。
客户端凭据许可（Client Credentials）：没有用户参与。

以上四种授权类型在接下的描述中会有详细解读，这里大家只需要知道授权码许可类型是最经典、最安全且应用最广泛的，后面三种都是基于授权码许可类型作了裁剪，所以安全性较弱，最不安全的是隐式许可。

2. 授权码许可：一步步带你走一遍授权码流程

为了讲清楚授权码许可，我们先要了解OAuth 2.0 官方定义的四种角色：

资源所有者
客户端（经常也被称为第三方软件，我认为用第三方软件这个术语更贴切，下文默认用第三方软件来代表客户端）
授权服务器
受保护资源

我们用一个你肯定用过或者至少听过的真实例子——使用微信登录「知乎」，来生动拆解 OAuth 2.0 的授权码流程。

在这个场景里：

你：资源所有者（你的微信账号和信息的所有者）
微信：同时扮演授权服务器（负责问你同不同意）和资源服务器（存着你的头像、昵称等资源）
知乎：第三方软件（想借用你的微信身份来让你快捷登录）
你的微信头像和昵称：受保护的资源

授权的前提需要第三方软件（知乎）去平台（微信）备案（注册），注册通过才能证明其为合法应用。

注册后平台会给第三方软件appid、app_secret等信息，方便后续授权时校验身份信息。同时，注册时第三方软件也会请求受保护资源的访问范围（scope）

第一步：知乎引导你去微信官方认证

你在知乎登录页点击 “微信登录” 按钮。

知乎很聪明，它不会傻乎乎地弹个框让你输入微信账号密码。它会直接跳转到微信官方的一个页面（这个页面地址是 https://open.weixin.qq.com/...）。

微信官方页面

这个页面的地址栏是微信的，安全锁图标也是微信的，这就在告诉你：“现在是你和微信官方在对话，知乎已经被支开了。”

备注：授权码流程中发生了第一次重定向：从第三方软件（知乎）跳转到（微信）授权界面完成授权。

第二步：你亲自用微信授权

你看到了微信官方的授权页面，上面清晰地写着：“知乎申请使用你昵称、头像”，你可以“允许” / “拒绝”。

微信授权界面

请注意这个页面的关键点：

它是在你已经登录的、可信的微信App内部弹出的。
它跳过了输入账号密码的步骤，因为你的登录状态（通常以 refresh_token 或长期会话的形式存在）已经证明了“你就是你”。

你点击 “同意” 。这个确认动作，就完全等同于传统流程中“在授权页面输入密码并点击同意”的步骤。所以，它依然是标准的授权码流程。只是将用户认证环节前置或委托给可信客户端（如App内的WebView），并非真正跳过认证。

你是在微信的官方页面上点击的“同意”，知乎从头到尾都没看到我们的微信账号密码！

第三步：微信发放“一次性取件码”

你点击“同意”后，微信服务器会生成一个短命的、一次性的「授权码」，然后通过浏览器重定向，把这个码作为参数传回知乎事先设定好的一个回调地址（比如 https://www.zhihu.com/oauth/callback/wechat?code=ABC123...）。

解读：这个 code=ABC123... 就是那个“取件码”。它本身没啥价值，知乎不能直接用这个码来获取你的微信信息。它只是一个凭证，证明你刚才已经“点头同意”了。

OAuth 2.0规范建议授权码code的有效期为10分钟，并且一个授权码code只能被使用一次。code的临时性和一次性保障了微信授权登录的安全性。

在授权服务中，需要将生成的授权码code值与app_id、user进行关系映射。即，一个授权码code，表示某一个用户给某一个第三方软件进行了授权。
同时，授权服务还需要将授权码code跟已经授权的权限范围rscope进行绑定并存储，以便后续颁发访问令牌时能够通过code值取出授权范围并与访问令牌绑定。

颁发授权码code是通过前端通信完成的，浏览器也参与了授权码的颁发流程。所以第三方软件（知乎）是通过浏览器间接与授权服务器（微信）通信的。

备注：授权码流程中发生了第二次重定向：从授权界面跳转回第三方软件（知乎）界面。第二次重定向带了授权码(code，临时的、间接的凭证)。

在这里，我们来回答下文章刚开始提的第3个问题：授权码许可流程中授权码的作用只是用来换取访问令牌么？

如果没有授权码，授权服务只能将访问令牌发送给第三方软件的后端服务（通过地址返回前端不安全，访问令牌机密性极高，不允许地址传递），这样用户与第三方软件的前端就断开连接了（因为在授权时已经重定向到授权界面了），所以需要携带授权码跳回前端界面。
有了授权码后，访问令牌可以在后端服务间传输，同时还可以重新建立用户与第三方软件前端界面的连接，既照顾了用户体验，又保证了通信的安全性。

思考：在授权服务携带授权码重定向第三方软件前端时，攻击者篡改了返回的地址怎么办？

第四步：知乎后台秘密兑换“正式通行证”

知乎的后台服务器在拿到这个「授权码」后，会秘密地（在你的浏览器背后）做一件事：它同时拿着这个「授权码」（code和它自己的「应用身份证」（secret，是它当初在微信开放平台注册时获得的），一起发送给微信的服务器。

通过code获取access_token的后端请求：

https://api.weixin.qq.com/sns/oauth2/access_token?appid=APPID&secret=SECRET&code=CODE&grant_type=authorization_code

参数详细介绍:

| 参数 | 是否必须 | 描述 | | — | — | — | | appid | 是 | 应用唯一标识，在微信开放平台提交应用审核通过后获得 | | secret | 是 | 应用密钥AppSecret，在微信开放平台提交应用审核通过后获得 | | code | 是 | 填写上一步获取的code参数（“一次性取件码”） | | grant_type | 是 | 固定为authorization_code |

核心安全机制：

这一步是服务器对服务器的通信，非常安全。你的浏览器不参与，这就防止了恶意软件或网络监听者截获最关键的信息。那个 app_secret 就像是知乎和微信之间的暗号，证明来兑换码的是“正版知乎”，而不是冒充的。

第五步：微信发放“长期通行证”

微信服务器验证了授权码和知乎的身份后，确认一切无误，就会返回一个 「访问令牌」 和 「刷新令牌」 给知乎的后台服务器。

{
"access_token":"ACCESS_TOKEN", &nbsp;# 接口调用凭证
"expires_in":7200, # access_token接口调用凭证超时时间，单位（秒）
"refresh_token":"REFRESH_TOKEN", # 用户刷新access_token
"openid":"OPENID", # 授权用户唯一标识
"scope":"SCOPE"&nbsp;# 用户授权的作用域，使用逗号分隔
}

解读：这个「访问令牌」就是那张真正的、有时效的“通行证”。知乎可以拿着这个令牌，在一定时间内（比2小时）代表你向微信索要信息，而无需你再授权。

访问令牌（access_token）是调用授权关系接口的调用凭证，access_token有效期较短，通常为几分钟~几小时：

当access_token超时后，可以使用refresh_token进行刷新；
若access_token未超时，那么使用refresh_token进行刷新时并不会改变access_token，但其超时时间会刷新，就相当于把access_token的有效期延长了。

refresh_token拥有较长的有效期（30天），当refresh_token失效的后，需要用户重新授权。

在这里，我们很容易回答出文章开头抛出的问题：有了访问令牌，为什么还需要刷新令牌，是多此一举么？

访问令牌失效后，为了避免让用户频繁手动授权，第三方软件可携带刷新令牌请求授权服务器再生成一个新的访问令牌。为了避访问令牌失效后，又没可用的（有效期内）刷新令牌，所以刷新令牌必须得和访问令牌一起生成。

接着，我们再尝试回答一个问题：有了刷新令牌，是不是就可以让访问令牌一直有效了？

要解决这个疑问，我们要知道的是，刷新令牌也有有效期。尽管生成了新的刷新令牌，但它的有效期不会改变，有效期的时间戳仍然是上一个刷新令牌的。刷新令牌的有效期到了，就不能再继续用它来申请新的访问令牌了。

OAuth 2.0规范没有约束访问令牌和刷新令牌的生成规则，我们既可以生成一个UUID，也可以将一些必要的信息通过结构化的处理放入令牌中，这种结构化令牌（简称JWT），在下文我们会详细讲述JWT。

第六步：知乎凭“通行证”获取你的信息

知乎的后台服务器拿到「访问令牌」后，就可以理直气壮地向微信的资源服务器发起请求：“嘿，这是我的令牌，请把对应用户的头像和昵称给我。”

微信验证令牌有效，就把你的公开信息发给了知乎。最后，知乎用这些信息为你创建或登录了账号，你成功进入了！

通过上面”微信登录知乎“例子，我们再来总结一下：

来源：微信官方文档

授权码优点：

安全性：你的微信密码从未泄露给知乎。你信任的是微信官方。
用户体验：你无需记住一个新的知乎账号密码，一键快捷登录。
权限可控：你授权给知乎的只是“公开信息”，它无法获取你的微信好友列表、聊天记录等敏感数据。微信的授权页面清晰地列出了权限范围。
符合流程：完美演绎了 “前端拿到码 -> 后端用码换令牌 -> 后端用令牌拿资源” 这一核心安全设计。

授权码流程：

整个 OAuth 2.0 授权码流程，就像是知乎作为一个“访客”，想进你家（你的微信数据）拿点东西。但它不直接问你要钥匙（密码），而是让你（房主）亲自去门口的保安亭（微信授权服务器）开一张一次性的访客条（授权码），然后知乎拿着这个条去保安亭换一张有期限的门禁卡（访问令牌），最后才能刷卡进门。

3. OAuth 2.0的其他三种许可类型

我们刚刚详细拆解了“微信登录知乎”这个经典流程。它安全、优雅，是 OAuth 2.0 的 授权码模式 的完美体现。这套流程就像一套精密的“外交礼仪”，适用于知乎（客户端）和微信（授权服务器）是两个完全独立的实体，且无法完全信任对方的情况。

但是，请大家思考一个问题：是不是所有场景都需要这么复杂的安全流程呢？

想象一下，如果每次你想用自己家的钥匙打开自己家的保险箱，也需要先扫个码、拿个临时码、再去换正式钥匙，是不是太繁琐了？OAuth 2.0 的设计者早就考虑到了不同场景下的安全与便利权衡，于是为我们提供了另外三种“通行证”获取方式。

3.1. 隐式许可：适用于完全公开的客户端

“微信登录知乎”时，知乎有个后台服务器能安全地保存 client_secret。但如果客户端没有后台服务器，比如是一个纯前端的 JavaScript 单页应用（例如：一个运行在浏览器里的网页版计算器，想获取你的公开微信头像来个性化界面），它无法安全地保管秘密。这时候，还用授权码模式，秘密就暴露了。

这时就可以使用隐式许可。这就像微信管家一看是那个“网页版计算器”来了，知道它兜里藏不住秘密，于是直接在重定向的 URL 后面附上了“访问令牌” (https://calculator.com/callback#token=XYZ789)。这个令牌通过片段传递，浏览器能读，但不会发送到服务器，稍微安全一点。但它毕竟暴露在前端，所以通常有效期很短，只用于获取公开信息。

核心区别：跳过“授权码”中转步骤，直接在前端颁发访问令牌。

3.2. . 资源拥有者凭证许可：在高度信任下的“捷径”

授权码模式要求用户跳转到微信的页面去授权。但如果第三方软件（客户端）是用户极度信任的“自己人” 呢？比如 “微信官方出品的另一个新App”（比如“微信读书”）。作为用户，你对这个App的信任度和对微信本身是一样的。再让你跳转一次，体验就很不流畅。

这种场景下就可以使用资源拥有者凭据许可。这就好比你在“微信读书”里，直接输入你的微信账号和密码，它拿着你的凭证直接去找微信服务器换令牌。这完全绕开了跳转和授权页。

核心区别：客户端直接收集用户的账号密码，用以交换访问令牌。

重要警告：这是最危险的方式，只适用于第一方应用（比如同一个公司旗下的产品）。你绝对不应该在知乎这类第三方App里输入你的微信密码！

如果授权码模式下也需要用户输入密码完成验证后再授权，那这与资源拥有者凭据许可有啥区别？

两者核心区别在于敏感信息的暴露面和控制权。

在资源拥有者凭据许可中，用户直接将用户名和密码提交给第三方软件，第三方完全掌控这些凭据，存在极大的安全风险——相当于把家门钥匙交给别人。

而在授权码模式中，用户始终在授权服务（如京东、微信）的可信域内输入账号密码，第三方软件只能获得一个临时的授权码，无法接触用户的原始凭据。即使用户需要登录，也只是在平台自己的页面上完成，第三方无法获取或记录密码。

此外，授权码模式支持更细粒度的权限控制（scope）、可撤销的令牌、以及刷新令牌机制，而资源拥有者凭据许可则缺乏这些安全特性。

因此，虽然用户都参与了认证，但授权码模式通过隔离凭据输入环境和引入中间凭证（code），实现了安全与可用性的平衡。

3.3. 客户端凭证许可：机器与机器之间的对话

上面的例子都是“一个应用代表一个用户”去访问资源。但如果一个应用不是为了代表用户，而是为了自己呢？比如，“知乎的数据备份服务”需要定期从微信服务器拉取一些公开的、不涉及具体用户的数据（如微信开放平台的公告列表）。这里没有“用户授权”的概念。

这就需要使用客户端凭证许可。这就像是“知乎备份服务”这个机器人，拿着自己的 “应用身份证” 和 “应用密码” ，直接去找微信服务器说：“是我，知乎机器人，我要拉取公告。” 微信服务器验证它的身份后，直接发给它一个适合它这个应用身份的访问令牌。

核心区别：没有用户参与，是客户端应用以自己的名义发起的认证，用于访问与其自身相关的、而非代表用户的资源。

这里需要注意的是，客户端凭证许可中并没有提供刷新令牌。这是因为，刷新令牌用于避免访问令牌失效后需要用户再次登录的问题，而客户端授权许可类型没有用户的概念，因此没有刷新令牌，也无法注入额外的userDetails信息。

3.4. 小结

我们可以用一张表来清晰地总结这四种类型：

通过这样一个从熟悉例子出发，不断提出新问题、解决新需求的叙述方式，我们就能非常自然且深刻地理解 OAuth 2.0 为何要设计这四种不同的“通行证”获取方式了。它们共同构成了一套适应万变互联网场景的、灵活而强大的授权框架。

4. OIDC：OAuth 2.0 解决了授权，但没解决身份认证

好的，让我们顺着刚才的思路我们了解了 OAuth 2.0 的四种授权方式。回想一下“微信登录知乎”的流程，它完美地解决了 “授权”问题：知乎在未经手你密码的情况下，获得了访问你微信基本信息的权限。

但这里存在一个关键的 “认知偏差”：

知乎真正想要的是什么？ 它真的是想要你的微信头像和昵称吗？不完全是。它最根本的目的是 “确认你就是你”，从而为你创建一个知乎账号并让你登录。
OAuth 2.0 提供了什么？ OAuth 2.0 流程结束时，知乎拿到的是一个 “访问令牌”。这个令牌好比一张 “仓库通行证” ，知乎可以拿着它去微信的仓库（资源服务器）里取你的信息（头像、昵称）。

这里就产生了两个问题：

信息不标准：知乎去微信仓库取信息，微信返回的数据格式可能是自定义的。如果换做“GitHub登录”，又是另一套格式。知乎需要为每个登录方式编写不同的数据解析代码。
核心诉求未直接满足：知乎的目的是“认证用户身份”，但它不得不先“授权”，再用授权得到的令牌去“换取用户信息”。这个过程是间接的。

一句话总结：OAuth 2.0 告诉你 “这个用户允许你访问这些数据”，但它没有用一种标准的方式告诉你 “这个用户到底是谁？”。

4.1. OIDC 的登场：在授权之上，建立统一的身份层

为了解决上述问题，OpenID Connect 应运而生。它不是取代 OAuth 2.0，而是建立在 OAuth 2.0 授权码流程之上的一个“身份认证”协议。

你可以把 OIDC 理解为 OAuth 2.0 的一个 “官方认证信息扩展包”。

4.1.1. OIDC 的核心创新：ID Token

在标准的 OAuth 2.0 流程中，知乎用授权码换回的是一个 访问令牌。而在 OIDC 流程中，知乎用授权码换回的是 两样东西：

访问令牌 – 和以前一样，用于去用户信息端点获取用户详情。
ID Token – 这是一个全新的、核心的东西。

一个生动比喻：

OAuth 2.0：微信管家给你（知乎）一张“仓库通行证”（访问令牌），让你自己去仓库里翻找用户的身份证明文件。
OIDC：微信管家除了给你“仓库通行证”，还直接、当场给你一份由他亲自签名盖章的“标准化身份凭证”。这份凭证有标准格式，全世界的系统都能识别。

这份 “标准化身份凭证” 就是 ID Token。它是一个 JWT，里面直接包含了用户的唯一标识、姓名等信息，并且由微信的授权服务器进行数字签名，防伪且可信。

4.1.2. OIDC 带来的巨大好处：

直接认证：知乎拿到 ID Token 后，立即就能知道用户是谁，无需再额外调用一次API。这大大加快了登录速度。
标准化：ID Token 的内容有标准字段（如 sub 表示用户唯一ID, name, email等），无论你用微信、GitHub还是Google登录，知乎都能用同一套逻辑解析用户身份。
更安全：由于 ID Token 是签名的，知乎可以本地验证其真实性，防止被篡改。

4.2. OAuth 2.0 与 OIDC 的核心区别：一张图讲清

让我们用“微信登录知乎”这个例子来做一个终极对比：

4.3. 小结

所以，当我们今天在使用“微信登录知乎”时，我们看到的虽然是一个“登录”行为，但其背后运行的协议，绝大多数情况下已经是 OIDC，而不仅仅是 OAuth 2.0 了。

OAuth 2.0 是基石，提供了安全的授权框架。
OIDC 是上层建筑，利用 OAuth 2.0 的安全流程，专门解决了“身份认证”这个互联网核心问题。

简单来说：OAuth 2.0 是关于授权的协议；OIDC 是关于在授权基础上进行认证的协议。 几乎所有现代的“社交登录”，都是 OIDC 的具体实现。

5. 常见典型问题答疑

5.1. JWT跟OAuth 2.0之间是什么关系？

实际上，JWT跟OAuth 2.0并没有直接关系，它只是一种结构化的信息存储，可以被用在除了OAuth 2.0以外的任何地方。比如，重置密码的时候，会给你的邮箱发送一个链接，这个链接就需要能够标识出用户是谁、不能篡改、有效期5分钟，这些特征都跟JWT相符合。也就是说，JWT并不是OAuth 2.0协议规范所涵盖的内容。

JWT格式令牌的最大问题在于 “覆水难收”，也就是说，没办法在使用过程中修改令牌状态。

若想了解更多关于JWT的内容，可以参阅往期博文：

一文看懂JWT如何重塑网络身份认证：从“身份证”到“数字令牌”

5.2. 使用了HTTPS，是不是就能确保JWT格式令牌的数据安全？

OAuth 2.0 需要搭配HTTPS使用。因为访问令牌、应用密钥敏感信息要在网络上传输，都离不开HTTPS的保护。但是，HTTPS也只是保证了访问令牌等重要信息在网络传输上的安全。

在OAuth 2.0 的规范中，访问令牌对第三方软件是不透明的，从来都不应该被任何第三方软件解析到。由于JWT格式的令牌自包含了用户相关的信息，比如用户标识，因此仅仅对它进行签名还不够。要避免第三方软件有机会获取访问令牌所包含的信息，那我们在与第三方软件交互的环境下使用JWT格式的令牌时，还要对它进行加密来保障令牌的安全，而不是仅仅依靠HTTPS。

5.3. OAuth 2.0和单点登录SSO的区别？

公司的SSO（单点登录）系统常被误认为就是OAuth 2.0，但其实二者职责不同。OAuth 2.0本质是授权协议，不是身份认证协议。它解决的是“我能访问哪些资源”，而非“你是谁”。

但在实际应用中，如微信登录、GitHub第三方登录，OAuth 2.0常与OIDC结合使用，后者在OAuth之上增加了身份层，才真正实现认证功能。此时，用户无需向第三方暴露密码，授权服务完成认证后返回授权码，第三方再换取访问令牌和用户身份信息。

因此，许多公司所谓的“OAuth实现SSO”，其实是基于OAuth 2.0的流程，配合ID Token或用户信息接口，实现了身份认证效果。这造成了“OAuth=SSO单点登录”的误解。真正的SSO应包含统一身份认证和跨系统会话管理，而纯OAuth 2.0仅提供授权通道，需扩展才能支撑完整SSO能力。

参考链接

网站应用微信登录开发指南: https://developers.weixin.qq.com/doc/oplatform/Website_App/WeChat_Login/Wechat_Login.html
The OAuth 2.0 Authorization Framework: https://datatracker.ietf.org/doc/html/rfc6749
OAuth 2.0实战课（王新栋）: https://geek.csdn.net/educolumn/c413c8717724fbbb5a2956cd73b1545f

关注我，带你看懂技术本质！用最接地气的”人话”拆解硬核知识，让复杂概念变得简单易懂 🔥