OAuth 2.0 流程

OAuth 2.0 是一种委托授权框架。它允许用户向第三方应用授予对另一项服务上资源的有限访问权限，而无需共享密码。

• 它关注的是授权（应用可以执行哪些操作），而不是身份验证（用户是谁）。
• 应用会收到一个具有范围限制的 access_token，而不会收到用户凭据。

防御人员必须牢记：OAuth 本身无法证明身份。将访问令牌当作登录证明，是 OIDC 所要解决的典型错误。

每个 OAuth 流程都涉及四种角色。正确厘清这些角色对于威胁建模至关重要。

• 资源所有者 — 拥有数据的用户。
• 客户端 — 请求访问权限的应用。
• 授权服务器（AS） — 在用户同意后签发令牌。
• 资源服务器（RS） — 保存受保护数据并验证令牌的应用程序接口。

这些角色之间存在信任边界。客户端遭到入侵，或 AS 的权限过于宽松，都会破坏整个信任链。

授权码授权模式是网页和移动应用推荐使用的流程。它将面向用户的重定向与机密的令牌交换分开。

• 用户会被重定向到 AS，以进行身份验证并表示同意。
• AS 会将短期有效的 code 返回到已注册的重定向 URI。
• 客户端通过后端通道在服务器端用授权码交换令牌。

由于令牌通过后端通道获取，因此不会出现在浏览器地址栏或历史记录中。

PKCE（RFC 7636）强化了授权码授权模式，现在建议所有客户端使用，包括机密客户端。

• 客户端生成随机的 code_verifier，并将其哈希值作为 code_challenge 发送。
• 交换令牌时，客户端必须提供原始验证器。

这会将授权码绑定到最初的请求方，从而阻止截获授权码的攻击者兑换令牌。

客户端凭据授权模式适用于机器到机器的访问，此时不涉及用户（例如后端服务调用应用程序接口）。

• 客户端使用自身凭据进行身份验证，并接收访问令牌。
• 通常不存在用户同意，也不存在刷新令牌。

请严格限制这些令牌的范围，并轮换客户端密钥。切勿使用此流程冒充最终用户。

OAuth 会签发两种主要的令牌类型，其生命周期和处理规则大不相同。

• 访问令牌 — 生命周期短，每次调用时都发送给资源服务器。请将其视为持有者凭据。
• 刷新令牌 — 生命周期长，仅用于向 AS 请求新的访问令牌。

刷新令牌价值很高。请安全存储，将其绑定到客户端，并支持撤销。

大多数 OAuth 访问令牌都是持有者令牌：任何持有令牌的人都可以使用它，就像使用现金一样。

• 始终通过 TLS 传输；切勿放在 URL 中，否则会泄露到日志和引荐来源中。
• 通过 Authorization 标头发送。
• 对于高风险 API，请考虑使用发送方约束令牌（DPoP、mTLS）。

旧版隐式授权会直接将令牌返回到重定向 URI 片段中。现在，OAuth 2.0 安全 BCP 已不再建议使用它，并且 OAuth 2.1 已将其移除。

• 令牌会通过浏览器历史记录、引荐来源标头和日志泄露。
• 由于没有后端通道，客户端身份验证更弱。

对于 SPA，请改用 PKCE 授权码流程。

state 参数可以保护重定向步骤免受 CSRF 攻击。客户端生成一个随机值，将其存储在会话中，并在回调时进行验证。

• 如果返回的 state 不匹配，请拒绝该响应。
• 这样可以防止攻击者将自己的授权码注入受害者的会话。

作用域表示令牌授予的访问权限粒度。请在每个步骤都应用最小权限原则。

• 只请求功能所需的作用域（read:profile，而不是 admin）。
• 资源服务器必须在每个端点上执行作用域检查，不能只信任有效令牌。

权限同意范围过大是现实中常见的风险：用户会批准那些请求远超实际所需权限的应用。

大多数 OAuth 事故源于配置，而不是协议本身。

• 开放重定向/宽松的 redirect_uri 匹配会让攻击者窃取授权码。
• 缺少 state 或 PKCE 会导致 CSRF 和授权码注入。
• 访问令牌长期有效且没有撤销机制。
• 将访问令牌当作身份验证断言。

请注册精确的重定向 URI，并严格验证它们。

请选择下面场景应使用的正确现代流程。

要点：

• OAuth 2.0 是委托授权，而不是身份验证。
• 四种角色：资源所有者、客户端、授权服务器和资源服务器。
• 授权码 + PKCE 是 Web、移动应用和 SPA 的默认方案。
• 客户端凭据用于机器间访问。
• 使用 state、严格的重定向 URI 匹配、短期有效的访问令牌，并在各处使用 TLS 来进行保护。
• 隐式授权和密码授权已弃用。