Porque não deves construir o teu próprio sistema de autenticação: lições de dezenas de entrevistas a clientes

A autenticação parece algo que consegues despachar sozinho. Email, palavra-passe, faz o hash, compara ao fazer login. Quão difícil pode ser construir o teu próprio sistema de autenticação?

Podes fazê-lo. Esse é o truque.

Falámos com dezenas de equipas sobre a autenticação que construíram por conta própria. A maioria veio até nós pelo mesmo motivo: estava a atrasar o negócio.

Diferentes setores, stacks e dimensões, mas o mesmo desfecho. A autenticação que construíram tornou-se numa dívida que a equipa carregava.

A parte estranha é que nunca aparece como uma indisponibilidade. O sistema entra as pessoas e funciona bem, até que uma mudança no negócio bloqueia o caminho: uma revisão de segurança, o primeiro cliente empresarial, uma aquisição, uma funcionalidade que precisa de abranger dois produtos.

Na semana passada estava "tudo bem". Depois, a próxima coisa no roadmap fica presa atrás disso.

O maior erro com autenticação caseira é tratá-la como uma funcionalidade. Dá para escrever no primeiro dia. Mas assim que o tráfego real passa por lá, emaranha-se com os utilizadores, organizações e permissões.

Autenticação não é uma funcionalidade. É uma infraestrutura de identidade.

Atrás da página de login está todo um modelo de identidade#

Todo o sistema de autenticação caseiro começa da mesma forma. Pega num email e numa palavra-passe, faz o hash, guarda, compara ao fazer login. Quarenta linhas de código, limpas e concluídas.

O problema começa depois do lançamento. Bots atacam o endpoint de registo, então adicionas rate limiting, CAPTCHA, fingerprint do dispositivo. Os códigos SMS deixam de sair numa manhã, então acrescentas tentativas e um limite diário. Depois vêm as partes mais difíceis: recuperação segura de palavra-passe, MFA e seu fluxo de recuperação, sessões e tokens de refresh, e um modelo de permissões que é muito mais do que um booleano is_admin.

Nada disto é difícil isoladamente. Cada um cabe numa sprint. Mas cada vez que entregas uma destas, estás a responder a uma questão maior pelo produto.

Empilha essas respostas e tens o modelo de identidade que o teu produto agora assume como verdadeiro: quem conta como utilizador, se uma pessoa pode pertencer a várias organizações, como é que o sistema de identidade de um cliente empresarial se liga, e como é que o acesso é revogado quando alguém sai.

Todas as funcionalidades seguintes tratam essas respostas como adquiridas, e quanto mais tempo passam, mais difícil é mudá-las.

Vimos isto acontecer numa empresa: uma SaaS vertical B2B, vinte anos de existência, servindo operadores de lojas físicas. Construíram o seu próprio sistema de autenticação há mais de uma década, com um login separado por cliente e verificações de permissões escritas diretamente nos módulos de negócio. Na altura, era a decisão certa.

Vinte anos depois, queriam algo que parece pequeno: uma única página de login, com o email como nome de utilizador. Não era sequer uma mudança de página. Essas verificações estavam espalhadas por centenas de módulos, e unificar o login significava mexer no modelo de utilizador, no modelo de organização, migração de credenciais, e em cada fronteira de permissões. Ninguém queria aprovar isso, por isso arrastou-se durante anos.

Quando escreveram aquela primeira página de login, parecia uma funcionalidade. O que ficou para trás foi um modelo de identidade completo.

Quando o teu negócio avança, autenticação caseira deixa de ser suficiente#

Para ser justo, autenticação caseira normalmente dura bastante tempo. Faz login, refresca sessões e suporta o dia-a-dia do negócio durante anos. A complexidade acumula-se devagar, nunca de uma só vez, e vais resolvendo aos poucos, sentindo que está sob controlo.

Mas ser "suficiente" normalmente só significa que o negócio ainda não bateu na parede. Quando isso acontece, o problema raramente é a autenticação em si. É o negócio ao lado que mudou, e "suficiente" passa a ser "atrapalho" de um dia para o outro.

Os exemplos abaixo aparecem na maioria dos produtos à medida que escalam. Parecem diferentes mas, na essência, é sempre o mesmo: o negócio avançou e o antigo modelo de identidade não acompanha.

Clientes empresariais começam a pedir SSO#

O cenário: um cliente quer autenticar-se com o seu próprio IdP, e o teu sistema não reconhece "provedores de identidade externos".

Chega o primeiro contrato empresarial a sério, e o procurement envia os requisitos. Primeiro é SSO via Microsoft Entra ou Google Workspace. Depois é SAML e OIDC, porque o cliente seguinte usa outra coisa. Depois é SCIM, para provisionar e desprovisionar colaboradores automaticamente.

Cada cliente tem uma configuração diferente: protocolos, mapeamento de campos, rotação de certificados, e modos de alinhar a estrutura deles com a tua.

E quase nada disto é reutilizável. O próximo cliente traz um IdP novo e outra configuração, e a maior parte do trabalho volta a ser feito do zero. SSO não é uma funcionalidade que se constrói uma vez. Cada grande cliente que fechas, voltas a construí-la, e o custo só cresce com o número de clientes.

Autenticação deixou de ser "deixa os utilizadores entrarem no teu produto." Passou a ser "deixa o teu produto ligar-se ao sistema de identidade do cliente". Dois trabalhos completamente distintos.

Vimos uma empresa onde todo o setup SSO era feito à mão, e só um engenheiro entendia tudo do início ao fim. Quando estava presente, os clientes avançavam. Quando ia de férias, as vendas e onboarding ficavam parados. Quando saiu, o conhecimento saiu com ele.

Nada disto estava em cima da mesa no dia em que decidiram construir autenticação própria.

O produto precisa de unificar identidades dispersas#

O cenário: começaste com a identidade fragmentada, separada por organização e produto, e à medida que o negócio cresce, passa a ser necessária uma identidade unificada.

A empresa de vinte anos a que nos referimos acima sentiu isto ao tentar unificar o login, e vemos o mesmo padrão em vários produtos. Trabalhámos com uma plataforma com nove produtos, todos adquiridos, cada um com o seu auth e base de utilizadores.

Uma aquisição não funde essas identidades por ti. Cada produto comprado traz mais um stack de autenticação, e manter nove em paralelo exige pessoal só para isso.

As perguntas acumulam-se. É a mesma pessoa um só utilizador no produto A e no B, ou dois? Como alinhar a mesma organização de cliente em ambos? Como autorizar uma funcionalidade transversal? Quando um funcionário sai, como revogar acesso a todos os nove de uma vez? E onde auditar qualquer uma destas ações?

Nenhum dos nove está avariado. Juntos, são um muro.

"Unificar identidade" parece uma funcionalidade. Em código, significa redefinir a coisa mais fundamental: o que é um utilizador e uma organização. Quase todas as funcionalidades assentam na definição antiga, então mudar isso move toda a camada por cima.

Na era da IA, agentes e CLIs acedem ao teu sistema em nome do utilizador#

O cenário: já não são só pessoas a fazer login pelo browser. Agora agentes, linhas de comando e scripts também atuam por um utilizador, mas a tua autenticação só conhece uma coisa: uma pessoa a fazer login numa página.

Um agente precisa de chamar ferramentas internas por um utilizador. Um servidor MCP precisa de expor recursos protegidos em segurança. Uma CLI precisa de aceder a dados de conta sem browser.

Todos levantam as mesmas questões: por que utilizador age este pedido, a que recursos pode aceder, a quem é emitido o token, qual o seu escopo, como revogá-lo, registamos o utilizador ou o agente?

O sistema antigo nunca construiu mecanismos para estes clientes. MCP baseia-se no OAuth para autorizar. Uma CLI ou faz login via OAuth ou usa um personal access token substituto de pessoa que pode ser revogado a qualquer altura. Nada disto foi feito para uma página de login.

Se a tua autenticação foi desenhada para uma pessoa numa página, é agora que deves lidar com clientes a agir em nome dos utilizadores.

A manutenção a longo prazo é o maior custo da autenticação própria#

Nenhuma das situações acima é "a autenticação foi abaixo". O sistema continua a funcionar. Cada uma parece uma funcionalidade pequena e, assim que começas, transforma-se em estratégia de produto, migração de dados e deliverable para clientes.

MFA é o exemplo mais claro. À superfície, é "podemos verificar uma vez mais após login".

Duas etapas depois, é: a que organizações e utilizadores obrigas? Um admin pode forçar nos membros? Ações sensíveis como alterar info de pagamento ou exportar dados precisam revalidação? Como geras e recuperas códigos de recuperação? O suporte pode repor? O MFA de um SSO pertence a ti ou ao IdP do cliente? Acrescentar MFA significa acrescentar uma camada inteira de política de segurança.

"Sincronizar alguns utilizadores" é igual: por trás há uma cadeia de decisões sobre onboarding, saída e múltiplas organizações, cada uma a pressupor que os teus modelos de utilizador e organização estavam certos desde o início.

Quanto mais funcionalidades acrescentas, mais estás a manter um produto de identidade dentro do teu produto. A primeira versão é barata, uns engenheiros e algumas semanas. Mas alimentas isso ano após ano.

O custo oculto: a fatura só mudou a forma de pagamento#

A razão mais comum para construir o teu próprio é o custo, e não é ingênua.

Uma associação de membros que entrevistámos fez as contas há cinco anos. Tinham cerca de cem mil membros, mas só uns milhares faziam login regularmente. Os fornecedores cobravam pelo total de membros, o orçamento estourou, e fazer internamente saiu mais barato. Naquele ano, não foi uma má decisão.

Cinco anos depois, a matemática inverteu. Manter o login próprio e garantir segurança já custou mais do que teria custado comprar.

No primeiro ano, a factura que poupas é visível e o tempo de engenharia não. Ao fim de cinco anos, o valor evitado é o mesmo, mas o tempo de engenharia transformou-se em atrasos no roadmap, dívida de segurança e manutenção que ninguém quer assumir.

Construir a tua autenticação não sai de graça. Só nunca recebes uma factura com "subscrição de autenticação." Pagas em horas de engenharia, prazos falhados, retrabalho, dívida técnica e foco tirado do teu produto central.

Um punhado de engenheiros acaba por ser dono disto#

Aquele engenheiro a manter SSO à mão não é caso único. Mantém autenticação própria tempo suficiente e o contexto crítico acaba por assentar em uma ou duas pessoas: que cliente tem que configuração, que campo não se pode mexer, porque uma migração foi feita daquela maneira. Raramente vai para a documentação. Vive na cabeça de alguém.

Quando ele está, a entrega anda. Quando não está, o pipeline empresarial pára, e descobres que a tua infraestrutura mais importante não tem dono, apenas "quem sabe do assunto".

Algumas equipas vão mais longe e constroem para os clientes um self-service completo de configuração SSO. Parece maduro, até perguntares quantos clientes serve. Vimos um com 1,5 milhões de utilizadores mensais a operar um sistema destes só para uma dúzia de clientes.

Pensavas que estavas a construir uma funcionalidade. Estavas a construir um produto interno, com o custo repartido por uma dúzia de clientes. Se identidade é o teu negócio, vale a pena. Caso contrário, é a fatura escondida na sua forma mais pura.

Onde queres os teus engenheiros?#

Voltando à SaaS vertical de vinte anos. Estes engenheiros não são fracos. Manter um produto do setor vivo durante vinte anos prova precisamente que conhecem bem os seus clientes.

Esse é o problema. Resumindo: queres que estejam a manter à mão o SSO de cada cliente e a desenrolar vinte anos de permissões em centenas de módulos, ou aprofundar o software do setor?

Não é perfeccionismo de engenharia. É alocação de recursos. Se constróis pagamentos, uma SaaS vertical, um portal de membros, ou software operacional, nenhum cliente te paga nem mais um cêntimo por teres escrito o teu próprio servidor OAuth.

Uma equipa de pagamentos disse-o diretamente: o IdP caseiro deles era bom, mas era uma decisão estratégica. Não escrever demasiado código de autenticação. Guardar energia para fazer pagamentos o melhor possível, e usar a solução de autenticação mais provada no mercado para o resto.

Autenticação tem de ser fiável. Mas "fiável" não é o mesmo que "construída por ti". A base de dados, entrega de email, e cloud também têm de ser fiáveis, e uma equipa madura não assume que tudo importante tem de ser interno.

Para a maioria dos produtos, autenticação é dependência central, não um diferenciador. A não ser que identidade seja o teu negócio, correr um produto de identidade dentro do teu produto não é normalmente vantagem competitiva. É um dreno de recursos a longo prazo.

Quando ainda faz sentido construir autenticação própria?#

É fácil cair no extremo: nunca escrever código de autenticação. Isso também é errado.

Em algumas fases, faz sentido construir a tua (ou metade dela): protótipos internos, demos, projetos piloto. E se o teu negócio tem regras de autorização muito específicas que as plataformas existentes não conseguem exprimir, manter essa parte in-house, enquanto uma solução externa trata de autenticação, sessões, SSO, MFA e o diretório de utilizadores, é perfeitamente razoável.

Atenção ao efeito POC. Já vimos isto: dois developers passam seis a oito meses num protótipo para integrar com um sistema externo. A abordagem não é má. Eles próprios dizem que está bom. Só nunca foi feito para escalar.

E um POC é a coisa mais fácil de endurecer para arquitetura de longo prazo. Seis meses depois é "a solução atual", dois anos depois "o sistema legado", cinco anos depois "infraestrutura intocável". O melhor momento para sair do auth próprio normalmente não é depois de falhar. É antes de virar fundação.

A linha é esta: a questão não é se escreveste uma linha de código de autenticação. É se aceitaste manter uma plataforma de identidade genérica a longo prazo na tua equipa.

Constrói tu próprio as capacidades de ponta. Cuidado com a camada central. E não construas inadvertidamente um CIAM completo.

Se não fores tu a construir, como escolher uma solução de autenticação?#

Se decidires não a escrever tu mesmo, a próxima questão aparece: de quem compras e como escolher?

As soluções maduras já cobrem as funcionalidades: SSO, MFA, múltiplas organizações, login unificado, acesso de agentes. A diferença real raramente está nas funcionalidades.

O que é fácil de ignorar, e mais relevante, são os pontos abaixo. Todos giram em torno de uma preocupação: não saias de meia dúzia de milhares de linhas tuas para ficares preso noutro sistema de onde não consegues sair.

• Usa protocolos standard, não stacks inventados por um único fornecedor. OIDC, OAuth e JWTs assinados com RS256 são conhecidos. Lês os claims diretamente do token, sem API específica do fornecedor.
• Mantém uma porta de saída real. Se a solução for open source e self-hosted, podes sair quando quiseres. (Mas manter uma versão self-hosted tem o seu próprio custo oculto.)
• Não deixes a faturação seguir a tua tabela de utilizadores. Cobrar por utilizadores registados ou mensais ativos segue uma lista que só cresce, cheia de pessoas que já não entram, e à escala transforma-se num "imposto de crescimento". Foi este modelo de preços que levou a associação acima a optar por auth própria.
• Os teus dados não ficam trancados. Podes exportar dados quando quiseres. E entregar estes dados sensíveis a um especialista poupa-te o risco de proteger algo privado que nunca devias guardar.

Disclaimer: Logto é o produto de autenticação que nós criámos exatamente por estes quatro motivos. É open source, self-hosted, e também disponível como Cloud gerido: usa Cloud para zero manutenção, ou self-host para controlo total, e no dia em que quiseres sair, a porta está aberta.

Login, MFA, SSO e RBAC funcionam prontos a usar sobre OIDC standard, e a faturação baseia-se em tokens, pagando só pelo que usas.

Há outras opções maduras, e autenticação nunca foi uma pergunta de resposta única. Se estás a avaliar, escrevi um artigo inteiro sobre como escolher uma solução de autenticação para consulta.

Conclusão: não confundas uma plataforma de identidade com uma funcionalidade ordinária#

Construir autenticação própria é normalmente razoável no início. O problema é que cresce e vira infraestrutura.

Cada passo do negócio volta a expor o tema: empresas querem SSO, segurança quer MFA, o produto quer login unificado, vários produtos precisam de se ligar, agentes IA querem aceder a recursos de um utilizador. Por trás de cada funcionalidade pequena está uma cadeia de políticas, e alimetá-la durante anos consome o tempo de engenharia que fazia falta no teu core.

Esta fatura não chega no primeiro dia. Muitas vezes chega anos mais tarde. Nessa altura vês: aquela página de login era já infraestrutura de identidade que ia atravessar toda a vida do produto.

Provavelmente autenticação não é o teu negócio. Quanto mais cedo vires isso, mais cedo voltas a focar o teu tempo e recursos no produto que realmente estás a construir.

FAQ#

Nunca se deve construir um sistema próprio de autenticação?#

Não. Demos, ferramentas internas, projetos-piloto, ou regras de autorização muito específicas que o mercado não cobre podem justificar. O a evitar é assumir uma plataforma genérica de identidade por tempo indefinido sem dar conta e colocá-la na manutenção de uma equipa de produto.

Qual a diferença entre autenticação e autorização?#

Autenticação responde "quem és tu". Autorização responde "o que podes fazer". Numa SaaS real as duas estão entrelaçadas: utilizadores, organizações, roles, permissões, sessões, claims de token, e logs de auditoria entrelaçam-se. Por isso, ao trocar um sistema de autenticação, não podes olhar só para a página de login.

Porque é que o SSO empresarial complica a autenticação caseira?#

Porque significa ligar o teu produto ao sistema de identidade do cliente. Cada cliente usa diferentes IdPs, protocolos, campos, certificados, e mapeamentos. Ligar o primeiro não significa copiar o resto. Muitas vezes vira trabalho manual que só um engenheiro entende.

Já tivemos o nosso próprio durante anos. Podemos migrar?#

Sim, mas raramente a mudança total é o caminho. Migra por camadas: começa por novos registos, logins e SSO empresarial na plataforma de identidade, e migra os utilizadores antigos no próximo login deles. Mantém rollback e logs de auditoria sempre, para jamais ser irreversível.