本文发布于北京时间
一、开篇引入
在现代互联网应用中，几乎每个开发者都遇到过这样的场景：一个网站提示“使用微信登录”或“使用Google账户登录”，你点击后跳转到对应的平台，授权后便完成了登录，无需为第三方应用单独注册账户。这背后支撑的核心技术就是
很多学习者对OAuth 2.0的理解停留在“会用第三方登录”的层面，一旦面试中被问到“四种授权模式的区别是什么”“访问令牌和刷新令牌如何配合工作”“OAuth与OIDC有什么不同”等问题时，往往答不出关键逻辑。本文将从核心概念、四大授权模式、代码实现、底层原理到高频面试题，由浅入深帮读者建立完整的OAuth 2.0知识链路。
二、痛点切入：为什么需要OAuth 2.0
2.1 传统授权方式的缺陷
在OAuth出现之前，第三方应用若要访问用户在另一平台的数据，最直接的做法是：让用户把用户名和密码直接交给第三方应用。
传统方案：第三方应用直接保存用户的账号密码 def access_photo_service(username, password): 第三方应用需要保存用户的账密 session = login_to_service(username, password) 高危操作！ photos = fetch_user_photos(session) return photos
这种做法的缺陷非常明显：
安全性极差：第三方应用可以访问用户的全部资源，而不仅仅是它需要的部分。
密码暴露风险：用户不得不将密码交给第三方，第三方如何保管、是否会被泄露都不可控。
权限无法回收：用户无法单独收回某一应用的授权，只能通过改密码来“一刀切”地收回所有授权。
扩展性差：每新增一个第三方应用，都要面临同样的安全风险。
2.2 OAuth 2.0的设计初衷
为了解决上述问题，OAuth 2.0采用了基于令牌（Token）的授权机制，核心思想是：用令牌代替密码。用户只需授权一次，授权服务器颁发一个有限权限、有限有效期的令牌给第三方应用，第三方凭此令牌访问用户资源，全程不触及用户密码-51。
三、核心概念讲解：OAuth 2.0的角色与令牌
3.1 四个核心角色
OAuth 2.0协议规范定义了以下四个主体-1：
| 角色 | 英文 | 说明 |
|---|---|---|
| 资源所有者 | Resource Owner | 即用户本人，拥有受保护资源的所有权 |
| 客户端 | Client | 第三方应用程序，请求访问用户资源的应用 |
| 授权服务器 | Authorization Server | 验证用户身份并颁发访问令牌的服务器 |
| 资源服务器 | Resource Server | 托管受保护资源的服务器，接收并验证访问令牌后返回资源 |
3.2 两种核心令牌
访问令牌（Access Token） ：客户端用来访问受保护资源的凭据，表示授权的权限范围和有效期，通常具有较短的生命周期-12。
刷新令牌（Refresh Token） ：一个长期有效的令牌，用于在访问令牌过期后获取新的访问令牌，无需用户重新授权-12。
四、四种授权模式讲解
OAuth 2.0定义了四种授权模式（Grant Types），适应不同的应用场景-54。
4.1 授权码模式（Authorization Code Grant）
最安全、应用最广泛的模式，适用于有服务端的Web应用。
伪代码：授权码模式的核心流程 Step 1: 客户端重定向用户到授权服务器 redirect_to_auth_server({ "response_type": "code", "client_id": "your_app_id", "redirect_uri": "https://yourapp.com/callback", "scope": "read_photos" }) Step 2: 用户登录并授权后，授权服务器返回授权码（在回调URL中） redirect_uri?code=AUTHORIZATION_CODE Step 3: 客户端后端用授权码换取访问令牌 def exchange_code_for_token(auth_code): response = http.post("https://auth-server.com/token", { "grant_type": "authorization_code", "code": auth_code, "client_id": "your_app_id", "client_secret": "your_app_secret" }) return response.json() 返回access_token和refresh_token
4.2 密码模式（Resource Owner Password Credentials Grant）
用户直接将用户名和密码提供给客户端，客户端用它们换取访问令牌。仅适用于高度信任的客户端，目前已不推荐使用。
4.3 客户端凭证模式（Client Credentials Grant）
客户端使用自己的凭证（client_id和client_secret）直接向授权服务器请求令牌。适用于机器对机器（M2M）通信，无需用户参与。
4.4 隐式模式（Implicit Grant）
访问令牌直接通过重定向返回给客户端，无需中间授权码。由于安全缺陷显著，已在OAuth 2.1中被移除-60。
五、概念关系与区别总结
5.1 OAuth vs SSO vs OIDC
| 概念 | 用途 | 核心关注 |
|---|---|---|
| OAuth 2.0 | 授权协议，允许第三方访问用户数据 | Authorization（授权） |
| SSO | 单点登录，一次登录访问多个系统 | Authentication（认证） |
| OIDC | OAuth 2.0之上的身份认证层，能确认用户身份并返回用户信息 | Authentication + Authorization |
一句话概括：OAuth管“能做什么”，SSO管“你是谁”，OIDC把两者结合-22。
5.2 OAuth vs JWT
| 对比维度 | OAuth 2.0 | JWT |
|---|---|---|
| 本质 | 授权框架（协议），定义如何授权 | 令牌格式（数据结构），定义如何打包信息 |
| 核心作用 | 定义令牌的颁发、刷新、撤销流程 | 携带声明的紧凑格式，可自验证 |
| 典型关系 | OAuth常用JWT作为访问令牌的格式 |
OAuth和JWT解决的是不同层面的问题——OAuth是一个协议框架，JWT是一种数据格式-43。在实际生产环境中，两者往往配合使用。
六、代码示例：Spring Boot实现授权码模式
以下是一个基于Spring Security OAuth2的简化示例（关键步骤已标注）：
// 1. 配置授权服务器 @Configuration @EnableAuthorizationServer public class AuthServerConfig extends AuthorizationServerConfigurerAdapter { @Override public void configure(ClientDetailsServiceConfigurer clients) throws Exception { clients.inMemory() .withClient("client-app") // client_id .secret("{bcrypt}encoded-secret") // client_secret .authorizedGrantTypes("authorization_code", "refresh_token") .scopes("read", "write") .redirectUris("https://yourapp.com/callback") .accessTokenValiditySeconds(3600) // 访问令牌1小时 .refreshTokenValiditySeconds(86400); // 刷新令牌24小时 } } // 2. 配置资源服务器 @Configuration @EnableResourceServer public class ResourceServerConfig extends ResourceServerConfigurerAdapter { @Override public void configure(HttpSecurity http) throws Exception { http.authorizeRequests() .antMatchers("/api/").authenticated(); } } // 3. 客户端发起授权请求 // 浏览器访问：https://auth-server.com/oauth/authorize?client_id=client-app&response_type=code&redirect_uri=https://yourapp.com/callback&scope=read
七、底层原理与技术支撑
OAuth 2.0的核心安全机制建立在以下几个底层技术上：
HTTPS加密传输：所有令牌和授权码的传输必须通过HTTPS，防止中间人攻击-12。
令牌自包含与签名：当使用JWT格式的访问令牌时，令牌中包含签名，资源服务器可本地验证令牌真实性，无需每次调用授权服务器-43。
PKCE（Proof Key for Code Exchange） ：在OAuth 2.1中，PKCE已成为所有客户端的强制要求，用于防止授权码拦截攻击-60。
State参数防CSRF：授权请求中的state参数用于防止跨站请求伪造攻击。
八、高频面试题与参考答案
问题1：什么是OAuth 2.0？它的核心角色有哪些？
答案：OAuth 2.0是一个开放标准的授权协议，用于授权第三方应用访问用户受保护资源，无需共享用户凭证。核心角色包括：资源所有者（用户）、客户端（第三方应用）、授权服务器（颁发令牌）、资源服务器（托管资源）-12。
问题2：访问令牌和刷新令牌有什么区别？
答案：访问令牌用于直接访问资源，有效期短（通常数小时）；刷新令牌用于获取新的访问令牌，有效期长（通常数天甚至更长），客户端可在访问令牌过期时使用刷新令牌申请新令牌，无需用户重新授权-12。
问题3：授权码模式为什么最安全？
答案：因为授权码在浏览器前端信道传输，而访问令牌在后端信道（服务端到服务端）传输。即使授权码被拦截，攻击者也无法直接使用，因为换取令牌还需要client_secret。这种前后端分离的设计大幅降低了令牌暴露风险。
问题4：OAuth 2.0是认证协议还是授权协议？它与OIDC有什么区别？
答案：OAuth 2.0是授权协议，负责授予权限而非确认身份。OIDC（OpenID Connect）是在OAuth 2.0之上构建的身份认证层，增加了ID Token来携带用户身份信息，实现了“认证+授权”的完整方案-22。
问题5：OAuth 2.1相比2.0有哪些重大变化？
答案：OAuth 2.1废弃了隐式模式和不安全的资源所有者密码凭证模式，强制要求所有客户端使用授权码模式+PKCE，禁止在URL查询参数中传递Bearer令牌，并整合了PKCE、令牌撤销等安全最佳实践-60。
九、结尾总结
本文系统梳理了OAuth 2.0授权框架的核心知识点：
✅ 四个角色：资源所有者、客户端、授权服务器、资源服务器
✅ 两种令牌：访问令牌（短效）+ 刷新令牌（长效）
✅ 四种授权模式：授权码模式（最安全）是首选
✅ 概念辨析：OAuth（授权）≠ SSO（单点登录）≠ OIDC（认证+授权）
✅ 技术要点：HTTPS加密、令牌自验证、PKCE防拦截
重点提示：随着OAuth 2.1的普及，隐式模式和密码模式已在2026年被正式废弃，新项目应统一使用授权码模式+PKCE。
下一期将深入解析OAuth 2.1迁移实战，包括Spring Boot 3.x的完整配置方案，敬请期待！
