Pular para o conteúdo principal

SSO & Auth

Última atualização: 16 de julho de 2026

A aba SSO & Auth, na seção Players, é onde você configura quais provedores de autenticação os Players podem usar para entrar no seu Project. Só provedores habilitados são aceitos — qualquer tentativa de login por um provedor desabilitado será rejeitada.

Para abrir: vá em Players → SSO & Auth na barra lateral do Project.

Visão geral​

A página lista todos os provedores de autenticação disponíveis. Cada provedor mostra o status atual e, quando expandido, os campos de configuração.

O cabeçalho exibe quantos provedores estão habilitados do total disponível — por exemplo, 2 of 6 providers enabled.

Os provedores se dividem em duas categorias:

Provedores padrão exigem que você forneça credenciais do console de desenvolvedor do provedor. O PlayServ as usa para validar a autenticação no backend. Google, Facebook e Apple entram por OAuth 2.0; Epic entra por Epic Online Services; Steam entra por OpenID.

Provedores​

Login com contas Google via OAuth 2.0.

1

Obtenha as credenciais no Google Cloud

Vá em console.cloud.google.com e abra ou crie um projeto. Navegue até APIs & Services → Credentials e crie um OAuth 2.0 Client ID com tipo de aplicação Web application.

2

Informe as credenciais no PlayServ

Copie o Client ID e o Client Secret para os campos correspondentes no PlayServ.

CampoDescrição
Client IDIdentificador de client OAuth 2.0 do console do Google Cloud
Client SecretSegredo de client OAuth 2.0 do console do Google Cloud
Redirect URIGerado pelo PlayServ — somente leitura
3

Adicione o Redirect URI no Google

Copie o Redirect URI exibido no PlayServ e adicione-o à lista de Authorised redirect URIs no seu app OAuth do Google Cloud, depois salve as mudanças lá.

4

Teste e habilite

Clique em Test connection para verificar se as credenciais são aceitas, e então ligue o provedor.

Testando uma conexão​

Cada provedor padrão tem um botão Test connection que aparece quando a linha do provedor é expandida. Use-o depois de informar as credenciais, para verificar se o PlayServ consegue alcançar o provedor antes de habilitá-lo.

dica

Teste a conexão antes de habilitar o provedor. Um provedor mal configurado que esteja habilitado vai rejeitar silenciosamente todas as tentativas de login por aquele método.

Teste ponta a ponta com as Test Tools​

O PlayServ inclui uma página Test Tools embutida, que deixa você rodar um fluxo completo de autenticação contra o seu backend real sem escrever código nenhum.

Abra-a pelo botão Test sign-in, no canto superior direito do cabeçalho Player authentication da página SSO & Auth, ou vá direto para dashboard.playserv.com/test-tools.

Página Test Tools — cards de provedores aguardando a sondagem

1

Obtenha a sua Public SDK key

Você precisa de uma Public SDK key (pk_...) para usar as Test Tools. Essa key é exibida uma única vez — no momento em que é criada no dashboard do PlayServ.

Diálogo Save your token — o único momento em que a Public SDK key é exibida

Se você não a salvou na criação, gere uma nova em API Key Management. Depois de fechado, o token não pode ser recuperado.

2

Informe a key nas Test Tools

Cole a sua Public SDK key no campo Public SDK key, no topo da página Test Tools.

A key já carrega o Project e o Environment — não é preciso informar um ID de Project à parte. A ferramenta chama GET /api/v1/auth/providers e ativa os cards de todos os provedores que estiverem habilitados e configurados no seu Project.

3

Rode o fluxo de autenticação

Clique no card do provedor que você quer testar. Cada card conduz o fluxo de login inteiro, de ponta a ponta.

Google SSO abre a tela de consentimento do Google → callback → retorna player_id e session_token.

Apple Sign-in abre o popup do Apple JS SDK → /apple/verify → retorna player_id e session_token.

Epic Online Services conduz o /start da Epic → callback → retorna player_id e session_token.

4

Verifique o resultado

Depois de um login bem-sucedido, a ferramenta exibe o player_id e o session_token emitidos. Essas são credenciais reais — a conta de Player é criada no seu Project se ainda não existia.

observação

O SSO do Facebook aparece nas Test Tools como Coming Soon — o ambiente de teste ainda não está disponível para esse provedor.

Vinculando e mesclando contas​

Um mesmo Player pode ter vários provedores vinculados a uma conta — por exemplo um guest que depois entra com Google, ou um Player que adiciona Steam ao lado da Epic. Cada provedor que um Player conecta aparece no perfil dele em Linked accounts, onde um operador também pode fazer Unlink.

Duas regras mantêm a vinculação sem ambiguidade:

  • Uma conta por provedor. Um Player não pode vincular uma segunda conta do mesmo provedor — a tentativa é recusada (provider_already_linked) até que a existente seja desvinculada. Desvincular um provedor que não está vinculado é, do mesmo modo, uma recusa sem efeito (provider_not_linked).
  • A mesclagem resolve colisões explicitamente. Quando duas contas existentes precisam virar uma (um Player que entrou separadamente com dois provedores), a plataforma as mescla em vez de escolher uma vencedora em silêncio. Provedores conflitantes entre as duas contas aparecem como merge_provider_conflict, e uma mesclagem que colidiria em um campo reservado aparece como reserved_field_on_player_merge — de modo que uma mesclagem nunca descarta dados às escondidas.
observação

Para dados owned, uma mesclagem segue a política on_player_merge de cada Entity, e excluir um Player segue a política on_player_delete — veja Schema Object Reference → Configurações de Entity.

Habilitando e desabilitando provedores​

Cada provedor tem um toggle do lado direito da sua linha. Provedores são habilitados ou desabilitados de forma independente.

  • Desligar um provedor faz com que ele pare imediatamente de aceitar logins. Players que antes se autenticavam por ele não conseguirão entrar de novo até que seja reabilitado.
  • Ligar um provedor o torna disponível como método de login assim que as credenciais forem válidas e a conexão estiver verificada.

Em breve​

Os provedores a seguir estão listados na aba SSO & Auth, mas ainda não estão disponíveis:

PlayServ Webhook (nativo do PlayServ) — o seu servidor de auth chama o PlayServ. Use quando você já tem a sua própria UI de login e quer delegar a emissão de tokens ao PlayServ.

PlayServ Auth Token (nativo do PlayServ) — o SDK passa um token assinado. Use quando você emite JWTs no servidor e os passa direto para o SDK.

Próximos passos​

  • User Login & Authentication — como o SDK consome o UserToken depois que um Player entra por um provedor
  • API Key Management — credenciais no nível do Project usadas pelo próprio SDK, separadas dos provedores de auth do Player
Etiquetas:
Última atualização em