Por que você não deveria construir seu próprio sistema de autenticação: lições de dezenas de entrevistas com clientes
Você pode construir seu próprio sistema de autenticação em um dia, e ele rodar por anos. O custo real aparece depois, no dia em que o negócio muda. Lições de dezenas de entrevistas B2B.
YijunDeveloper
Pare de perder semanas com autenticação de usuários
Lance aplicativos seguros mais rapidamente com o Logto. Integre a autenticação de usuários em minutos e concentre-se no seu produto principal.
A autenticação parece algo que você pode resolver sozinho. Email, senha, faz o hash, compara no login. Quão difícil pode ser criar seu próprio sistema de autenticação?
Você pode. Esse é o problema.
Conversamos com dezenas de equipes sobre o sistema de autenticação que construíram. A maioria procurou a gente pelo mesmo motivo: aquilo estava travando o negócio.
Indústrias, stacks e tamanhos diferentes, mas o mesmo desfecho. O sistema de autenticação caseiro virara uma dívida que a equipe carregava.
A parte estranha é que nunca aparece como uma falha geral. O sistema faz login normalmente e roda bem, até que uma mudança de negócio bloqueia tudo: uma auditoria de segurança, o primeiro cliente enterprise, uma aquisição, ou uma funcionalidade integrada a dois produtos.
Na semana passada estava "ok". Aí a próxima tarefa no roadmap trava atrás disso.
O maior erro do auth caseiro é tratá-lo como um recurso. Dá para escrever no primeiro dia. Mas depois que tráfego real passa por ele, começa a se embolar com usuários, organizações e permissões.
Autenticação não é uma funcionalidade. É infraestrutura de identidade.
Atrás da página de login existe todo um modelo de identidade#
Todo auth caseiro começa igual. Recebe email e senha, faz o hash, armazena, compara no login. Quarenta linhas de código, limpo e feito.
O problema começa depois do lançamento. Bots atacam o endpoint de cadastro, então você adiciona rate limiting, CAPTCHA, fingerprint de dispositivo. SMS para de sair numa manhã, então adiciona tentativas e um limite diário. Depois vêm coisas mais difíceis: reset de senha seguro, MFA e seu fluxo de recuperação, sessões e tokens de refresh, e um modelo de permissões muito além de um booleano is_admin.
Nenhum desses é difícil isoladamente. Dá para entregar por sprint. Mas cada vez que finaliza um, você responde uma pergunta maior em nome do produto.
Empilhe essas respostas e você tem o modelo de identidade que seu produto agora assume como verdadeiro: quem é usuário, se uma pessoa pode pertencer a várias organizações, como o sistema de identidade do cliente enterprise se integra, e como o acesso é removido quando alguém sai.
Toda feature escrita depois entende essas respostas como garantidas, e quanto mais o sistema roda, mais difícil fica mudar.
Vimos acontecer numa empresa: vertical SaaS B2B, vinte anos de mercado, atendendo operadores do varejo físico. Fizeram seu próprio auth há mais de uma década, com login separado por cliente e checagem de permissão direto nos módulos de negócio. Na época, parecia sensato.
Vinte anos depois, queriam algo pequeno: uma página unificada de login, usando email como nome de usuário. Não era só trocar uma página. As checagens estavam distribuídas em centenas de módulos, e unificar o login exigia mexer no modelo de usuário, no modelo de organização, migração de credencial e cada limite de permissão. Ninguém queria assinar a mudança, então virou uma novela de anos.
Quando fizeram aquela página de login, parecia só uma funcionalidade. O que deixou foi um modelo inteiro de identidade.
Quando o negócio avança, o auth caseiro costuma parar de funcionar#
Para ser justo, auth caseiro normalmente aguenta anos. Faz login, renova sessão, toca a rotina diária por muito tempo. A complexidade aumenta devagar, nunca de uma vez, e você resolve um problema de cada vez, sentindo que está sob controle.
Mas ser "suficiente" muitas vezes só significa que o negócio ainda não bateu no limite. Quando bate, normalmente o problema não é o auth em si. O negócio ao lado mudou, e o "suficiente" vira "obstáculo" da noite para o dia.
As situações abaixo aparecem na maioria dos produtos à medida que escalam. Parecem diferentes, mas no fundo é sempre igual: o negócio andou, e o modelo antigo de identidade não acompanha mais.
O cenário: um cliente quer fazer login com o próprio IdP, e seu auth não entende o conceito de "proveedor de identidade de terceiros".
O primeiro grande contrato enterprise chega, e a área de compras manda um documento de requisitos. Primeiro SSO via Microsoft Entra ou Google Workspace. Depois pedem SAML e OIDC porque outro cliente usa outra coisa. Depois SCIM, para provisionar e desprovisionar funcionários automaticamente.
Cada cliente tem um setup diferente: protocolos diferentes, campos, rotação de certificado, e jeitos distintos de mapear a estrutura da organização.
Quase nada desse trabalho reaproveita. O próximo cliente traz outro IdP e configuração nova, e a maior parte começa do zero. SSO não é uma feature que se faz uma vez. Cada cliente novo pede a mesma coisa e o esforço cresce junto com a base enterprise.
Auth deixa de ser "fazer login no seu produto" e vira "integrar com o sistema de identidade do cliente". Dois trabalhos completamente diferentes.
Vimos uma empresa cujo setup inteiro de SSO era feito à mão, e só um engenheiro entendia de ponta a ponta. Quando ele estava, o cliente ia ao ar. Quando saía de férias, vendas e onboarding entravam em fila. Quando saiu da empresa, o know-how foi embora com ele.
Nada disso estava no escopo quando decidiram construir o auth ali atrás.
O produto precisa unificar identidades espalhadas#
O cenário: seus dados de identidade começaram fragmentados, separados por organização e produto, e conforme o negócio cresce você precisa de identidade unificada.
A empresa dos vinte anos passou por isso ao tentar unificar o login, e esse padrão aparece em vários produtos. Ajudamos uma plataforma com nove produtos, todos de aquisições, cada um com seu auth e base de usuários.
Aquisição não faz merge por você. Cada novo produto comprado traz outro auth, e manter nove em paralelo demanda gente só para isso.
As perguntas só aumentam. A mesma pessoa é um usuário nos produtos A e B ou dois? Como cruzar a mesma empresa nas duas plataformas? Como autorizar funcionalidades que cruzam produtos? Quando um funcionário deixa a empresa, como cortar acesso nos nove de uma vez? E como auditar tudo isso?
Nenhum dos nove estava quebrado. Juntos, viraram uma muralha.
"Unificar identidade" parece feature. No código, significa redefinir o conceito fundamental: o que é um usuário e uma organização. Quase tudo depende da antiga definição, então ao mexer nela, mexe todo o resto por cima.
Na era da IA, agentes e CLIs acessam seu sistema em nome do usuário#
O cenário: não são só pessoas fazendo login pelo navegador. Agora agentes, linhas de comando e scripts atuam por usuários, enquanto seu auth só entende "gente fazendo login na página".
Um agente precisa acessar suas ferramentas internas por conta de um usuário. Um servidor MCP expõe recursos protegidos. Uma CLI precisa ver dados de conta sem navegador.
Todos lidam com as mesmas questões: pra qual usuário a requisição vale, quais recursos pode acessar, pra quem o token foi emitido, qual escopo, como revogar, audita agente ou usuário?
O sistema antigo nunca construiu mecanismos pra esses clientes. MCP usa OAuth pra autorização. CLI ou faz login OAuth ou carrega token pessoal, que pode ser revogado a qualquer momento. Nada disso pensa numa página de login.
Se seu auth foi feito para gente real logando em página, agora você precisa lidar com clientes agindo em nome deles.
Manutenção de longo prazo é o maior custo de um auth próprio#
Nenhuma dessas situações é "auth caiu". O sistema roda. Cada uma parece uma feature pequena, mas começa virando estratégia de produto, migração de dados e trabalho de entrega para o cliente.
MFA é o melhor exemplo. À primeira vista: "podemos verificar mais uma vez depois do login?"
Duas etapas depois: em quais organizações e usuários forçar MFA, admin pode obrigar para membros, ações sensíveis como trocar info de pagamento ou exportar precisam revalidação, como gerar e resetar códigos de recuperação, suporte pode resetar, MFA do SSO pertence a você ou ao IdP do cliente? Adicionar MFA adiciona toda uma camada de política de segurança.
"Só sincronizar uns usuários" é igual: por trás tem uma sequência de decisões sobre onboarding, offboarding e participação em várias organizações, cada uma pressupondo que user e org model estavam certos desde o início.
Cada feature adicionada significa manter um produto de identidade dentro do seu. A primeira versão custa pouco, uns engenheiros e algumas semanas. Mas você alimenta isso ano após ano.
O motivo mais comum para construir próprio é custo, e não é inocente.
Uma entidade de membros nos contou que fez as contas cinco anos antes. Cem mil membros, só alguns milhares acessando frequentemente. Os fornecedores cobravam por total, a cotação passou do orçamento, fazer interno saiu mais barato naquele ano.
Cinco anos depois, a conta mudou. Manter login e garantir segurança já tinha custado mais do que comprar.
No início, a fatura que você economiza é visível, o tempo de engenharia não. Cinco anos depois, a conta evitada é igual, mas o tempo de engenharia virou atraso de roadmap, dívida de segurança e manutenção que ninguém quer assumir.
Construir seu auth não é grátis. Você só não recebe uma fatura dizendo "assinatura de autenticação". O pagamento é em meses da equipe, atrasos, retrabalhos, dívidas e o foco de engenharia que poderia estar no produto real.
Aquele engenheiro que faz SSO a mão não é exceção. Auth caseiro por tempo suficiente, o contexto crítico se fixa em um ou dois: qual cliente está configurado de qual forma, qual campo não pode mexer, por que certa migração foi feita daquele jeito. Raramente vira documentação. Fica só na cabeça de alguém.
Quando está presente, as entregas andam. Quando não, a fila enterprise para, e você descobre que a infraestrutura mais importante não tem dono, só "quem sabe".
Algumas equipes vão além e criam plataforma para o próprio cliente configurar SSO self-service. Parece maturidade, mas quantos clientes usa? Vimos uma empresa com 1,5 milhão de usuários ativos e esse sistema todo servia mal a uma dúzia de clientes.
Você achou que era uma feature. No fundo era um produto interno, cujo custo se espalha entre uma dúzia de clientes. Se identidade é o seu negócio, vale a pena. Se não, é a fatura oculta em sua forma mais pura.
Voltando ao SaaS vertical dos vinte anos. Eles não são fracos. Manter produto relevante por duas décadas mostra exatamente que dominam o cliente.
Esse é todo o problema. Indo direto: prefere que mantenham SSO de cada cliente à mão e tirem vinte anos de lógica de permissão de centenas de módulos, ou que foquem no produto do setor?
Não é perfeccionismo. É alocação de recurso. Se você faz contas a pagar, SaaS vertical, portal de membros ou sistema operacional, ninguém paga um centavo a mais porque desenvolveu teu próprio servidor OAuth.
Uma equipe de contas a pagar resumiu: o IdP caseiro funcionava, mas era decisão estratégica. Não escreva muito código de auth. Guarde a energia para tornar a plataforma melhor, e use o auth mais testado do mercado para o resto.
Auth precisa ser confiável. Mas "confiável" não é igual a "feito por você mesmo". Seu banco de dados, e-mail e cloud também precisam ser. E uma equipe madura não assume que algo é próprio só porque é importante.
Para a maioria, auth é dependência central, não diferencial. A menos que identidade seja o produto, rodar um produto de identidade dentro da aplicação dificilmente gera barreira de entrada. Só drena recursos ao longo do tempo.
Fácil cair no extremo: nunca escreva código de auth. Errado também.
Em certos momentos, construir o próprio (ou metade dele) faz total sentido: demos internos, protótipos inicias, validações pontuais. E se o negócio exige autorização fina que plataforma pronta não cobre, manter isso dentro de casa enquanto auth, sessão, SSO, MFA e diretório vão para uma solução externa é perfeitamente razoável.
Só cuide do risco POC. Vimos isso várias vezes: dois devs gastam seis a oito meses em um protótipo pra integrar sistema externo. A ideia não é ruim. Nas próprias palavras deles, ficou bom. Só não era para escala.
E POC é a coisa mais fácil de virar arquitetura. Meio ano vira "a solução atual", dois anos depois "o sistema legado", cinco anos depois "infraestrutura intocável". O melhor momento para largar auth próprio não é depois de quebrar. É antes de virar base de tudo.
Ou seja: não é ter escrito linha de código de auth. É assumir um pedaço genérico de infraestrutura de identidade e mantê-lo da equipe no longo prazo.
Construa as pontas sozinho. Cuidado com o core de identidade. E não construa sem perceber um CIAM completo.
Se não construir, como escolher uma solução de auth?#
Se decidir não fazer, surge a questão: de quem comprar e como escolher?
As soluções maduras já cobrem as features: SSO, MFA, múltiplas organizações, login unificado, acesso para agentes. Então o real diferencial raramente está nas features.
O que passa batido e merece ser comparado são os pontos a seguir. São partes de uma coisa: não saia do auth caseiro de mil linhas para um sistema de onde não consegue sair.
Aderir a protocolos padrão, não pilha inventada por fornecedor. OIDC, OAuth, JWTs assinados com RS256 são padrões compreensíveis. Você lê claims direto do token, sem API específica para aprender.
Tenha sempre uma porta de saída verdadeira. Se a solução é open source e você pode hospedar, pode sair quando quiser. (Manter versão própria é outro custo oculto, claro.)
Cobrança não pode seguir sua tabela de usuários. Cobrar por usuários registrados ou ativos acompanha tabela só crescente, cheia de gente que não acessa mais, e em escala vira "taxa de crescimento". Essa foi a precificação que tornou auth próprio mais barato no caso do exemplo acima.
Seus dados não devem ser aprisionados. Você precisa exportar dados de usuários quando quiser. E entregar esse dado sensível para host especializado te livra do risco de guardar pilha de dados privados que não deveria ser seu.
Sendo transparente: Logto é nosso produto de auth feito exatamente nesses quatro pontos. Open source, self-hosted, e disponível também em Cloud gerenciado: use Cloud sem manutenção, ou hospede você mesmo para controle total; no dia que quiser migrar, a porta segue aberta.
Login, MFA, SSO e RBAC funcionam prontos via OIDC padrão, a cobrança é por token, ou seja, paga-se pelo uso real.
Existem outras opções maduras, e auth nunca teve uma única resposta certa. Se estiver avaliando, escrevi um artigo sobre como escolher uma solução de auth para você usar.
Conclusão: não confunda uma plataforma de identidade com uma funcionalidade comum#
Construir auth próprio normalmente faz sentido no primeiro dia. O problema é que vira infraestrutura com o tempo.
Cada novo passo do negócio expõe de novo: enterprise quer SSO, segurança pede MFA, o produto quer login unificado, aparecem múltiplos produtos, agentes de IA precisam acessar recursos em nome do usuário. Por trás de cada feature pequena existe uma sequência de políticas, e alimentar isso ao longo dos anos tira o tempo de engenharia do produto central.
A fatura não chega no primeiro dia. Costuma vir anos depois. Aí que você percebe: aquela página de login que escreveu lá atrás já era infraestrutura de identidade para vida toda do produto.
Autenticação provavelmente não é seu negócio principal. Quanto antes perceber, mais cedo pode focar tempo e energia naquilo que realmente constrói.
Nunca se deve construir seu próprio sistema de autenticação?#
Não. Demos inicias, ferramentas internas, validações únicas ou autorização fina que plataforma pronta não suporta podem justificar auth próprio. O que evitar é assumir uma infraestrutura genérica de identidade de longo prazo sem perceber, e deixá-la dentro do escopo de manutenção do time de produto.
Qual a diferença entre autenticação e autorização?#
Autenticação responde "quem é você". Autorização responde "o que você pode fazer". Em um SaaS real é difícil separar: usuários, organizações, papéis, permissões, sessões, claims de token e logs de auditoria se entrelaçam. Trocar auth não é só olhar a página de login.
Por que SSO enterprise torna auth caseiro complicado?#
Porque envolve plugar seu produto no sistema de identidade do cliente, que é diferente em cada empresa: IdPs, protocolos, fields, certs e mapeamentos organizacionais mudam de lugar pra lugar. Conectar o primeiro cliente não significa repetir com o resto. Na prática, vira trabalho manual que só um dev entende.
Rodamos auth próprio faz anos. Dá pra migrar ainda?#
Sim, mas o corte seco raramente é a solução. Migre em camadas: coloque novos cadastros, logins e SSO enterprise na plataforma de identidade primeiro, e migre usuários existentes no próximo login deles. Garanta rollback e logs de auditoria sempre, para que a migração nunca seja irreversível.
