Autenticação e Gestão de Identidade

Se preferir começar por um resumo, peça um TL;DR ao ChatGPT ou ao Claude .

Autenticação e gestão de identidade são capacidades críticas: uma falha pode interromper o acesso a toda a plataforma ou expor dados e operações. Isso não significa, porém, que toda organização deva desenvolver seu próprio provedor de identidade.

Sob a ótica de Domain-Driven Design, identidade costuma ser um subdomínio genérico quando apenas sustenta o acesso às aplicações. Ela pode ser parte do core domain quando o modelo de identidade é uma fonte real de diferenciação, como em plataformas cuja proposta depende de identidade regulada, consentimento, administração delegada, prevenção de fraude ou relações complexas entre tenants.

Portanto, classificar identidade como genérica é uma decisão de contexto, não uma regra universal.

Decisão: adotar, operar ou desenvolver

Para um subdomínio genérico, a recomendação inicial é avaliar uma solução pronta, gerenciada ou auto-hospedada. Desenvolver internamente só se justifica quando os requisitos diferenciais não puderem ser atendidos com configuração, extensão ou integração aceitáveis.

Antes da escolha, registre:

protocolos e integrações necessários;
fontes de identidade e requisitos de federação;
modelo de tenants e de administração delegada;
requisitos regulatórios, de residência e retenção de dados;
ameaças relevantes e níveis de autenticação exigidos;
disponibilidade, RTO e RPO esperados;
capacidade da equipe para operar, atualizar e recuperar o serviço;
custo total, incluindo infraestrutura, suporte, atualização e migração;
extensões que podem criar dependência específica da solução.

O uso de OpenID Connect ou SAML reduz o acoplamento das aplicações ao provedor, mas não elimina lock-in. Temas, fluxos de autenticação, APIs administrativas, políticas e extensões proprietárias continuam gerando custo de migração.

Keycloak como candidato

O Keycloak é uma solução open source de Identity and Access Management (IAM). Ele é um candidato coerente quando a organização precisa de controle sobre a implantação, integração com diretórios ou provedores existentes e capacidade de configurar fluxos de autenticação — e aceita assumir sua operação.

Entre as capacidades documentadas estão:

Single Sign-On e Single Sign-Out;
clientes OpenID Connect e SAML;
federação com LDAP e Active Directory;
papéis de realm e de cliente;
autenticação com OTP e WebAuthn;
administração de usuários, grupos, clientes e sessões;
customização de temas e fluxos de autenticação;
execução em múltiplos nós com caches distribuídos.

Essa lista demonstra cobertura funcional, não adequação automática. A decisão deve ser validada contra os requisitos e a capacidade operacional do contexto.

Quando a opção perde força

Keycloak pode não ser a melhor escolha quando:

a equipe não pode manter banco, proxy, certificados, atualização, backup e recuperação do serviço;
o prazo favorece um serviço gerenciado e o custo recorrente é aceitável;
os requisitos dependem de funcionalidades externas ou regulatórias que exigiriam extensões extensas;
a organização não consegue sustentar os objetivos de disponibilidade e segurança de uma infraestrutura compartilhada.

Segmentação com realms

No Keycloak, um realm isola usuários, credenciais, papéis, grupos, clientes e configurações de autenticação. Um usuário pertence e autentica em um realm. Essa é uma fronteira forte e deve representar uma necessidade real de isolamento.

Separar um realm externo de um realm interno é uma opção válida quando existem fronteiras independentes de administração, identidade, política, auditoria ou ciclo de vida. Por exemplo:

Realm externo

usuários finais e aplicações públicas;
federação com provedores externos;
políticas e fluxos próprios para cadastro e recuperação;
escala e ciclo de vida distintos dos usuários internos.

Realm interno

equipes internas e aplicações de back-office;
federação com o diretório corporativo;
autenticação multifator compatível com o risco;
administração, auditoria e recuperação sob controles internos.

Essa divisão não deve ser aplicada apenas porque as aplicações têm públicos diferentes. Se as mesmas identidades precisam de SSO, governança e ciclo de vida comuns, um único realm com clientes, grupos, papéis e escopos separados pode ser mais simples.

Múltiplos realms também têm custos: configuração duplicada, usuários duplicados, integrações adicionais e experiência fragmentada entre fronteiras. A decisão deve registrar qual risco o isolamento reduz e por que os controles dentro de um único realm seriam insuficientes.

Restrição de acesso ao back-office

Um realm não limita acesso por rede de forma automática. Restrições a rede corporativa, VPN ou endereços permitidos devem ser aplicadas no proxy reverso, ingress, gateway ou firewall.

Em uma implantação exposta à internet:

publique somente os caminhos necessários para autenticação;
mantenha a interface e a API administrativas em acesso interno quando isso for compatível com a operação;
não exponha endpoints de métricas e saúde ao público;
configure hostname, TLS e cabeçalhos de proxy explicitamente;
impeça acesso direto ao Keycloak que contorne o proxy;
teste os controles a partir das redes permitidas e bloqueadas.

A documentação do Keycloak recomenda restringir no proxy os caminhos administrativos e os endpoints de autenticação do realm administrativo. Esses controles reduzem a superfície exposta, mas não garantem segurança por si sós.

Autenticação e autorização

O mecanismo de autenticação deve corresponder ao risco. Back-office e operações privilegiadas podem exigir MFA com OTP ou WebAuthn, mas a simples ativação de um segundo fator não encerra o trabalho. Também é necessário definir recuperação de conta, revogação de credenciais, proteção contra elevação de privilégio e procedimentos para perda do autenticador.

Para autorização:

use escopos e papéis mínimos nos tokens;
restrinja URIs de redirecionamento e origens de cada cliente;
limite duração de sessões e tokens conforme o risco;
revise contas administrativas e permissões delegadas;
mantenha decisões voláteis do domínio nos serviços ou em um componente de políticas apropriado.

O provedor pode transportar identidade, escopos e papéis. Regras como limite de crédito, aprovação de pedido ou acesso condicionado ao estado de uma entidade pertencem ao domínio que possui essas informações. Colocá-las no IAM pode acoplar a evolução do negócio à infraestrutura de identidade.

Disponibilidade e operação

Executar múltiplas instâncias não garante alta disponibilidade. O resultado depende também de banco de dados, caches, balanceador, DNS, certificados, capacidade, estratégia de atualização e topologia de falha.

Antes de produção, valide pelo menos:

falha e substituição de uma instância;
indisponibilidade e recuperação do banco;
persistência ou encerramento esperado das sessões;
rotação de chaves e certificados;
backup e restauração de dados e configurações;
atualização e rollback de versão;
comportamento do proxy e dos health checks;
capacidade sob pico e degradação de dependências;
emissão de eventos, logs e alertas úteis para investigação.

Os testes devem produzir evidências para os objetivos de disponibilidade, RTO e RPO definidos. Sem esses testes, “clustering” descreve uma configuração, não uma garantia operacional.

Critérios de decisão

Keycloak pode ser adotado quando um experimento ou avaliação comprovar que:

os fluxos críticos de login, logout, recuperação e federação funcionam;
os limites entre realms, clientes e papéis correspondem ao modelo de acesso;
os controles de rede bloqueiam interfaces e caminhos não públicos;
aplicações recebem apenas os escopos e papéis necessários;
backup, restauração, atualização e falha de instância atendem aos objetivos;
a equipe consegue operar e corrigir a plataforma no tempo requerido;
o custo total e o custo de saída são aceitáveis.

Se esses critérios não forem atendidos, compare uma oferta gerenciada, outra solução ou uma redução de escopo. A escolha deve permanecer reversível na medida compatível com o custo do sistema.

Referências

KEYCLOAK TEAM. Server Administration Guide. Disponível em: https://www.keycloak.org/docs/latest/server_admin/

KEYCLOAK TEAM. Configuring a reverse proxy. Disponível em: https://www.keycloak.org/server/reverseproxy

KEYCLOAK TEAM. Configuring Keycloak for production. Disponível em: https://www.keycloak.org/server/configuration-production

KEYCLOAK TEAM. High availability overview. Disponível em: https://www.keycloak.org/high-availability/introduction