游戏中的细粒度OAuth授权：在后端实现作用域级权限

每个独立开发者都知道玩家在权限屏幕前犹豫不决的时刻。你的游戏请求访问他们的好友列表、电子邮件、购买历史——然后他们点击“拒绝”。这种犹豫并非不理性；这是对一种感觉像侵犯隐私的全有或全无选择的理性回应。这种摩擦直接影响你的转化率和玩家信任。

Cloudflare 最近对其 OAuth 系统的更新引入了一个强大的解决方案：基于任务的细粒度授权。与其强迫玩家批准你的游戏可能需要的所有权限，你现在可以将特定作用域标记为可选。这让玩家只授予他们当前任务所接受的权限，这是游戏认证流程的一次范式转变。

游戏中全有或全无权限的问题

传统的 OAuth 授权是二元的。当你的游戏请求 profile.read、friends.list 和 inventory.write 等作用域时，玩家会看到一个“批准”按钮。如果他们不愿意向第三方工具授予 inventory.write 访问权限，他们唯一的选择就是拒绝整个请求。

这给游戏开发者带来了几个具体问题：

1. 高放弃率： 有安全意识的玩家会直接离开你的游戏，而不是授予广泛的访问权限。
2. 过度授权： 为了避免玩家流失，开发者通常会请求比实际需要更少的作用域，从而削弱功能。
3. 信任侵蚀： 玩家会逐渐将你游戏的登录流程与失去控制联系起来，损害长期留存。

核心问题在于，玩家授权一个配套应用进行基本统计跟踪时，不应该被迫同时授予其修改装备或花费游戏内货币的能力。

基于任务的 OAuth 授权如何工作

新模型允许开发者配置包含两种作用域的 OAuth 客户端：必需和可选。当玩家发起授权流程时，他们会看到请求的完整权限列表，但可以取消选择任何标记为可选的权限。

关键的技术细节在于，这种评估发生在每次授权请求时，而不是针对客户端配置的整个作用域集。这对游戏至关重要，因为不同的功能需要不同的权限。

考虑一个包含以下作用域的游戏后端：

• player.profile.read（基本登录必需）
• player.inventory.read（可选，用于配套应用）
• player.inventory.write（可选，用于装备管理）
• match.history.read（可选，用于统计跟踪）

使用简单统计跟踪工具的玩家只会请求 player.profile.read 和 match.history.read。授权屏幕会同时显示两者，但由于 match.history.read 是可选的，玩家可以取消选择它，并仍然使用受限令牌继续。inventory 作用域甚至不会出现，因为它们不是针对该特定流程请求的。

在游戏后端实现细粒度授权

让我们通过一个实际实现来了解。我们将使用通用的 OAuth 2.0 流程，你可以根据自己的后端进行适配，无论是自定义解决方案还是像 horizOn 这样的服务。

步骤 1：使用可选作用域配置 OAuth 客户端

在向授权服务器（如 Cloudflare 或你自己的服务器）注册 OAuth 应用时，你需要定义哪些作用域是必需的，哪些是可选的。以下是一个概念性配置：

{
  "client_id": "your_game_client_id",
  "scopes": {
    "required": ["player.profile.read"],
    "optional": [
      "player.inventory.read",
      "player.inventory.write",
      "match.history.read",
      "match.history.write"
    ]
  },
  "redirect_uris": ["https://yourgame.com/callback"]
}

这告诉授权服务器：“当此客户端请求权限时，如果请求了 player.profile.read，则必须始终授予，但其他权限由用户决定。”

步骤 2：处理授权请求和响应

你的游戏客户端启动 OAuth 流程，请求当前任务所需的作用域。关键部分出现在玩家批准或修改请求之后。你必须检查响应中授予的作用域，而不是假设你获得了所要求的一切。

以下是一个用于处理回调的简化伪代码示例：

// After the player is redirected back to your game with an authorization code
async function handleOAuthCallback(authorizationCode) {
  // Exchange the code for tokens
  const tokenResponse = await fetch('/oauth/token', {
    method: 'POST',
    body: JSON.stringify({
      code: authorizationCode,
      client_id: CLIENT_ID,
      client_secret: CLIENT_SECRET,
      redirect_uri: REDIRECT_URI,
      grant_type: 'authorization_code'
    })
  });
  
  const tokens = await tokenResponse.json();
  
  // CRITICAL: Check the granted scopes
  const grantedScopes = tokens.scope.split(' ');
  
  // Now, adapt your game's functionality based on what was actually granted
  if (grantedScopes.includes('player.inventory.read')) {
    enableInventoryViewer();
  } else {
    disableInventoryViewer();
    showLimitedFunctionalityMessage();
  }
  
  if (grantedScopes.includes('match.history.read')) {
    enableStatTracking();
  } else {
    disableStatTracking();
  }
  
  // Store the token with its specific scope set
  storeUserSession({
    accessToken: tokens.access_token,
    scopes: grantedScopes,
    // ... other token data
  });
}

步骤 3：为部分授权设计游戏 UI

用户体验并不仅限于 OAuth 屏幕。你的游戏需要优雅地处理权限比理想情况更少的令牌。

UI/UX 最佳实践：

• 保持透明： 如果某个功能因缺少权限而被禁用，请告诉玩家原因以及他们之后如何授予访问权限。
• 提供升级路径： 在设置菜单中包含一个“授予更多权限”按钮，用于重新启动包含可选作用域的 OAuth 流程。
• 优雅降级： 缺少 match.history.write 的统计跟踪应用仍应显示统计数据，只是无法保存自定义报告。

游戏 OAuth 授权的 5 个最佳实践

1. 请求最小可行作用域： 对于每个功能，确定所需的最小绝对作用域。其他所有内容都设为可选。排行榜查看器只需要 match.history.read，而不是 match.history.write。

2. 情境化权限请求： 不要在登录时请求所有可能的作用域。仅在玩家实际尝试使用装备编辑器时才请求 inventory.write。这通过情境建立信任。

3. 按会话存储作用域集： 玩家可能向不同的配套应用授予不同的作用域。你的后端必须将每个访问令牌与其特定的已授予作用域关联，并在 API 级别强制执行。

4. 审计你的作用域定义： 定期检查你的作用域列表。是否有在开发早期定义但不再使用的作用域？弃用它们。更小、更干净的作用域列表不会让人望而生畏。

5. 在每个端点上实现作用域验证： 你的 API 必须检查传入的访问令牌是否具有请求资源所需的作用域。这对于安全性是不容商量的。仅具有 player.profile.read 的令牌必须被阻止调用 /api/inventory。

构建整个流程——客户端配置、动态授权屏幕、作用域感知的令牌处理和后端验证——是一项艰巨的任务。它需要与授权服务器深度集成，并仔细管理状态。这就是像 horizOn 这样的后端服务可以节省数周开发时间的地方。horizOn 的认证系统正是考虑到了这些现代细粒度授权模式而构建的，提供预配置的端点和 SDK，可立即处理作用域验证和部分授权。

安全影响：为什么这对游戏后端很重要

细粒度授权不仅仅是 UX 的改进；它是一种安全架构模式。通过限制受损令牌的爆炸半径，你可以保护玩家和游戏经济。

如果恶意第三方应用只成功让玩家授予 match.history.read，它就无法触及他们的库存或货币。这种最小权限原则是安全系统设计的基础。要深入了解如何构建能够抵御入侵的后端，请参阅我们对 Star Citizen 数据泄露事件 的分析。

结论：通过控制建立信任

从全有或全无到基于任务的 OAuth 授权的转变对玩家和开发者来说都是双赢。玩家获得了他们想要的控制权，从而带来更高的授权率和信任度。开发者获得更准确的权限集，从而实现更丰富的集成，而不必担心吓跑用户。

首先审计你当前的 OAuth 实现。确定哪些作用域对核心功能真正必不可少，哪些可以设为可选。实现服务器端逻辑以处理部分授权，并更新游戏 UI，向玩家清楚传达每个权限的作用。

通过给玩家选择权，你并没有限制你的游戏——你正在建立信任的基础，支持长期参与，并为第三方工具和配套应用构建更健康的生态系统。

---

来源：从全有或全无到基于任务的 OAuth 授权