ROPC（资源所有者密码凭据模式 Resource Owner Password Credentials）介绍（OTP、TOTP、FIDO2、WebAuthn、CTAP、Passkey）

文章目录

• ROPC（Resource Owner Password Credentials）详解：OAuth 2.0 中最具争议的授权模式
• • 引言
  • OAuth 诞生前的问题
  • OAuth 的核心思想
  • 什么是 ROPC
  • ROPC 请求示例
  • ROPC 的优点
  • • 1. 实现简单
    • 2. 用户体验简单
    • 3. 适合遗留系统改造
  • ROPC 的致命问题
  • • 1. 客户端必须知道用户密码
    • 2. 无法支持 MFA
    • 3. 无法支持 SSO
    • 4. 无法实现零信任认证
  • OAuth 2.1 为什么删除了 ROPC
  • ROPC 与 Authorization Code 的比较
  • Keycloak 中的 ROPC
  • 现在还有哪些场景会使用 ROPC
  • • 企业内部系统
    • 遗留系统迁移
    • CLI 工具（历史方案）
  • 总结

ROPC（Resource Owner Password Credentials）详解：OAuth 2.0 中最具争议的授权模式

引言

在 OAuth 2.0 的各种授权模式中，ROPC（Resource Owner Password Credentials）一直是一个颇具争议的存在。

一方面，它实现简单、开发成本低，在 OAuth 2.0 早期曾被广泛采用；另一方面，它要求用户直接将账号密码交给客户端应用，违背了 OAuth 设计的核心理念，因此如今已被大多数安全规范所淘汰。

本文将介绍 ROPC 的工作原理、历史背景、优缺点，以及为什么现代系统应避免使用它。

---

OAuth 诞生前的问题

在 OAuth 出现之前，如果一个第三方应用需要访问用户资源，通常只能让用户提供账号密码。

例如：

• 邮件客户端获取 Gmail 邮件
• 第三方网站读取社交媒体数据
• 自动化工具访问企业系统

典型流程：

用户 │ ├── 用户名 └── 密码 │ ▼ 第三方应用 │ ▼ 资源服务器

这种方式存在明显问题：

1. 用户必须将密码交给第三方应用
2. 第三方应用可能保存密码
3. 密码泄露风险极高
4. 无法限制权限范围
5. 无法单独撤销授权

OAuth 的出现就是为了解决这些问题。

---

OAuth 的核心思想

OAuth 的核心原则是：

第三方应用不应该接触用户密码。

正确的 OAuth 流程应该是：

用户 │ ▼ 授权服务器 │ ▼ Access Token │ ▼ 客户端应用 │ ▼ 资源服务器

客户端拿到的是 Token，而不是密码。

这也是现代 OAuth 的基本设计理念。

---

什么是 ROPC

ROPC 全称：

Resource Owner Password Credentials Grant

中文通常翻译为：

资源所有者密码凭据模式

在这种模式下：

用户直接把用户名和密码提供给客户端应用。

客户端再使用这些凭据向授权服务器换取 Access Token。

流程如下：

+--------+ | User | +--------+ | | Username + Password v +-----------+ | Client | +-----------+ | | POST /token | grant_type=password | v +------------------+ | Authorization | | Server | +------------------+ | | Access Token v +-----------+ | Client | +-----------+

与其它 OAuth 模式相比：

ROPC 完全绕过了浏览器授权页面。

---

ROPC 请求示例

客户端向 Token Endpoint 发送请求：

POST /oauth/token grant_type=password username=alice password=123456 client_id=my-client client_secret=secret

授权服务器验证成功后返回：

{"access_token":"eyJhbGci...","token_type":"Bearer","expires_in":3600,"refresh_token":"xyz..."}

之后客户端即可使用 Access Token 访问资源：

GET /api/profile Authorization: Bearer eyJhbGci...

---

ROPC 的优点

1. 实现简单

无需：

• 浏览器跳转
• 授权页面
• 回调地址

开发成本极低。

对于早期系统来说非常方便。

---

2. 用户体验简单

用户只需要输入：

用户名 密码

即可登录。

不需要经历：

跳转 授权 确认 回调

整个过程更加直接。

---

3. 适合遗留系统改造

很多企业内部系统原本就是：

用户名 + 密码

认证模式。

引入 ROPC 可以较低成本地升级到 OAuth 架构。

---

ROPC 的致命问题

虽然简单，但它违背了 OAuth 最重要的设计原则。

1. 客户端必须知道用户密码

OAuth 的本意：

用户 → 授权服务器

ROPC 变成：

用户 → 客户端 → 授权服务器

客户端获得了用户密码。

这意味着：

• 密码可能被记录
• 密码可能被缓存
• 密码可能被泄露

---

2. 无法支持 MFA

现代认证越来越依赖：

• OTP（One-Time Password） - 一次性密码，每个密码只能使用一次，通常每隔30或60秒生成新密码，用于增强账户安全性的双因素认证技术
• TOTP（Time-Based One-Time Password） - 基于时间的一次性密码，通过时间戳算法生成动态密码，要求客户端和服务器时间同步，是OTP的具体实现方式
• FIDO2（Fast IDentity Online 2） - 开放式身份验证标准，包含WebAuthn和CTAP两大核心组件，旨在实现无密码安全认证，提供防钓鱼保护
• Passkey（通行密钥） - 基于FIDO2标准的无密码认证方式，使用公钥/私钥加密技术，支持生物识别或PIN码验证，可跨设备同步使用
• WebAuthn（Web Authentication） - W3C标准，FIDO2的核心组件，提供浏览器与认证器（如安全密钥、生物识别设备）之间的交互接口，实现无密码网页认证

例如：

用户名 密码 短信验证码

ROPC 只能提交用户名和密码。

无法很好支持这些现代认证机制。

---

3. 无法支持 SSO

现代企业普遍采用：

• SAML
• OAuth
• OpenID Connect

进行统一身份认证。

典型流程：

应用 ↓ Keycloak ↓ Azure AD

ROPC 绕过浏览器流程后：

• 无法展示登录页面
• 无法进行身份联邦
• 无法进行外部认证跳转

因此与 SSO 天然冲突。

---

4. 无法实现零信任认证

现代安全架构越来越强调：

• Device Trust
• Conditional Access
• Risk Based Authentication

例如：

新设备登录 异地登录 高风险IP

这些场景通常需要：

• 浏览器交互
• 额外验证步骤

ROPC 无法支持。

---

OAuth 2.1 为什么删除了 ROPC

OAuth 2.1 草案直接移除了 ROPC。

原因非常明确：

ROPC encourages insecure handling of user credentials.

即：

ROPC 会鼓励客户端处理用户密码，从而带来安全风险。

OAuth 社区认为：

现代系统已经有更好的替代方案。

因此不再推荐继续使用。

---

ROPC 与 Authorization Code 的比较

项目	ROPC	Authorization Code
客户端获得密码	是	否
支持 MFA	差	好
支持 SSO	差	好
支持身份联邦	差	好
安全性	低	高
实现复杂度	低	中
OAuth 2.1 支持	否	是

---

Keycloak 中的 ROPC

在 Keycloak 中：

ROPC 对应：

Direct Access Grants

开启位置：

Clients └── Client └── Capability Config └── Direct Access Grants Enabled

启用后即可使用：

POST /realms/{realm}/protocol/openid-connect/token

请求：

grant_type=password username=alice password=123456 client_id=my-client

获取 Access Token。

不过 Keycloak 官方也建议：

除非必要，否则优先使用：

• Authorization Code Flow
• Authorization Code + PKCE

而非 Direct Access Grants。

---

现在还有哪些场景会使用 ROPC

虽然已经过时，但仍然存在于一些特殊场景：

企业内部系统

完全可信环境：

员工客户端 ↓ 企业认证中心

风险可控。

---

遗留系统迁移

从：

用户名 + 密码

逐步迁移到：

OAuth 2.0

过程中临时使用。

---

CLI 工具（历史方案）

早期命令行工具常使用：

username: password:

获取 Token。

如今越来越多工具改为：

Device Authorization Flow

例如：

• GitHub CLI
• Azure CLI
• Google Cloud CLI

都已经基本放弃 ROPC。

---

总结

ROPC 是 OAuth 2.0 中最简单的一种授权模式，其本质是：

使用用户名和密码直接换取 Access Token。

它曾经帮助大量传统系统快速接入 OAuth，但也因为要求客户端直接处理用户密码而带来了严重安全隐患。

现代身份认证体系的发展方向已经十分明确：

• Authorization Code Flow
• PKCE
• OpenID Connect
• MFA
• Passkey
• WebAuthn

这些技术都建立在“客户端不接触用户密码”的原则之上。

因此在新的系统设计中，ROPC 更适合作为理解 OAuth 演进历史的一个阶段，而不应作为首选方案。对于绝大多数场景，Authorization Code + PKCE 已经成为事实上的最佳实践。