Keycloak além do login: autorização fina que escala com o negócio

Keycloak além do login: autorização fina que escala com o negócio

Colocar o Keycloak na frente da aplicação resolve autenticação. Autorização é outro problema, e costuma ser onde o sistema começa a apodrecer. Regras espalhadas em controllers, verificações duplicadas em serviços e um if (usuario.isAdmin()) que aparece em vinte arquivos diferentes são sintomas de que o modelo de permissões nunca foi desenhado.

Separe autenticação de autorização

O Keycloak entrega identidade, sessão e emissão de tokens. Ele não decide o que cada usuário pode fazer dentro do seu domínio de negócio, e não deveria.

A fronteira saudável é:

• O provedor de identidade diz quem é a pessoa e a quais grupos pertence

• A aplicação traduz isso em permissões concretas sobre recursos

Papéis de realm versus papéis de cliente

Papéis de realm descrevem funções organizacionais amplas, como administrador ou analista. Papéis de cliente descrevem o que a pessoa pode fazer naquela aplicação específica.

Misturar os dois cria um catálogo que ninguém consegue auditar depois de seis meses.

Escopos como contrato de API

Escopos são a forma mais subestimada de autorização. Em vez de verificar papéis dentro de cada endpoint, defina escopos que representam capacidades:

• pedidos:ler

• pedidos:aprovar

• relatorios:exportar

O token carrega o que o cliente pode fazer, e a API valida o escopo antes de executar a regra de negócio.

Autorização baseada em recursos

Quando a permissão depende do recurso e não só do papel, como no caso do gerente que só aprova pedidos da própria filial, o modelo precisa de atributos.

O Keycloak suporta isso via claims customizadas e services de autorização. A alternativa é manter uma camada de política na aplicação, avaliando atributos do token contra o recurso solicitado.

Erros que custam caro

Estas falhas são recorrentes e cada uma anula boa parte do investimento em identidade:

• Token com validade longa demais

• Refresh sem rotação

• Claims com dados sensíveis

• Verificação de assinatura desativada em ambiente interno

Onde isso encaixa em projetos reais

Sistemas sob medida que lidam com dados de clientes raramente podem tratar autorização como detalhe de implementação. O artigo Software sob medida: quando vale a pena investir mostra como segurança e conformidade entram desde o diagnóstico do projeto.

Para times que precisam revisar o modelo de acesso de um sistema já em produção, a assessoria técnica da ITCODE faz essa avaliação. E quando o sistema já está no ar e precisa de correções e monitoramento contínuos, a sustentação e modernização cobre esse ciclo.

Conclusão

Keycloak bem modelado é infraestrutura invisível: o time de produto pensa em capacidades, não em tokens. O trabalho inicial de desenhar papéis, escopos e atributos é o que evita que a autorização se torne o gargalo do próximo ciclo de crescimento.