���盖 OAuth 2.0 授权码流程、设备指纹生成与绑定、安全存储、服务端校验、防 Token 复制攻击的全链路实施方案
四条泳道(用户 → WorkBuddy → Skills → MCP/API)自上而下描述完整的 OAuth 2.0 授权码鉴权流程。包含 Token 缺失走 OAuth 和 Token 有效跳过 OAuth 两条路径。
设备指纹是防 Token 复制的核心机制。每次 OAuth 授权时,WorkBuddy 将本机硬件指纹写入 JWT 的 cnf (confirmation) 声明。后续 MCP 请求必须携带相同的指纹,否则服务端拒绝访问。
跨平台硬件信号采集器,Windows / macOS / Linux 三端适配。信号哈希后不可逆,不泄露原始硬件信息。
| 信号 | 值 | 可靠性 |
|---|---|---|
| MachineGuid | 164ecf8e-d075-4349-8fbe-b2d4dd928efe | ★★★★★ |
| BIOS 序列号 | 67422/25SE01488 | ★★★★☆ |
| 主板序列号 | 525M59SRMP000559P02BS | ★★★★☆ |
| CPU ID | BFEBFBFF000B06A2 | ★★★★☆ |
| 设备指纹(SHA-256) | 0712a0d153af628a68b972c6f878285ab094bbf97e64634332d4aa6b65292acc | 衍生值 |
测试设备: XIAOMI TM2413 / i5-13500H / 32GB / Windows 11 — 4/4 核心信号全部可用
单靠硬件指纹不够——两台同型号批次的电脑可能有相同硬件信号。引入 WorkBuddy 实例 ID(软件层第二因子),双因子组合确保唯一性。
绑定密钥不能明文存储在文件里(可被复制)。必须存入操作系统原生加密区:Windows DPAPI / macOS Keychain / Linux Secret Service。
| 平台 | 机制 | 复制到其他机器可用? | 原因 |
|---|---|---|---|
| Windows | DPAPI | ✗ 不可用 | 加密时绑定当前用户 SID + 机器密钥 |
| macOS | Keychain | ✗ 不可用 | 密钥受登录密码保护,Apple Silicon 走 Secure Enclave |
| Linux | Secret Service | ✗ 不可用 | 密钥环用用户登录密码加密 |
OAuth 授权时在 Token 交换请求和每次 MCP 调用中注入设备绑定信息。
服务端在签发 JWT 时将设备绑定写入声明,每次 MCP 请求时校验三层:签名 → 过期 → 设备绑定。
| 攻击者做了什么 | 结果 | 失败原因 |
|---|---|---|
| 只复制 oauth_tokens/ 目录 | 403 拒绝 | 请求头中的设备指纹 ≠ JWT 中绑定的指纹 |
| 复制 oauth_tokens/ + config.json | 403 拒绝 | 硬件不同 → 指纹不同 → 绑定密钥不同 |
| 复制全部文件 + 伪造设备指纹 | 403 拒绝 | 不知道原始硬件信号值,无法生成相同哈希 |
| 同一台机器复制到另一个 WorkBuddy 安装 | 403 拒绝 | 实例 ID 不同 → 绑定密钥不同 |
| 同一台机器 + 同一 WorkBuddy 安装 | 通过 | 本质是同一用户在同一机器使用(非攻击场景) |
| DPAPI 加密文件复制到其他机器 | 解密失败 | DPAPI 绑定当前用户 SID + 机器密钥,异机无法解密 |
| 拦截 authorization_code 后伪造请求 | 换 Token 失败 | 缺少 PKCE code_verifier(仅存于原始机器安全区) |
| 方案 | 防复制强度 | 实现复杂度 | 标准化 | 推荐度 |
|---|---|---|---|---|
| 短效 Token + Refresh 轮转 | ★★☆ | 低 | OAuth 2.0 标准 | 辅助 |
| PKCE | ★★☆ | 低 | RFC 7636 | 标配 |
| 设备指纹绑定 | ★★★ | 中 | 自定义扩展 | ⭐ 核心 |
| DPoP (RFC 9449) | ★★★★ | 高 | RFC 9449 | 进阶 |
| mTLS (RFC 8705) | ★★★★ | 高 | RFC 8705 | 企业级 |
| Introspection + 风控 | ★★★ | 中 | RFC 7662 | 辅助 |