L’interface est localisée ; les présentations et documents des Skills sont traduits automatiquement par IA dans votre langue. Le code, les commandes, chemins et termes techniques restent en version originale, et le document de l’auteur fait foi.
Explorer les Skills
Productivité · SKILL.md

configuring-oauth2-authorization-flow

configuring-oauth2-authorization-flow

配置安全的 OAuth 2.0 授权流程,包括带 PKCE 的授权码流、客户端凭据和设备授权授予。本技能涵盖流程选择、PKCE 实施、令牌生命周期管理、范围设计以及符合 OAuth 2.1 安全要求。

Independent GitHub snapshot · Automated classification · Original documentation governs

Documentation de la Skill

GitHub

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 授权类型

  1. 授权码 + PKCE:推荐用于所有客户端类型(Web、移动、SPA)。PKCE 在 OAuth 2.1 中为强制要求。
  2. 客户端凭据:无用户上下文的机器间认证。
  3. 设备授权授予(RFC 8628):用于输入受限设备(智能电视、CLI 工具)。
  4. 刷新令牌:长期有效的令牌,无需重新认证即可获取新访问令牌。

PKCE(授权码交换证明密钥)

PKCE(RFC 7636)防止授权码拦截攻击:

  1. 客户端生成随机 code_verifier(43-128 个字符,不保留 URI 字符)
  2. 客户端计算 code_challenge = BASE64URL(SHA256(code_verifier))
  3. 授权请求包含 code_challenge 和 code_challenge_method=S256
  4. 令牌请求包含原始 code_verifier
  5. 服务器验证 SHA256(code_verifier) 与存储的 code_challenge 匹配

令牌类型

  • 访问令牌:短期有效(5-60 分钟),bearer 或 DPoP 绑定
  • 刷新令牌:长期有效,一次性使用并轮换
  • ID 令牌(OIDC):包含用户身份声明的 JWT

实施步骤

步骤 1:带 PKCE 的授权码流

  1. 生成加密随机 code_verifier(最少 43 个字符)
  2. 使用 S256 方法计算 code_challenge
  3. 使用以下参数将用户重定向到授权端点:
    • response_type=code
    • client_id、redirect_uri、scope、state
    • code_challenge、code_challenge_method=S256
  4. 用户进行认证和授权
  5. 授权服务器使用授权码重定向
  6. 在令牌端点用 code + code_verifier 交换令牌
  7. 验证 state 参数与原始值匹配

步骤 2:范围设计

  • 定义细粒度范围:read:users、write:orders、admin:settings
  • 遵循最小权限:只请求所需的最少范围
  • 在资源服务器上实施范围验证
  • 记录范围层次结构和同意要求

步骤 3:令牌安全

  • 安全存储令牌(Web 应用使用 httpOnly Cookie,移动端使用密钥链)
  • 实施带轮换的令牌刷新(一次性使用刷新令牌)
  • 设置适当的过期时间:访问令牌 5-15 分钟,刷新令牌 8-24 小时
  • 启用 DPoP(持有证明)用于发送方约束令牌
  • 实施令牌撤销端点

步骤 4:客户端凭据流

  1. 注册服务客户端,包含 client_id 和 client_secret
  2. 请求令牌:POST /oauth/token,参数 grant_type=client_credentials
  3. 包含所需权限的 scope
  4. 安全存储 client_secret(保险库、环境变量,而非代码中)
  5. 为更高保障级别实施基于证书的客户端认证

步骤 5:安全加固

  • 对所有授权码流强制执行 PKCE
  • 使用精确的重定向 URI 匹配(无通配符)
  • 使用 state 参数实施 CSRF 保护
  • 启用刷新令牌轮换,并在检测到重用时撤销
  • 应用 RFC 9700 安全最佳实践
  • 阻止隐式授予和 ROPC(在 OAuth 2.1 中已移除)

安全控制

控制项NIST 800-53描述
访问控制AC-3基于令牌的访问执行
认证IA-5客户端凭据管理
会话管理SC-23令牌生命周期管理
审计AU-3记录所有令牌颁发和撤销
加密保护SC-13PKCE 和令牌签名

常见陷阱

  • 使用隐式授予(OAuth 2.1 中已移除)而非授权码 + PKCE
  • 将令牌存储在 localStorage(容易受 XSS 攻击)而非 httpOnly Cookie
  • 未验证 state 参数,使 CSRF 攻击成为可能
  • 使用通配符重定向 URI,允许开放重定向利用
  • 未实施刷新令牌轮换,导致令牌盗窃持续有效

验证

  • 带 PKCE 的授权码流成功完成
  • 在令牌端点验证了 PKCE code_challenge
  • state 参数防止了 CSRF
  • 访问令牌在配置的生命周期内过期
  • 刷新令牌轮换在每次使用时颁发新的刷新令牌
  • 令牌撤销使访问令牌和刷新令牌都失效
  • 客户端凭据流适用于服务间调用
  • 资源服务器正确执行范围
Skills enregistrées