| name | configuring-oauth2-authorization-flow |
| description | 配置安全的 OAuth 2.0 授权流程，包括带 PKCE 的授权码流、客户端凭据和设备授权授予。本技能涵盖流程选择、PKCE 实施、令牌生命周期管理、范围设计以及符合 OAuth 2.1 安全要求。 |
| domain | cybersecurity |
| subdomain | identity-access-management |
| tags | ["iam","identity","access-control","authentication","authorization","oauth2","oidc","pkce"] |
| version | 1.0 |
| author | mahipal |
| license | Apache-2.0 |
配置 OAuth 2.0 授权流程
概述
配置安全的 OAuth 2.0 授权流程，包括带 PKCE（Proof Key for Code Exchange）的授权码流、客户端凭据和设备授权授予。本技能涵盖流程选择、PKCE 实施、令牌生命周期管理、范围设计以及符合 OAuth 2.1 安全要求。
目标
- 为公共客户端和机密客户端实施带 PKCE 的授权码流
- 为机器间通信配置客户端凭据流
- 设计最小权限范围层次结构
- 实施安全的令牌存储、刷新和撤销
- 应用 OAuth 2.1 最佳实践和 RFC 9700 安全建议
- 验证令牌完整性并防止常见 OAuth 攻击
核心概念
OAuth 2.0 授权类型
- 授权码 + PKCE：推荐用于所有客户端类型（Web、移动、SPA）。PKCE 在 OAuth 2.1 中为强制要求。
- 客户端凭据：无用户上下文的机器间认证。
- 设备授权授予（RFC 8628）：用于输入受限设备（智能电视、CLI 工具）。
- 刷新令牌：长期有效的令牌，无需重新认证即可获取新访问令牌。
PKCE（授权码交换证明密钥）
PKCE（RFC 7636）防止授权码拦截攻击：
- 客户端生成随机
code_verifier（43-128 个字符，不保留 URI 字符）
- 客户端计算
code_challenge = BASE64URL(SHA256(code_verifier))
- 授权请求包含
code_challenge 和 code_challenge_method=S256
- 令牌请求包含原始
code_verifier
- 服务器验证
SHA256(code_verifier) 与存储的 code_challenge 匹配
令牌类型
- 访问令牌：短期有效（5-60 分钟），bearer 或 DPoP 绑定
- 刷新令牌：长期有效，一次性使用并轮换
- ID 令牌（OIDC）：包含用户身份声明的 JWT
实施步骤
步骤 1：带 PKCE 的授权码流
- 生成加密随机 code_verifier（最少 43 个字符）
- 使用 S256 方法计算 code_challenge
- 使用以下参数将用户重定向到授权端点：
- response_type=code
- client_id、redirect_uri、scope、state
- code_challenge、code_challenge_method=S256
- 用户进行认证和授权
- 授权服务器使用授权码重定向
- 在令牌端点用 code + code_verifier 交换令牌
- 验证 state 参数与原始值匹配
步骤 2：范围设计
- 定义细粒度范围：
read:users、write:orders、admin:settings
- 遵循最小权限：只请求所需的最少范围
- 在资源服务器上实施范围验证
- 记录范围层次结构和同意要求
步骤 3：令牌安全
- 安全存储令牌（Web 应用使用 httpOnly Cookie，移动端使用密钥链）
- 实施带轮换的令牌刷新（一次性使用刷新令牌）
- 设置适当的过期时间：访问令牌 5-15 分钟，刷新令牌 8-24 小时
- 启用 DPoP（持有证明）用于发送方约束令牌
- 实施令牌撤销端点
步骤 4：客户端凭据流
- 注册服务客户端，包含 client_id 和 client_secret
- 请求令牌：POST /oauth/token，参数 grant_type=client_credentials
- 包含所需权限的 scope
- 安全存储 client_secret（保险库、环境变量，而非代码中）
- 为更高保障级别实施基于证书的客户端认证
步骤 5：安全加固
- 对所有授权码流强制执行 PKCE
- 使用精确的重定向 URI 匹配（无通配符）
- 使用 state 参数实施 CSRF 保护
- 启用刷新令牌轮换，并在检测到重用时撤销
- 应用 RFC 9700 安全最佳实践
- 阻止隐式授予和 ROPC（在 OAuth 2.1 中已移除）
安全控制
| 控制项 | NIST 800-53 | 描述 |
|---|
| 访问控制 | AC-3 | 基于令牌的访问执行 |
| 认证 | IA-5 | 客户端凭据管理 |
| 会话管理 | SC-23 | 令牌生命周期管理 |
| 审计 | AU-3 | 记录所有令牌颁发和撤销 |
| 加密保护 | SC-13 | PKCE 和令牌签名 |
常见陷阱
- 使用隐式授予（OAuth 2.1 中已移除）而非授权码 + PKCE
- 将令牌存储在 localStorage（容易受 XSS 攻击）而非 httpOnly Cookie
- 未验证 state 参数，使 CSRF 攻击成为可能
- 使用通配符重定向 URI，允许开放重定向利用
- 未实施刷新令牌轮换，导致令牌盗窃持续有效
验证
