GitHub

Adicionar login social a um app é, tecnicamente, uma das tarefas mais documentadas que existem. Cada provedor tem seu tutorial, e em uma tarde você coloca o botão "entrar com" funcionando. É justamente essa facilidade que cria a armadilha: o time implementa rápido, pula as decisões que importam, e descobre os problemas meses depois, quando já há usuários reais atrelados às escolhas erradas.

Login social na prática não é sobre seguir o tutorial do provedor. É sobre o que você decide antes de abrir o tutorial. Identidade, recuperação de acesso, vínculo de contas, tratamento de dados, essas decisões definem se o login social vai ser uma fundação sólida ou uma dívida que você vai pagar com juros.

Este texto é um roteiro para quem vai implementar. Não a parte do código, que está bem documentada, mas a parte das decisões, que quase ninguém escreve e que é onde os erros caros acontecem.

Decisão um: qual é a sua fonte de identidade

Antes de qualquer integração, decida o que define um usuário no seu sistema. É a pergunta mais importante e a mais negligenciada.

Se você ancorar a identidade no provedor, "este usuário é a conta Google tal", você se prende a ele. O dia em que o usuário quiser trocar de provedor, ou em que você quiser adicionar login por e-mail, vira um problema de migração. Se, em vez disso, você ancorar a identidade em algo que você controla, tipicamente um identificador interno associado a um e-mail verificado, os provedores viram apenas formas de entrar numa conta que é sua, não deles.

A decisão prática: trate cada método de login como uma credencial que aponta para uma identidade interna única. Um mesmo usuário pode ter, ligadas à sua conta, uma entrada por Google, uma por e-mail e senha, e outras no futuro. A identidade é o centro; os métodos de login são satélites. Quem inverte isso paga caro para corrigir depois.

Decisão dois: o que acontece quando o provedor falha

Login social introduz uma dependência externa no caminho crítico do seu produto: a porta de entrada. Você precisa decidir, de antemão, o que acontece quando essa dependência falha, porque ela vai falhar em algum momento.

O provedor pode ficar fora do ar, mudar suas políticas, aumentar custos ou até descontinuar o serviço. Se a sua única forma de autenticação for por meio dele, qualquer um desses eventos tranca os seus usuários para fora, e você fica de mãos atadas.

A decisão madura é não depender de um único caminho. Ofereça mais de uma opção de entrada e mantenha sempre um método que você controla, como e-mail e senha ou um link mágico enviado por e-mail. Assim, mesmo que um provedor saia do ar, o usuário tem por onde entrar e você tem como ajudá-lo. Continuidade do acesso é continuidade do negócio.

Decisão três: como você unifica contas

Este é o detalhe que separa implementações maduras das amadoras. O mesmo usuário, em momentos diferentes, pode tentar entrar por métodos diferentes que apontam para o mesmo e-mail. Você precisa decidir, antes de implementar, como tratar isso.

Sem uma decisão consciente, o resultado padrão costuma ser o pior: o app cria uma conta nova a cada método, fragmentando a vida do usuário em identidades paralelas. Histórico dividido, dados aparentemente perdidos, suporte acionado.

A prática correta exige uma regra clara. Quando alguém entra por um método novo cujo e-mail já existe no sistema, o app deve reconhecer a conta existente e oferecer vincular o novo método a ela, em vez de duplicar. Isso depende de um cuidado importante: só confie no e-mail se o provedor confirmar que ele foi verificado. Vincular contas com base num e-mail não verificado abre brecha para alguém assumir a conta de outro. Essa é uma decisão de segurança, não só de conveniência.

Decisão quatro: quais dados você vai pedir e guardar

Os provedores oferecem acesso a um leque de dados do usuário. Você precisa decidir, antes de integrar, exatamente o que vai pedir, e a resposta deveria ser "o mínimo".

Para autenticar, você normalmente precisa apenas de um identificador estável e de um e-mail verificado. Tudo além disso é dado que você passa a guardar, proteger e justificar. Pedir acesso amplo "para o caso de precisar" é criar passivo sem retorno e aumentar a fricção na tela de permissão, onde parte dos usuários desiste ao ver um pedido invasivo.

A decisão se desdobra em uma segunda: o que fazer com o que você recebe. Guardar o mínimo necessário, definir por quanto tempo, e ter clareza de para que cada dado serve. Essa disciplina é, ao mesmo tempo, boa arquitetura e o caminho natural para a conformidade com a LGPD, que exige finalidade e minimização. Decidir isso na hora de implementar é trivial; reduzir coleta depois, com dados já acumulados, é trabalhoso.

Decisão cinco: privacidade e direito de saída

Implementar login social significa assumir um fluxo de dados pessoais entre o provedor, o seu app e o usuário. A LGPD trata esse fluxo com seriedade, e algumas decisões precisam estar no roteiro desde o início.

Você precisa informar ao usuário, de forma clara, quais dados são obtidos pelo login social e com que finalidade. Precisa ter base legal para tratá-los. E precisa garantir um caminho para o usuário excluir a conta no seu app de maneira independente da conta social dele, apagar a conta do app não pode exigir que ele mexa na rede social, e desvincular não pode deixar dados órfãos espalhados.

Esse último ponto é o mais esquecido na pressa de implementar. O fluxo de entrada recebe toda a atenção; o fluxo de saída, quase nenhuma. Mas o direito de exclusão é tão obrigatório quanto o login é opcional. Planejar a saída junto com a entrada evita uma reescrita futura sob pressão de um pedido de titular ou de uma fiscalização.

A armadilha de tratar como tarefa de uma tarde

O risco que atravessa todo este roteiro é cultural: tratar login social como uma tarefa pequena porque o tutorial é curto. O código é curto; as consequências são longas.

Times maduros reconhecem que autenticação é fundação. Errar nela não causa um bug isolado, causa problemas que se espalham por identidade, dados, segurança e conformidade, todos difíceis de corrigir com usuários ativos no sistema. Uma hora de decisão consciente antes de implementar economiza semanas de remendo depois. Essa é a troca que vale fazer.

Vale também resistir à tentação de adicionar provedores demais de uma vez. Cada provedor é uma integração a manter, uma política a acompanhar, um fluxo a testar. Comece com os que fazem sentido para o seu público e adicione outros quando houver demanda real.

Fechamento

Login social na prática não se resolve no tutorial do provedor. Resolve-se nas decisões que vêm antes: onde mora a identidade, o que acontece quando o provedor falha, como contas se unificam, que dados você pede e como o usuário sai. Essas escolhas são fáceis de fazer no início e caras de refazer depois.

A diferença entre um login social que sustenta o produto e um que vira fonte de incidentes não está na qualidade do código de integração, está na qualidade das decisões que o precederam. Reserve o tempo para decidir antes de digitar.

Se você está prestes a implementar autenticação no seu app, vale percorrer esse roteiro de decisões antes da primeira linha de código. Há outros artigos aqui no blog sobre OAuth, identidade e LGPD que aprofundam cada uma dessas frentes.

Login social na prática: o roteiro de decisões antes de implementar no seu app