【OAuth2.0】一、OAuth2.0是什么？

FeiMinds

于 2025-06-25 11:23:29 发布

阅读量828

点赞数 13

CC 4.0 BY-SA版权

文章标签： java OAuth2.0 架构 spring boot OAuth

本文链接：https://blog.youkuaiyun.com/Jeffray1991/article/details/148895086

【OAuth2.0】一、OAuth2.0是什么？

我说了一辈子谎话，唯这一次说了实话，却死在一个骗子的手下。

《智取威虎山》

在互联网飞速发展的今天，我们每天都会使用各种应用和服务，其中相对比较常见的场景就是“第三方登录”，这里的第三方登录就是OAuth的经典应用。当我们使用微信账号登录其他网站或应用时，无需输入微信密码，就能快速授权登录并获取相关权限？这背后涉及到的关键技术就是 OAuth 2.0。这次打算用两篇文章分别解决下OAuth2.0“是什么”、“怎么用”的问题。Let’s go

OAuth2.0是什么

OAuth（开放授权）是一个开放标准，OAuth 2.0 是其目前广泛使用的版本。简单来说，OAuth 2.0 允许用户让第三方应用访问该用户在某一网站上存储的私密资源（如照片、视频、联系人列表等），而无需将用户名和密码提供给第三方应用。用户只需提供一个令牌（token），第三方应用就能在令牌的权限范围内访问特定资源，并且这个令牌具有特定的有效期和权限范围，大大提高了用户信息的安全性。

例如，你在使用一款美食推荐应用时，该应用想要获取你的微信头像和昵称来完善你的个人资料。如果没有 OAuth 2.0，美食推荐应用可能需要你提供微信账号和密码，这无疑存在很大的安全风险。但通过 OAuth 2.0，你只需在微信授权页面确认授权，美食推荐应用就能获得一个有限权限和有效期的令牌，从而获取你的头像和昵称，而无需知道你的微信密码。

简单来说，它是一套安全授权框架，让用户在不透露密码的前提下，授权第三方应用访问自己的资源。

就像酒店前台：你出示身份证（授权），服务员给你房卡（令牌）。全程无需透露家庭住址（密码），房卡还限定了使用范围！

为什么我们要使用OAuth2.0

传统密码登录存在致命隐患：

密码泄露风险：应用直接存储用户密码
权限泛滥：应用可访问用户所有信息
权限回收难：用户无法单独撤销某应用权限

OAuth 2.0一举解决所有痛点！它让资源方（微信）、用户、第三方应用形成安全闭环。

OAuth2.0 中的关键角色

在 OAuth 2.0 的体系中，主要涉及以下几个关键角色：

资源所有者（Resource Owner）：也就是用户，拥有需要被访问的资源，例如微信用户拥有自己的个人信息、朋友圈等资源。
第三方应用程序（Third - Party Application）：即想要访问用户资源的应用，如上述的美食推荐应用。在微信公众号的场景中，就是那些希望通过微信授权获取用户信息的公众号应用。
服务提供商（Service Provider）：拥有用户资源的平台，如微信。微信不仅存储着用户的各种信息，还负责处理用户的授权请求。
认证服务器（Authorization Server）：服务提供商用于处理认证的服务器，验证用户身份并发放令牌。在微信中，负责验证用户身份并决定是否给予第三方应用授权令牌的服务器就是认证服务器。
资源服务器（Resource Server）：存放用户生成资源的服务器，它与认证服务器可以是同一台服务器，也可以是不同的服务器。在微信的例子中，存储用户个人信息的服务器就可视为资源服务器。

OAuth2.0中的授权模式

OAuth 2.0 提供了四种主要的授权模式，不同的场景会选择不同的模式：

一、授权码模式（Authorization Code）

这是最常用的一种模式，微信公众号授权也采用这种模式。流程如下：

用户访问第三方应用，第三方应用将用户导向微信的认证服务器。例如，你点击公众号中的某个链接，该链接指向的第三方应用会引导你跳转到微信的授权页面。
用户在微信的认证服务器页面选择是否给予第三方应用授权。
若用户给予授权，微信认证服务器将用户导向第三方应用事先指定的 “重定向 URI”（redirection URI），同时附上一个授权码。
第三方应用收到授权码后，附上早先指定的 “重定向 URI”，向微信认证服务器申请令牌。这一步是在第三方应用的后台服务器上完成的，对用户不可见。
微信认证服务器核对授权码和重定向 URI，确认无误后，向第三方应用发送访问令牌（access token）和更新令牌（refresh token）。

二、简化模式（Implicit）

与授权码模式大致相同，但少了获取授权码这一步，直接返回访问令牌。这种模式适用于一些安全要求相对较低、客户端类型为浏览器端的场景，因为它少了一次交互，性能更优，但安全性稍逊一筹。

三、密码模式（Resource Owner Password Credentials）

这种模式需要用户向第三方应用提供自己在服务提供商处的用户名和密码，第三方应用用这些信息向服务提供商换取令牌。由于涉及用户密码的传递，存在较大安全风险，一般不推荐使用，除非是在非常信任的应用场景下，且服务提供商对密码安全有严格保障措施。

四、客户端凭证模式（Client Credentials）

主要用于第三方应用以自己的名义去访问资源，而不是代表某个用户。例如，一些数据分析应用需要获取某个公众号的文章阅读量等统计信息，它可以使用自己在微信平台注册的客户端凭证去获取相应的令牌，从而访问这些数据。

OAuth2.0 的安全机制

OAuth 2.0 在设计上充分考虑了安全性：

引入授权码（authorization_code）：如前文所述，在授权码模式中，不直接将访问令牌（access_token）通过重定向返回给第三方应用，而是先返回一个授权码。因为浏览器的 redirect_uri 是一个不安全信道，直接返回 access_token 存在被泄露的风险，例如 uri 可能通过 HTTP referrer 被传递给其它恶意站点，也可能存在于浏览器缓存或 log 文件中。而 authorization_code 相对不那么敏感，即使被泄露，攻击者也无法直接拿到 access_token，因为用 authorization_code 去交换 access_token 时，需要验证第三方应用的真实身份。
state 参数防止 CSRF 攻击：在 redirect_uri 中引入 state 参数，它可以用于抵制 CSRF（Cross - Site Request Forgery，跨站请求伪造）攻击。当第三方应用发起授权请求时，会生成一个唯一的 state 值并传递给微信服务器，微信服务器在重定向回第三方应用时，会原样返回这个 state 值。第三方应用可以在接收到返回的 state 值后，验证其是否与之前发送的一致，如果不一致，则说明该请求可能是被伪造的，从而避免了 CSRF 攻击带来的风险。

总结

OAuth 2.0 作为一种开放授权标准，在保障用户信息安全的前提下，为第三方应用和服务提供商之间搭建了一座桥梁，实现了用户资源的合理共享和利用。无论是对于开发者还是普通用户，了解 OAuth 2.0 都有助于更好地理解互联网应用中的授权过程，提升应用使用的安全性和体验感。在未来，随着互联网应用场景的不断丰富和发展，OAuth 2.0 也将持续发挥其重要作用，为我们的数字化生活保驾护航。

本篇文章着重介绍了OAuth2.0 “是什么”，下一篇文章我将结合Spring Boot工程，详细介绍下OAuth2.0 “怎么用”。

如果能帮我点个免费的关注，那就是对我个人的最大的肯定。如果觉得写的还行，分享一下也是我生活的小确幸~

Peace Guys，我们下篇文章再见。