3、隐式模式与密码模式：流程、场景与安全风险
隐式模式（Implicit Grant）与密码模式（Resource Owner Password Credentials Grant）是 OAuth 2.0 早期定义的两种授权流程。由于安全缺陷明显，两者均已被 IETF 在 RFC 6749 后续安全最佳实践（BCP 195 / RFC 9700）中标记为“不推荐使用”。但大量遗留系统仍在使用，理解其流程、适用场景与风险，是安全审计和迁移改造的基础。
3.1 隐式模式流程
隐式模式专为纯前端应用（如浏览器中的 JavaScript SPA）设计，其核心特征是授权服务器直接通过 URL 片段（Fragment）向客户端返回 Access Token，跳过授权码交换步骤。
关键特征：令牌直接暴露在浏览器地址栏 # 之后，无客户端认证环节。
隐式模式步骤说明
- 用户访问客户端：浏览器加载 SPA 应用。
- 授权请求：客户端将用户代理重定向至授权服务器，请求参数包含
response_type=token。 - 用户认证并授权：用户在授权服务器登录并同意授权。
- 返回令牌：授权服务器将 Access Token 放在重定向 URI 的
#片段中返回给浏览器。 - 令牌提取：客户端 JavaScript 从 URL 片段中提取 Access Token。
- 访问资源：客户端使用 Access Token 请求资源服务器。
3.2 密码模式流程
密码模式允许客户端直接收集用户的用户名和密码，并以此向授权服务器换取 Access Token。该模式完全放弃了 OAuth 的委托授权本质，将用户凭证直接暴露给第三方客户端。
密码模式步骤说明
- 用户提供凭证：用户在客户端界面输入用户名和密码。
- 凭证交换：客户端将用户凭证通过 POST 请求发送给授权服务器，参数包含
grant_type=password、username、password。 - 返回令牌：授权服务器验证凭证后，直接返回 Access Token（可选返回 Refresh Token）。
- 访问资源：客户端使用 Access Token 请求资源服务器。
3.3 适用场景对比
| 对比维度 | 隐式模式 | 密码模式 |
|---|---|---|
| 典型客户端 | 浏览器 SPA、移动端 WebView | 第一方原生应用、遗留 CLI 工具 |
| 用户交互 | 重定向至授权服务器登录页面 | 直接在客户端输入用户名/密码 |
| 令牌传递 | URL Fragment（#） | HTTP 响应体（JSON） |
| 客户端认证 | 不支持 | 可选（client_secret） |
| Refresh Token | 不支持 | 支持（但风险高） |
| 当前推荐度 | ❌ 不推荐（已废弃） | ❌ 不推荐（仅限迁移场景） |
3.4 安全风险分析
隐式模式风险清单
- 令牌泄露：Access Token 出现在浏览器地址栏、历史记录、Referer 头中，中间人攻击或恶意脚本可轻易截获。
- 无客户端认证：授权服务器无法确认请求来自合法的注册客户端，易被重放和冒充。
- 无 Refresh Token：令牌过期后必须重新授权，用户体验差且增加交互风险。
- 混合攻击：攻击者可通过注册恶意客户端，诱导用户授权后窃取令牌。
密码模式风险清单
- 凭证直接暴露：客户端存储或传输用户密码，一旦客户端被逆向或篡改，所有用户密码泄露。
- 无委托授权：用户将密码交给第三方客户端，违背 OAuth 的“授权委托”核心原则。
- 不支持多因素认证：密码模式无法集成 2FA、生物识别等增强认证。
- 凭证重用风险：用户常在不同服务使用相同密码，泄露后影响范围扩大。
安全建议：新系统应使用授权码模式（Authorization Code Grant）配合 PKCE 扩展。对于遗留系统，密码模式应尽快迁移至授权码模式；隐式模式应升级为授权码模式 + PKCE，并启用 Form Post 响应模式替代 Fragment 传递。
风险对比总结
| 风险维度 | 隐式模式 | 密码模式 |
|---|---|---|
| 令牌/凭证泄露 | 高（URL 暴露） | 极高（密码明文） |
| 客户端冒充 | 高（无认证） | 中（可加 client_secret） |
| 多因素认证支持 | 支持（通过授权页面） | 不支持 |
| 凭证重用风险 | 低（不接触密码） | 高（直接收集密码） |
| 审计追溯能力 | 弱 | 弱 |