OAuth 2.0 协议学习笔记

一、协议背景与解决的问题

在传统客户端-服务器身份验证模型中，客户端使用资源所有者凭据（如用户名密码）访问受限资源，存在以下问题：

• 安全风险：第三方需存储明文密码，服务器需支持密码认证（密码存在固有弱点）。
• 权限失控：第三方获得广泛访问权限，资源所有者无法限制访问范围或时长。
• 撤销困难：无法单独撤销对某一第三方的访问，需修改密码导致所有授权失效。
• 泄露风险：第三方泄露会导致用户密码及所有受保护数据暴露。

OAuth 2.0 通过引入授权层，分离客户端与资源所有者角色，使用访问令牌替代凭据，解决上述问题。

二、核心角色与职责

1. 资源所有者（Resource Owner）

   授予对受保护资源访问权限的实体（通常为最终用户）。

2. 资源服务器（Resource Server）

   托管受保护资源，验证访问令牌并响应请求。

3. 客户端（Client）

   代表资源所有者发起请求的应用程序（如移动App、Web服务）。

4. 授权服务器（Authorization Server）

   验证资源所有者身份后颁发访问令牌，可与资源服务器分离或合并。

三、抽象流程与步骤

OAuth 2.0 核心流程包含以下步骤：

1. 客户端请求授权

   直接或通过授权服务器间接向资源所有者请求授权。

2. 获取授权许可（Authorization Grant）

   资源所有者通过四种授权类型之一（或扩展类型）授予许可。

3. 请求访问令牌

   客户端携带授权许可向授权服务器验证身份并申请令牌。

4. 颁发访问令牌

   授权服务器验证后发放令牌（可能包含刷新令牌）。

5. 访问受保护资源

   客户端携带令牌向资源服务器发起请求。

6. 验证令牌并响应

   资源服务器验证令牌有效性后提供服务。

四、授权类型（Authorization Grant）

规范定义四种标准授权类型，适用于不同场景：

• 流程：

  客户端引导用户至授权服务器，后者返回授权码至客户端。

  客户端用授权码换取访问令牌。

• 优势：

  资源所有者凭据不共享给客户端。

  支持客户端身份验证，提升安全性。

• 适用场景：Web应用、移动应用等需高安全性的场景。

• 流程：

  授权服务器直接返回访问令牌（无中间授权码）。

• 特点：

  简化流程，减少往返次数。

  令牌可能通过URI片段暴露，存在安全隐患。

• 适用场景：浏览器内脚本应用（如单页应用）。

• 流程：

  客户端直接使用用户名密码换取令牌。

• 限制：

  仅限高度信任场景（如设备操作系统）。

  需避免长期存储凭据。

• 适用场景：遗留系统或高特权应用。

• 流程：

  客户端用自身凭据（如API密钥）换取令牌。

• 特点：

  适用于客户端代表自身访问资源。

• 适用场景：后台服务间通信。

五、令牌机制

• 定义：表示授权的字符串，通常对客户端不透明。
• 属性：

  限定访问范围（Scope）和有效期。

  格式由资源服务器决定（如JWT、不透明令牌）。

• 安全要求：

  传输和存储需保密，仅通过TLS传输。

  隐式流程中需防范URI暴露风险。

• 定义：用于获取新访问令牌的凭据，仅限授权服务器使用。
• 流程：

  客户端携带刷新令牌向授权服务器申请新令牌。

  授权服务器验证后颁发新令牌（可选更新刷新令牌）。

• 安全要求：

  绑定客户端身份，防止滥用。

  支持轮换机制（如每次刷新颁发新令牌）。

六、安全考虑

• 要求：

  机密客户端（如Web服务）必须验证身份。

  公开客户端（如浏览器应用）需通过重定向URI等替代方案验证。

• 风险：客户端凭据泄露可能导致模拟攻击。

• 访问令牌：

  最小权限原则：客户端应请求最小必要范围。

  防止猜测攻击：授权服务器需确保令牌不可预测。

• 刷新令牌：

  绑定客户端身份，支持轮换以检测泄露。

  传输和存储需保密，仅通过TLS传输。

• 措施：

  强制资源所有者明确授权（如交互式确认）。

  提供授权详情（客户端信息、范围、有效期）。

  防止自动处理重复请求（避免模拟攻击）。

七、协议特点与演进

• 不兼容性：OAuth 2.0 与 OAuth 1.0 不兼容，但可共存。
• 扩展性：支持自定义授权类型和令牌格式（如JWT）。
• 简化设计：分离授权与资源访问，提升灵活性和安全性。

OAuth 2.0 通过角色分离、令牌机制和多样化授权类型，为现代应用提供了安全、灵活的授权框架，适用于Web、移动和设备等多种场景。