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。
各提供方
- Apple
- Epic
- Steam
通过 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 的认证提供方是两回事