2026: como testar login e recuperação após mudar o nome de usuário da Conta do Google

A autenticação funciona, mas o usuário aparece como uma conta nova depois de mudar o endereço da Conta do Google.

Conclusão: use o sub do ID token como identificador estável e trate o e-mail como um atributo que pode mudar. Valide separadamente a autorização existente, a nova autorização após revogação e o recebimento das mensagens de recuperação do seu produto. Um e-mail alterado em um fixture não comprova uma mudança real de identidade Google.

Este guia é para você que mantém a associação de contas com Sign in with Google e precisa conferir se a aplicação não usa o endereço como chave permanente.
Também atende quem prepara testes de QA e aceite de versão para continuidade de sessão, contas duplicadas e recuperação.
Se você responde por segurança ou recuperação de contas, use os cenários para conferir a validação do endereço e a titularidade da conta.

Última atualização: 25 de outubro de 2026. As informações sobre disponibilidade e comportamento foram conferidas no artigo do Google sobre a mudança do nome de usuário da Conta do Google em aplicativos, na referência oficial do OpenID Connect e nas páginas de ajuda da Conta do Google sobre nomes de usuário e sobre a mudança de endereço. Confira novamente essas fontes antes de liberar a versão: elegibilidade, disponibilidade e respostas observadas podem mudar.

Teste de mudança do nome da Conta do Google para desenvolvedores: identidade versus e-mail

O ponto de partida não é o texto que aparece na tela de login. É a identidade que seu backend reconhece. A documentação de OpenID Connect define sub como identificador do usuário e apresenta email como uma declaração separada. O Google recomenda usar sub para identificar a conta, em vez de usar o endereço de e-mail como identificador permanente. Consulte a definição dos campos e declarações no OpenID Connect ao conferir seu modelo de dados.

Um erro recorrente é manter uma coluna de e-mail como chave única e procurar o usuário exclusivamente por ela no retorno do login. Se o endereço mudar, a consulta pode falhar e o fluxo pode criar outro registro. Também pode associar uma conta existente sem verificar se aquela identidade externa já está vinculada a outro usuário. A causa não é necessariamente o provedor de login: pode estar na regra local de busca, no tratamento de colisões ou na ordem em que a aplicação atualiza os dados.

Separe, portanto, a identidade externa dos dados de contato. A conta interna deve manter sua chave. A associação com o provedor deve guardar o identificador estável recebido. O endereço pode ser atualizado segundo a política do produto, com registro da alteração e validações adequadas. Se você precisa revisar o tratamento de dados de teste e de contato, consulte as orientações de privacidade adotadas pela sua equipe.

Continuidade de login: autorização existente versus autorização renovada

O comportamento do e-mail pode variar conforme o estado da autorização. O Google informa que, se a autorização existente continuar válida, um aplicativo pode continuar recebendo o endereço antigo. Depois que o usuário revoga o acesso e faz uma nova autorização, o aplicativo pode receber o endereço novo. A mudança descrita pelo Google começou a ficar disponível para usuários nos Estados Unidos em 31 de março de 2026; a fonte também explica que o endereço antigo permanece associado à mesma caixa de entrada. Leia os detalhes e confirme a elegibilidade diretamente no anúncio para desenvolvedores.

O anúncio não significa que todas as contas, regiões ou aplicativos necessariamente apresentem o mesmo resultado. Verifique as páginas oficiais antes de concluir que um cenário é reproduzível na conta de QA disponível. Anote restrições de elegibilidade e de acesso como limitações do teste, não como aprovação implícita.

Além disso, não tome a tela de perfil como prova de que o vínculo está correto. A interface pode mostrar um endereço novo enquanto o backend ainda consulta pelo endereço antigo. Registre o sub recebido no servidor, o endereço retornado e o identificador interno resolvido. Evite colocar tokens completos, segredos ou dados pessoais em logs; use registros de diagnóstico com acesso controlado e o mínimo de informação necessário.

Associação após revogação: conta existente versus cadastro duplicado

O teste de reautorização precisa responder a uma pergunta operacional: o login encontra a conta interna associada à identidade já conhecida, ou inicia um cadastro novo? O e-mail ajuda a entender a mudança, mas não deve decidir sozinho a resposta.

Execute o cenário com uma conta de teste autorizada e um ambiente controlado. Registre o sub retornado antes da revogação. Depois, revogue o acesso pelo fluxo disponível para a conta de teste, repita a autenticação e compare a identidade recebida com o vínculo armazenado. A orientação do Google para validar tokens no servidor está disponível na documentação de autenticação de backend. Não substitua a verificação da assinatura, do emissor, do público ou da validade do token por uma comparação feita somente no cliente.

Interprete os resultados assim:

• Se o mesmo sub aponta para uma conta interna diferente, investigue a consulta de associação e o tratamento de colisões antes de liberar.
• Se o e-mail mudou e o sub corresponde ao vínculo existente, confirme se sua política permite atualizar o contato sem criar outra conta.
• Se o fluxo abre um cadastro novo, verifique se a lógica usa o e-mail como busca exclusiva ou se perde a associação após a revogação.
• Se o sub não corresponde ao que você esperava, não force uma associação com base apenas no endereço. Registre o cenário e investigue a identidade realmente autenticada.

Um fixture pode simular valores diferentes para testar a regra local: por exemplo, um endereço antigo e outro novo associados ao mesmo identificador de teste. Esse teste comprova como seu código reage aos dados de entrada configurados. Não comprova que o Google emitiu esses valores para uma conta real, nem que o processo de alteração ocorreu. Marque fixtures como fixtures e mantenha os resultados separados dos testes com autenticação real.

Recuperação: identidade de login versus endereço de contato

O login Google e o fluxo de recuperação do seu produto têm responsabilidades diferentes. O provedor identifica uma identidade autenticada. Seu produto decide qual endereço de contato mantém e para onde envia mensagens de recuperação. Uma alteração na Conta do Google não atualiza automaticamente, em todos os produtos, os dados de contato que já estão salvos.

O Google informa que, na mudança abordada em sua documentação, o endereço anterior permanece associado à mesma caixa de entrada. Isso é relevante para o acesso à caixa do usuário, mas não substitui a verificação do seu fluxo: sua aplicação pode ter um endereço antigo salvo, pode enviar para outro endereço ou pode aplicar regras próprias de confirmação. Confirme o destinatário efetivamente selecionado e o estado da conta após o uso do link.

Não trate a existência de uma mensagem na caixa de entrada como prova de que a recuperação está correta. Valide o destinatário, o conteúdo que ajuda o usuário a reconhecer o pedido, o destino do link e o estado final da conta. Registre também o caso em que o endereço antigo continua recebendo mensagens por estar associado à caixa de entrada: isso não demonstra que seu produto atualizou o endereço cadastrado, nem que a política de recuperação está segura.

Se sua equipe precisa estruturar os casos antes da execução, a lista de verificação para testes ajuda a organizar o que deve ser validado no ambiente. Adapte os itens para seu modelo de identidade e para o nível de acesso disponível à conta de QA.

Evidências: fixture versus autenticação e recebimento reais

Mantenha três classes de evidência. A primeira cobre a lógica local com fixtures. A segunda comprova o comportamento observado durante um login Google real com uma conta autorizada. A terceira comprova que uma mensagem emitida pelo seu produto chegou a uma caixa de entrada de teste. Elas respondem a perguntas diferentes e não devem ser somadas como se fossem uma única prova.

Em produção, a validação do token continua obrigatória mesmo quando um teste automatizado cobre a lógica de associação. Não crie uma exceção de segurança para facilitar a automação. Se um fluxo de CI/CD não puder autenticar uma conta real com segurança, use fixtures para as regras internas e planeje uma verificação manual ou controlada para a integração. Documente a limitação em vez de marcar a autenticação real como aprovada.

Esse registro também evita um equívoco comum em relatórios de QA: “o e-mail foi trocado no teste” pode significar apenas que um fixture foi alterado. Escreva exatamente qual foi a origem dos dados, qual ambiente foi usado, qual conta tinha autorização e se a mensagem foi realmente recebida. Para reduzir dados pessoais em cenários de demonstração, defina práticas de privacidade e dados de teste que não exponham informações reais.

Lista de aceite: identidade, associação e mensagem

Use a lista abaixo para preparar uma rodada de regressão. Cada item deve terminar com um resultado observável e uma referência ao ambiente ou ao tipo de evidência. Se você não tem acesso a uma conta elegível para a mudança real, registre esse limite claramente e não substitua a evidência por uma simulação.

• [ ] Confirme que o backend valida o ID token antes de usar suas declarações.
• [ ] Confira que a associação externa usa sub, e não apenas o endereço de e-mail.
• [ ] Verifique que o e-mail pode ser atualizado sem trocar a chave da conta interna.
• [ ] Execute o login com autorização existente e registre o endereço que voltou.
• [ ] Revogue a autorização da conta de teste, autentique novamente e compare sub, e-mail e conta interna.
• [ ] Confirme que o fluxo não cria uma conta duplicada quando reconhece a identidade já vinculada.
• [ ] Teste colisões e endereços não confirmados segundo as regras do seu produto.
• [ ] Envie uma recuperação pelo próprio produto e inspecione destinatário, conteúdo, destino do link e estado final.
• [ ] Separe no relatório o resultado de fixture, login Google real e recebimento real da mensagem.
• [ ] Registre a elegibilidade da conta e qualquer cenário que não pôde ser executado.

Para o aceite, priorize a continuidade da identidade, a ausência de associações incorretas, a atualização controlada do contato e a legibilidade da mensagem de recuperação. Um teste aprovado de fixture não cobre o login real. Um login real bem-sucedido não confirma a entrega do e-mail de recuperação. E uma mensagem recebida não demonstra, por si só, que o usuário foi associado à conta interna correta.

Perguntas frequentes

O que o Sign in with Google pode retornar depois da mudança?

O resultado depende do estado da autorização. Com uma autorização existente, o aplicativo pode continuar recebendo o endereço antigo; após revogar o acesso e autorizar novamente, pode receber o endereço novo. Valide o retorno na autenticação real e consulte a documentação oficial, pois a disponibilidade também pode variar conforme a conta.

O e-mail ou o sub deve localizar a conta?

Use sub como identificador da identidade Google depois de validar o token no servidor. O endereço pode mudar e deve ser tratado como dado de contato atualizável. Se a busca depender somente do e-mail, uma mudança pode levar a cadastro duplicado, falha de acesso ou associação incorreta.

Como verificar que uma nova autorização não duplicou o usuário?

Compare o sub antes e depois da revogação, junto do identificador interno da conta resolvida. A mudança de endereço não deve, sozinha, disparar uma nova conta. Fixtures podem testar a regra local, mas não provam os valores que o Google entregará numa autenticação real.

A recuperação enviada ao endereço antigo ainda chega?

O Google diz que o endereço antigo permanece associado à mesma caixa de entrada no cenário documentado. Ainda assim, teste o destinatário e o fluxo do seu produto: confirme qual contato está salvo, para onde a mensagem foi enviada e se o link recupera a conta correta. O recebimento não prova a identidade do usuário.

Verificação de recebimento sem confundir as evidências

Se você precisa comprovar que uma mensagem de recuperação enviada pelo seu próprio produto chegou a uma caixa de teste, use um endereço controlado e registre essa checagem separadamente da autenticação. O MSGTMP pode servir como opção para inspecionar esse recebimento sem expor seu endereço principal; consulte o serviço em MSGTMP. Isso ajuda a avaliar a mensagem emitida pelo seu sistema, mas não substitui uma conta Google de teste, a validação do ID token nem a comprovação de que a associação interna está correta.

Perguntas frequentes