授权码模式详解

授权码模式（Authorization Code Grant）是 OAuth 2.0 中最完整、最安全的授权流程，适用于有服务端后端的 Web 应用。该模式通过前端通道获取临时授权码，再通过后端安全通道交换访问令牌，确保令牌不会暴露在用户代理（浏览器）中。

授权码流程

授权码模式涉及四个参与方：资源所有者（用户）、用户代理（浏览器）、客户端（Web 应用后端）、授权服务器。完整流程包含以下步骤：

1. 授权请求：客户端将资源所有者重定向到授权服务器的 /authorize 端点，附带客户端标识、重定向 URI、请求的 scope 和 response_type=code。
2. 用户认证与授权：资源所有者在授权服务器上登录，并确认是否授权客户端访问其资源。
3. 授权码下发：授权服务器通过重定向将授权码（authorization code）返回给客户端的回调地址。
4. 令牌交换：客户端使用授权码，在后端通过 HTTPS 向授权服务器的 /token 端点发起 POST 请求，交换访问令牌和可选的刷新令牌。
5. 受保护资源访问：客户端使用访问令牌向资源服务器请求用户资源。

授权码请求与响应

授权码请求分为两个阶段：授权请求（前端通道）和令牌请求（后端通道）。

授权请求（/authorize）

客户端将用户重定向到授权服务器的授权端点，请求参数如下：

// 授权请求示例（浏览器重定向）
GET /authorize?
  response_type=code
  &client_id=web_app_001
  &redirect_uri=https://client.example.com/callback
  &scope=openid%20profile%20email
  &state=xyzABC123
  &nonce=abcDEF456
HTTP/1.1
Host: auth.example.com

授权码响应

用户授权后，授权服务器将用户重定向回客户端的回调地址，并在 URL 查询参数中附带授权码：

// 授权码响应示例（302 重定向）
HTTP/1.1 302 Found
Location: https://client.example.com/callback?
  code=authorization_code_abc123
  &state=xyzABC123

令牌请求（/token）

客户端在后端使用授权码向令牌端点发起 POST 请求，交换访问令牌：

// 令牌请求示例（后端 POST）
POST /token HTTP/1.1
Host: auth.example.com
Content-Type: application/x-www-form-urlencoded
Authorization: Basic base64(web_app_001:client_secret_xyz)

grant_type=authorization_code
&code=authorization_code_abc123
&redirect_uri=https://client.example.com/callback

授权码交换令牌

授权服务器验证授权码和客户端身份后，返回令牌响应：

// 令牌响应示例
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8

{
  "access_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...",
  "token_type": "Bearer",
  "expires_in": 3600,
  "refresh_token": "refresh_token_abc789",
  "scope": "openid profile email",
  "id_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9..."
}

安全考虑

授权码模式虽然是最安全的 OAuth 2.0 流程，但仍需注意以下安全要点：

授权码模式安全清单

• 始终使用 HTTPS：所有通信通道必须加密，防止中间人攻击。
• 验证 state 参数：防止 CSRF 攻击，确保回调来自同一用户会话。
• 严格验证 redirect_uri：授权服务器必须使用精确匹配，不允许通配符。
• 授权码一次性使用：授权码使用后立即失效，重复使用应被拒绝并告警。
• 短授权码有效期：建议 1-5 分钟，最长不超过 10 分钟。
• 客户端认证：机密客户端必须使用 client_secret 或私钥 JWT 进行认证。
• 使用 PKCE：即使对于有后端的 Web 应用，PKCE 也能提供额外保护层。
• 最小权限原则：只请求应用实际需要的 scope，避免过度授权。