Você consegue construir sua própria autenticação em um dia. Essa é a armadilha.
Dezenas de times B2B nos contaram a mesma história. Começa como uma simples página de login. Aí o tráfego real começa a passar por ela e, sem alarde, ela vira infraestrutura de identidade: a base sobre a qual o produto inteiro se apoia.
Parecia um recurso. Deixou para trás um modelo de identidade inteiro.
Toda autenticação caseira começa com um punhado de linhas. O problema aparece depois do lançamento, quando cada pequena decisão silenciosamente endurece no modelo que o produto inteiro passa a assumir como verdadeiro.
Dia um: quarenta linhas de código
E-mail, senha, faz o hash, guarda, compara no login. Limpo e pronto.
Dia duzentos: um modelo de identidade silencioso
Quem conta como usuário. A qual organização ele pertence. Qual sessão ainda é confiável. Como o acesso é revogado.
Ano cinco: uma fundação que você não pode tocar
Trocar a página de login no papel significava reconstruir a fundação de identidade no código.
A autenticação caseira roda bem — até o negócio se mexer
Ela faz login das pessoas por anos sem incidente. Aí uma mudança no negócio transforma o “suficiente” em “no caminho” da noite para o dia. Estas três chegam para quase todo produto que escala.
Clientes corporativos começam a pedir SSO
O primeiro grande contrato fecha e o procurement quer SSO pelo Entra ou Google Workspace deles. Depois SAML e OIDC, porque o próximo cliente usa outra coisa. A configuração de identidade de cada cliente é diferente, e quase nada do trabalho se reaproveita.
- Protocolos, mapeamentos de campos e rotações de certificado diferentes por cliente
- SSO não é feito uma vez. Você o reconstrói para cada empresa que assina
- Vira trabalho manual que só um engenheiro entende de ponta a ponta
A identidade que começou espalhada agora precisa ser uma só
Dividida por organização, dividida por produto, muitas vezes herdada por aquisições. “Unificar identidade” soa como recurso; no código, significa redefinir o que conta como um usuário e uma organização.
- Um mesmo e-mail pode pertencer a várias organizações? Como migrar os usernames históricos?
- Nove produtos vindos de aquisições significam nove stacks de auth rodando em paralelo
- Revogar quem sai em todos eles de uma vez, e auditar em um só lugar
Agentes de IA e CLIs começam a agir em nome do usuário
Não são mais só pessoas num navegador. Agentes, servidores MCP e linhas de comando alegam agir por algum usuário. E a sua autenticação só sabe logar uma pessoa numa página.
- Para quem o token é emitido, com qual escopo e qual audiência?
- Conceder só uma ferramenta ou uma fatia de dados, e revogar depois
- Acesso via MCP e CLI se apoia em OAuth, não num formulário de login
O custo real não é construir. É carregar isso por anos.
A primeira versão é barata: alguns engenheiros, algumas semanas, no ar. Depois você a alimenta todo ano com o tempo de engenharia que pertencia ao seu produto principal.
A conta só mudou a forma de pagamento
Você nunca recebe uma fatura que diz “autenticação”.
Tudo se apoia, sem alarde, em uma ou duas pessoas
O contexto crítico vive na cabeça de alguém, não na documentação.
Onde você quer seus engenheiros?
Nenhum cliente paga um centavo a mais porque você escreveu seu próprio servidor OAuth.
Se você não vai construir, como escolher?
A maioria das soluções maduras já cobre os recursos: SSO, MFA, organizações, login unificado, acesso de agentes. A diferença real é se você consegue sair. Não escape das suas próprias poucas milhares de linhas só para se prender nas de outra pessoa.
Protocolos padrão, não uma stack inventada
Uma porta por onde você realmente consegue sair
Cobrança que não acompanha sua tabela de usuários
Seus dados nunca ficam presos
Autenticação provavelmente não é o seu negócio principal. Trate-a assim.
O Logto é open source, self-hostable e também oferecido como um Cloud gerenciado. Login, MFA, SSO e RBAC funcionam de imediato sobre OIDC padrão. A cobrança segue os tokens e, no dia em que você quiser sair, a porta continua aberta.