本页尚未翻译，当前显示英文版本。
SSO & Auth
最后更新：2026 年 7 月 16 日
Players 一节中的 SSO & Auth 标签页，是你配置 Player 可用哪些认证提供方登录 Project 的地方。只有已启用的提供方会被接受 —— 通过已停用提供方发起的登录尝试一律被拒。
打开方式：在 Project 侧边栏中点击 Players → SSO & Auth。
概览
页面列出所有可用的认证提供方。每个提供方都显示当前状态，展开后还会显示它的配置字段。
页头显示当前已启用的提供方数量占可用总数的比例 —— 例如 2 of 6 providers enabled。
提供方分为两类：
标准提供方要求你从该提供方的开发者控制台取得凭据，PlayServ 用它们在后端校验认证。Google、Facebook 和 Apple 走 OAuth 2.0；Epic 走 Epic Online Services；Steam 走 OpenID。
各提供方
通过 OAuth 2.0 使用 Google 账号登录。
从 Google Cloud 取得凭据
打开 console.cloud.google.com，进入或新建一个项目。转到 APIs & Services → Credentials， 创建一个应用类型为 Web application 的 OAuth 2.0 Client ID。
在 PlayServ 中填入凭据
把 Client ID 和 Client Secret 复制到 PlayServ 中对应的字段。
| 字段 | 说明 |
|---|---|
| Client ID | 来自 Google Cloud 控制台的 OAuth 2.0 客户端标识符 |
| Client Secret | 来自 Google Cloud 控制台的 OAuth 2.0 客户端密钥 |
| Redirect URI | 由 PlayServ 生成 —— 只读 |
把 Redirect URI 加到 Google
复制 PlayServ 中显示的 Redirect URI，把它加进你 Google Cloud OAuth 应用的 Authorised redirect URIs 列表，然后在 Google Cloud 中保存。
测试并启用
点击 Test connection 确认凭据被接受，然后把这个提供方打开。
使用 Facebook 和 Meta 账号登录。
从 Meta for Developers 取得凭据
打开 developers.facebook.com，进入或新建一个 app。在 Settings → Basic 中复制 App ID 和 App Secret。
在 PlayServ 中填入凭据
把 App ID 和 App Secret 粘贴到对应字段。
| 字段 | 说明 |
|---|---|
| App ID | 15 位数字 ID |
| App Secret | 32 位十六进制字符串 |
| Redirect URI | 由 PlayServ 生成 —— 只读 |
把 Redirect URI 加到 Meta for Developers
复制 PlayServ 中显示的 Redirect URI，把它加进 Facebook Login → Settings 下的 Valid OAuth Redirect URIs 列表，然后在 Meta for Developers 中保存。
测试并启用
点击 Test connection 确认无误，然后把这个提供方打开。
Sign in with Apple。对于提供了任何第三方社交登录的 iOS 应用，App Store 第 4.8 条准则要求必须支持它。
警告
如果你的 iOS 应用包含任何第三方社交登录（Google、Facebook 等），按 App Store Review Guidelines 4.8，Apple 登录是强制的。缺了它会被拒审。
在 Apple Developer 中创建 Services ID
打开 developer.apple.com，找到你应用的标识符。启用 Sign in with Apple，然后为基于网页的 OAuth 流程创建一个 Services ID。
生成私钥
在 Keys 下创建一个启用了 Sign in with Apple 的新密钥。下载 .p8 密钥文件，并记下 Key ID 和你的 Team ID。
在 PlayServ 中填入凭据
从 developer.apple.com → Certificates, Identifiers & Profiles 取得凭据，然后填齐所有必填字段。
| 字段 | 说明 |
|---|---|
| Services ID | 注册在你 App ID 之下的一个 “Services ID”，用作 OAuth 的 client_id。 |
| Team ID | 在 Apple Developer 门户右上角可见。 |
| Key ID | 在 Apple Developer 中创建 Sign in with Apple 的 “Key” 时显示。 |
| Private key (.p8 PEM) | 粘贴 Apple 给你的 .p8 文件内容。P-256 ECDSA。 |
| Redirect URI | 由 PlayServ 生成 —— 只读 |
把 Redirect URI 加到 Apple Developer
复制 PlayServ 中显示的 Redirect URI，把它加进 Sign in with Apple → Configure 下你那个 Services ID 的 Return URLs，然后在 Apple Developer 中保存。
测试并启用
点击 Test connection 确认无误，然后把这个提供方打开。
使用 Epic Games 账号登录。
备注
只有当你要在 Epic Games Store 发行，或面向持有 Epic 账号的玩家时，才启用这个提供方。它默认列为 disabled。
从 Epic Developer Portal 取得凭据
打开 dev.epicgames.com，进入你的产品。在 Product Settings → Clients 下复制 Client ID 和 Client Secret。
在 PlayServ 中填入凭据
把 Client ID、Client Secret 和 Deployment ID 粘贴到对应字段。
| 字段 | 说明 |
|---|---|
| Client ID | EOS 的客户端凭据。在 Epic 开发者门户的 Product → Clients 下签发。 |
| Client Secret | EOS 的客户端凭据。在 Epic 开发者门户的 Product → Clients 下签发。 |
| Deployment ID | 用于认证的 EOS deployment。Product ID 和 Sandbox ID 会在服务端由它推导出来 —— 不必另行填写。 |
| Redirect URI | 由 PlayServ 生成 —— 只读 |
把 Redirect URI 加到 Epic Developer Portal
复制 PlayServ 中显示的 Redirect URI，把它加进 Product Settings → Clients 下该 client 的 Redirect URL(s)，然后在 Epic Developer Portal 中保存。
启用该提供方
把这个提供方打开。Epic 不需要连接测试这一步。
使用 Steam 账号登录。Steam 走的是 OpenID 而非 OAuth，因此要向 Steam 注册的不是 redirect URI，而是一个 Return URL。
申请 Steam Web API Key
打开 steamcommunity.com/dev，为你的账号注册一个 Steam Web API Key。同时从 Steamworks 记下你游戏的 App ID。
在 PlayServ 中填入凭据
把 Steam Web API Key 和 Steam App ID 粘贴到对应字段。
| 字段 | 说明 |
|---|---|
| Steam Web API Key | 来自 steamcommunity.com/dev 的 32 位大写十六进制密钥 |
| Steam App ID | 来自 Steamworks 的数字 App ID（例如 480） |
| Return URL | 由 PlayServ 生成 —— 只读 |
把 Return URL 加到 Steamworks
复制 PlayServ 中显示的 Return URL，在 Steamworks 中把它注册为你应用的 OpenID 回调 endpoint，然后保存。
测试并启用
点击 Test connection 确认密钥和 App ID 被接受，然后把这个提供方打开。
测试连接
每个标准提供方在展开该行时，都会出现一个 Test connection 按钮。填完凭据后用它确认 PlayServ 能连通该提供方，再去启用。
提示
先测连接，再启用提供方。一个配置有误却已启用的提供方，会默默拒掉所有走这种方式的登录尝试。
用 Test Tools 做端到端测试
PlayServ 内置了 Test Tools 页面，不用写一行代码就能对着你的真实后端跑一遍完 整的认证流程。
从 SSO & Auth 页面 Player authentication 页头右上角的 Test sign-in 按钮进入，或直接访问 dashboard.playserv.com/test-tools。
取得你的 Public SDK key
使用 Test Tools 需要一个 Public SDK key（pk_...）。这个 key 只显示一次 —— 就在它于 PlayServ 面板中被创建的那一刻。
如果创建时没保存，就到 API Key Management 里生成一个新的。对话框一旦关闭，token 就取不回来了。
在 Test Tools 中填入这个 key
把你的 Public SDK key 粘贴到 Test Tools 页面顶部的 Public SDK key 字段。
这个 key 本身就带着 Project 和 Environment 信息 —— 不需要另外填 Project ID。工具会调用 GET /api/v1/auth/providers，并激活你 Project 中所有已启用且已配置的提供方卡片。
跑一遍认证流程
点击你想测试的那个提供方的卡片。每张卡片都会把完整的登录流程从头走到尾。
Google SSO 打开 Google 授权页 → 回调 → 返回 player_id 和 session_token。
Apple Sign-in 打开 Apple JS SDK 弹窗 → /apple/verify → 返回 player_id 和 session_token。
Epic Online Services 走 Epic 的 /start → 回调 → 返回 player_id 和 session_token。
核对结果
登录成功后，工具会显示签发出的 player_id 和 session_token。这些是真实凭据 —— 如果该 Player 账号此前不存在，它就会在你的 Project 中被创建出来。
备注
Facebook SSO 在 Test Tools 中标为 Coming Soon —— 该提供方的测试环境尚未就绪。
账号的绑定与合并
同一个 Player 可以在一个账号上绑定多个提供方 —— 比如一个 guest 后来用 Google 登录，或者一位 Player 在 Epic 之外又加了 Steam。Player 连接过的每个提供方都会显示在他档案的 Linked accounts 中，运营人员也可以在那里 Unlink。
有两条规则让绑定关系不含糊：
- 每个提供方只能 绑一个账号。 Player 不能再绑第二个同一提供方的账号 —— 在解绑已有的那个之前，尝试会被拒（
provider_already_linked）。解绑一个本就没绑定的提供方，同样是一次无效果的拒绝（provider_not_linked）。 - 合并会显式解决冲突。 当两个已有账号需要合成一个时（Player 分别用两个提供方登录过），平台会去做合并，而不是默默挑一个赢家。两个账号之间冲突的提供方会以
merge_provider_conflict暴露出来，会在保留字段上撞车的合并则以reserved_field_on_player_merge暴露 —— 因此合并绝不会悄悄丢掉数据。
备注
对于 owned 的数据，合并遵循各 Entity 的 on_player_merge 策略，删除 Player 则遵循它的 on_player_delete 策略 —— 见 Schema Object Reference → Entity 设置。
启用与停用提供方
每个提供方所在行的右侧都有一个开关，各提供方彼此独立地启用或停用。
- 关掉某个提供方后，它会立即停止接受登录。此前通过它认证的 Player，在重新启用之前都无法再登录。
- 打开某个提供方后，只要凭据有效、连接已验证，它就会作为一种登录方式可用。
即将推出
以下提供方已列在 SSO & Auth 标签页中，但尚不可用：
PlayServ Webhook （PlayServ 原生） —— 由你的认证服务器调用 PlayServ。适用于你已经有自己的登录界面，想把 token 签发这件事交给 PlayServ 的情况。
PlayServ Auth Token （PlayServ 原生） —— 由 SDK 传入一个已签名的 token。适用于你在服务端签发 JWT，再直接把它传进 SDK 的情况。
下一步
- User Login & Authentication —— Player 通过某个提供方登录之后，SDK 如何使用
UserToken - API Key Management —— SDK 自身所用的 Project 级凭据，与 Player 的认证提供方是两回事
更新于 2026年7月16日