Keycloak, Auth0 ou login próprio: qual escolher

Todo sistema novo tem uma tela de login, e ela costuma ser tratada como o detalhe mais simples do projeto: um campo de e-mail, um de senha e um botão. Até que alguém pede "entrar com o Google", o cliente quer que os usuários dele acessem com a conta da empresa, a auditoria pergunta quem acessou o quê, e o segundo sistema da casa precisa reaproveitar os mesmos usuários.

Nesse ponto aparece a dúvida: continuar com o login feito dentro da aplicação, contratar um provedor de identidade gerenciado como Auth0, Amazon Cognito ou Microsoft Entra ID, ou subir um Keycloak em servidor próprio? Este texto organiza essa escolha para quem decide, sem exigir que o leitor saiba o que é um token.

Resposta curta: decida pela quantidade de sistemas e de tipos de usuário. Um sistema só, usado por funcionários, resolve bem com o login do próprio framework ou com o diretório que a empresa já tem (Entra ID ou Google). Quando há vários sistemas, clientes e parceiros entrando, com exigência de login único, segundo fator, login social e auditoria, um provedor de identidade evita reinventar segurança. Entre Keycloak e Auth0, a pergunta é quem opera: o Auth0 é um serviço gerenciado, pago conforme o uso, em que o fornecedor cuida da infraestrutura; o Keycloak é código aberto, sem licença, mas roda nos seus servidores e vira responsabilidade do seu time. Sem equipe para operar um serviço crítico, o gerenciado costuma ser a melhor escolha.

Por que autenticação é a parte do sistema que menos se deve improvisar

Uma falha no relatório de vendas gera um número errado. Uma falha no login entrega a conta de alguém para outra pessoa. Por isso a autenticação concentra um tipo de risco diferente do resto do sistema.

O que parece simples esconde uma lista longa de detalhes:

• Armazenar senhas com algoritmo adequado, nunca em texto puro nem com criptografia reversível.
• Recuperação de senha sem permitir que alguém descubra quais e-mails estão cadastrados ou sequestre a conta pelo link de redefinição.
• Bloqueio contra tentativas repetidas, sem travar o usuário legítimo para sempre.
• Sessões que expiram, que podem ser encerradas quando o funcionário sai e que não ficam válidas por meses no celular de alguém.
• Segundo fator (código no aplicativo, chave física, notificação) e o processo de recuperação quando a pessoa perde o celular.
• Registro de acessos que responda, meses depois, quem entrou, de onde e quando.

Cada item tem armadilhas conhecidas, e boa parte dos incidentes acontece justamente nas bordas: o link de recuperação que não expira, o token que nunca é revogado, a API que confia em qualquer cabeçalho. Tratamos alguns desses erros em segurança de APIs: os erros mais comuns em produção.

Nada disso exige um produto de identidade em todo sistema. Exige alguém responsável por esses detalhes, hoje e daqui a alguns anos.

Login próprio: quando o framework resolve

"Login próprio" raramente quer dizer escrever autenticação do zero, e não deveria. Os frameworks web maduros trazem módulos de autenticação prontos, testados por muita gente, com armazenamento de senha, sessão e recuperação já resolvidos. Usar esse módulo, sem inventar criptografia, é a forma responsável de ter login dentro da aplicação.

Esse caminho funciona bem quando:

• Existe um sistema só, ou sistemas que não precisam compartilhar usuários.
• O público é conhecido e pequeno, como a equipe interna ou um grupo fechado de clientes.
• As exigências são simples: e-mail e senha, talvez um segundo fator, perfis de acesso dentro da própria aplicação.
• Há um time que mantém o sistema e acompanha as atualizações de segurança do framework.

Vantagens reais: nenhum fornecedor a mais e controle total da experiência e dos dados.

O custo aparece com o tempo. Cada pedido novo (login com Google, segundo fator, integração com o diretório de um cliente, login único com outro sistema) vira desenvolvimento. E a responsabilidade pela segurança do fluxo inteiro fica com quem mantém o código.

A alternativa que muita empresa esquece: o diretório que já existe

Para sistemas internos, há um meio-termo frequente. Se a empresa já usa Microsoft 365 ou Google Workspace, os funcionários já têm uma identidade corporativa, com senha, segundo fator e desligamento centralizados. O sistema interno pode simplesmente confiar nessa identidade, usando padrões abertos como OpenID Connect.

O ganho é grande: quando alguém sai da empresa, a conta é desativada num lugar só e o acesso ao sistema cai junto. Explicamos esse efeito em login único (SSO) e 2FA. O sistema continua cuidando apenas de uma coisa: o que cada pessoa pode fazer lá dentro.

Provedores gerenciados: Auth0, Cognito e Entra ID

Provedores de identidade gerenciados são serviços em nuvem, no modelo SaaS, que assumem o fluxo de login: cadastro, senha, recuperação, segundo fator, login social, sessões e registro de eventos. O sistema da empresa deixa de guardar senhas e passa a receber do provedor a confirmação de quem é o usuário.

Em linhas gerais:

• Auth0 é uma plataforma de identidade voltada a desenvolvedores, muito usada para o login de clientes em aplicações web e móveis.
• Amazon Cognito é o serviço de identidade da AWS, que se encaixa naturalmente em sistemas já hospedados nessa nuvem.
• Microsoft Entra ID é o serviço de identidade da Microsoft, muito presente em empresas que usam Microsoft 365, com uma oferta voltada também a usuários externos.

Todos trabalham com padrões abertos de identidade e oferecem APIs e documentação para integração. Os recursos específicos, limites e condições comerciais mudam com frequência, então confirme diretamente com cada fornecedor o que está disponível hoje para o seu caso.

O que um provedor gerenciado faz bem:

• Tira a senha do seu banco de dados. Menos dado sensível guardado, menos superfície de ataque.
• Entrega o básico bem feito sem desenvolvimento: recuperação, segundo fator, bloqueio de tentativas, login social.
• Centraliza vários sistemas. O mesmo usuário entra no portal, no aplicativo e na área administrativa com uma conta só.
• Recebe atualizações de segurança do lado do fornecedor, sem que o seu time precise reescrever o fluxo de login.

Onde pede atenção:

• Dependência do fornecedor. Migrar usuários de um provedor para outro é possível, mas trabalhoso, principalmente as senhas. Vale planejar a saída antes de entrar.
• Custo que cresce com o uso. O modelo comercial costuma acompanhar a quantidade de usuários ou de recursos. Simule o cenário de crescimento com o fornecedor antes de decidir.
• Personalização da experiência. As telas de login podem ser ajustadas, mas dentro do que cada produto permite.
• Onde ficam os dados. Para dados de clientes pessoa física, verifique a região de armazenamento e as cláusulas de tratamento à luz da LGPD. O tema está em dados na nuvem no Brasil e LGPD.

Keycloak e a opção auto-hospedada

Keycloak é um software de código aberto de gestão de identidade e acesso. Ele cumpre o mesmo papel de um provedor gerenciado (login centralizado, login único entre sistemas, segundo fator, federação com diretórios corporativos), só que roda em infraestrutura da própria empresa ou da nuvem que ela contrata.

Faz sentido quando:

• Há exigência de manter a identidade sob controle próprio, por política interna, contrato ou setor regulado.
• Existem muitos usuários, e o modelo de cobrança por usuário de um serviço gerenciado pesaria no orçamento.
• A personalização é profunda, com fluxos de cadastro e regras de federação específicas.
• Já existe um time de infraestrutura acostumado a operar serviços críticos.

O ponto que costuma ser subestimado: "gratuito" se refere à licença, não à operação. Keycloak vira um sistema crítico da empresa. Se ele cair, ninguém entra em nenhum sistema. Alguém precisa cuidar de atualizações de versão, correções de segurança, backup, alta disponibilidade, monitoramento e da configuração, que é extensa. Quem escolhe auto-hospedar escolhe também assumir essa rotina.

Keycloak ou Auth0: o que muda na prática

Os dois resolvem o mesmo problema e falam os mesmos padrões abertos (OpenID Connect, OAuth 2.0 e SAML). Para o sistema que consome o login, a integração é parecida. A diferença está no que acontece por trás, no dia a dia:

• Atualizações de segurança. No Auth0, o fornecedor aplica. No Keycloak, alguém do seu time acompanha os avisos do projeto, testa a nova versão em homologação e atualiza a produção, de preferência sem derrubar o login de todos os sistemas.
• Disponibilidade. No serviço gerenciado, a disponibilidade é compromisso do fornecedor, nos termos do contrato. No Keycloak, ela depende da arquitetura que você montar: mais de uma instância, banco de dados com backup testado e monitoramento com alerta.
• Previsibilidade de custo. O gerenciado tem uma fatura que cresce com usuários e recursos contratados, fácil de prever no início e que precisa ser simulada para o cenário de crescimento. O Keycloak tem custo de servidor e, principalmente, de horas de operação, que não aparecem numa fatura, mas existem.
• Extensões. Os dois permitem adaptar fluxos de login e cadastro. No gerenciado, dentro dos pontos de extensão que o produto oferece; no Keycloak, com mais liberdade, inclusive para escrever extensões próprias, o que também vira código a manter a cada atualização.
• Suporte. No gerenciado, há o suporte do fornecedor, conforme o plano. No Keycloak, a referência é a documentação e a comunidade do projeto, ou um parceiro contratado para isso.

Uma regra prática ajuda em qualquer dos dois: integre os sistemas usando os padrões abertos, e não recursos exclusivos de um produto. Assim, se um dia for preciso trocar de provedor, a mudança fica concentrada na migração dos usuários, e não em reescrever o login de cada aplicação.

Usuários internos, clientes e parceiros: identidades diferentes

Boa parte da confusão nessa decisão vem de tratar como iguais públicos que têm necessidades distintas.

Funcionários. Já possuem identidade corporativa. O ideal é que entrem com ela e que o desligamento seja feito num lugar só. Raramente faz sentido criar mais uma senha para eles.

Clientes. Cadastram-se sozinhos, esquecem a senha, querem entrar com Google ou Apple, usam o aplicativo e o portal. Aqui pesam experiência de cadastro, recuperação de conta e escala. É o cenário em que um provedor gerenciado costuma render mais. Se o sistema é um portal do cliente, essa decisão aparece logo no início.

Parceiros e clientes corporativos. Uma distribuidora ou um cliente grande quer que os funcionários dele acessem o seu sistema com a conta da empresa dele, e que o acesso caia quando alguém sai de lá. Isso exige federação: o seu sistema passa a confiar no diretório de outra empresa. Montar isso no login próprio é trabalhoso; provedores de identidade e o Keycloak foram feitos para esse tipo de arranjo.

Sistemas e integrações. Outro sistema que consome a sua API não é uma pessoa e não deve usar login de pessoa. Precisa de credenciais próprias, com escopo limitado e rotação. O tema aparece em como criar uma API para parceiros e clientes.

Uma separação importante vale para todos os casos: autenticação diz quem é a pessoa; autorização diz o que ela pode fazer. O provedor de identidade resolve bem a primeira parte. As permissões finas (qual filial, qual contrato, qual valor de aprovação) continuam sendo regra de negócio do sistema, e precisam de desenho cuidadoso, como discutimos em perfis de acesso e trilha de auditoria.

Tabela comparativa: login próprio x provedor gerenciado x Keycloak

Quando escolher cada um

Login do próprio framework

• Existe um sistema, sem plano concreto de outros que compartilhem usuários.
• O público é interno ou um grupo pequeno e conhecido.
• Não há pedido de login social nem de federação com clientes.
• O time que mantém o sistema acompanha atualizações de segurança com regularidade.
• Se o público for só de funcionários e a empresa já usa Microsoft 365 ou Google Workspace, prefira entrar com essa identidade em vez de criar senhas novas.

Provedor gerenciado

• Há ou haverá vários sistemas (portal, aplicativo, área administrativa) com os mesmos usuários.
• Clientes se cadastram sozinhos e esperam login social e recuperação de conta sem atrito.
• Clientes corporativos pedem para entrar com a conta da empresa deles.
• O time é enxuto e não deveria gastar energia operando identidade.
• Auditoria ou contrato exigem segundo fator e registro de acessos que a empresa não quer construir.

Para muitas empresas médias, esta é a escolha mais sensata: o produto pronto faz bem uma coisa que não diferencia o negócio de ninguém.

Keycloak auto-hospedado

• Política interna, contrato ou regulação exigem a identidade em infraestrutura própria.
• O volume de usuários torna o custo de um serviço gerenciado difícil de sustentar.
• Já existe um time capaz de operar serviços críticos com monitoramento, backup e plano de atualização.
• A empresa aceita que o login passe a ser um sistema próprio, com o cuidado que isso exige.

Cuidados que valem para qualquer caminho

• Não guarde senha onde não precisa. Se um provedor cuida disso, o seu banco não deveria ter cópia.
• Valide o token no servidor, sempre. A API precisa conferir assinatura, validade e destinatário de cada requisição, sem confiar no que o aplicativo diz.
• Separe credenciais de sistemas das de pessoas e mantenha segredos fora do código, como explicamos em gestão de segredos.
• Registre eventos de acesso e defina por quanto tempo guardá-los, com atenção à LGPD.
• Coloque autenticação no checklist do fornecedor. Ela deve constar das exigências de desenvolvimento seguro e ser testada antes de ir para produção.

Perguntas frequentes

O Keycloak é gratuito?

A licença do Keycloak é gratuita, por ser código aberto, mas a operação não. O Keycloak roda em servidores da empresa e vira um sistema crítico: alguém precisa cuidar de atualizações de segurança, backup, alta disponibilidade, monitoramento e configuração. O custo aparece em infraestrutura e em horas de operação, mesmo sem nenhuma fatura de licença.

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

Autenticação confirma quem é a pessoa; autorização define o que ela pode fazer dentro do sistema. Um provedor de identidade como Auth0 ou Keycloak resolve bem a autenticação, mas as permissões finas, como qual filial, qual contrato ou qual valor de aprovação, continuam sendo regra de negócio do próprio sistema e precisam de desenho cuidadoso.

O que é login único (SSO)?

Login único, ou SSO, é o recurso em que o usuário entra uma vez e acessa vários sistemas com a mesma conta, como portal, aplicativo e área administrativa. Para funcionários, o login único costuma usar a identidade corporativa do Microsoft 365 ou do Google Workspace, o que permite cortar o acesso a todos os sistemas num lugar só.

Dá para migrar do Auth0 para o Keycloak depois?

Dá, mas é trabalhoso, principalmente na migração das senhas dos usuários. A troca de provedor de identidade fica bem mais simples quando os sistemas se integram por padrões abertos, como OpenID Connect, OAuth 2.0 e SAML, sem depender de recursos exclusivos de um produto. Vale planejar essa saída antes de escolher o provedor.

É seguro fazer o login do sistema por conta própria?

Sim, desde que o login use o módulo de autenticação maduro do framework, sem inventar criptografia, e o time acompanhe as atualizações de segurança. Escrever autenticação do zero não é recomendado. Os riscos ficam nos detalhes: armazenamento de senha, recuperação de conta, expiração de sessões, bloqueio de tentativas e registro de acessos.

Como a Pervian Tech ajuda a decidir e a desenhar a identidade dos sistemas

Começamos por um diagnóstico inicial gratuito: quantos sistemas existem e estão previstos, quem acessa cada um (funcionários, clientes, parceiros, integrações), que diretório a empresa já usa e quem vai manter o fluxo de identidade nos próximos anos. Com isso na mesa, a recomendação costuma ficar clara.

Quando o login do framework ou o diretório corporativo resolvem, dizemos isso e evitamos um fornecedor a mais. Quando um provedor gerenciado atende, recomendamos o produto pronto e fazemos a integração com os sistemas. Quando há exigência de controle próprio, desenhamos e implantamos o Keycloak com a rotina de operação que ele precisa. Em todos os casos, cuidamos da parte que é sempre sob medida: perfis, permissões e trilha de auditoria alinhados à estrutura da empresa. Esse desenho faz parte do nosso trabalho de arquitetura de software.

O investimento é definido sob consulta, depois de entender o cenário. Outros textos sobre o tema estão na categoria segurança e LGPD. Se cada sistema da sua empresa tem um login diferente, ou se clientes já pedem para entrar com a conta deles, conte para nós como é hoje.