跳到主要内容

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 账号登录。

1

从 Google Cloud 取得凭据

打开 console.cloud.google.com,进入或新建一个项目。转到 APIs & Services → Credentials,创建一个应用类型为 Web application 的 OAuth 2.0 Client ID。

2

在 PlayServ 中填入凭据

把 Client ID 和 Client Secret 复制到 PlayServ 中对应的字段。

字段说明
Client ID来自 Google Cloud 控制台的 OAuth 2.0 客户端标识符
Client Secret来自 Google Cloud 控制台的 OAuth 2.0 客户端密钥
Redirect URI由 PlayServ 生成 —— 只读
3

把 Redirect URI 加到 Google

复制 PlayServ 中显示的 Redirect URI,把它加进你 Google Cloud OAuth 应用的 Authorised redirect URIs 列表,然后在 Google Cloud 中保存。

4

测试并启用

点击 Test connection 确认凭据被接受,然后把这个提供方打开。


测试连接​

每个标准提供方在展开该行时,都会出现一个 Test connection 按钮。填完凭据后用它确认 PlayServ 能连通该提供方,再去启用。

提示

先测连接,再启用提供方。一个配置有误却已启用的提供方,会默默拒掉所有走这种方式的登录尝试。


用 Test Tools 做端到端测试​

PlayServ 内置了 Test Tools 页面,不用写一行代码就能对着你的真实后端跑一遍完整的认证流程。

从 SSO & Auth 页面 Player authentication 页头右上角的 Test sign-in 按钮进入,或直接访问 dashboard.playserv.com/test-tools。

Test Tools 页面 —— 等待探测的提供方卡片

1

取得你的 Public SDK key

使用 Test Tools 需要一个 Public SDK key(pk_...)。这个 key 只显示一次 —— 就在它于 PlayServ 面板中被创建的那一刻。

Save your token 对话框 —— Public SDK key 唯一一次现身的时刻

如果创建时没保存,就到 API Key Management 里生成一个新的。对话框一旦关闭,token 就取不回来了。

2

在 Test Tools 中填入这个 key

把你的 Public SDK key 粘贴到 Test Tools 页面顶部的 Public SDK key 字段。

这个 key 本身就带着 Project 和 Environment 信息 —— 不需要另外填 Project ID。工具会调用 GET /api/v1/auth/providers,并激活你 Project 中所有已启用且已配置的提供方卡片。

3

跑一遍认证流程

点击你想测试的那个提供方的卡片。每张卡片都会把完整的登录流程从头走到尾。

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。

4

核对结果

登录成功后,工具会显示签发出的 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 的情况。


下一步​