Spring Security sem complicação: entendendo como uma API se protege

Spring Security + Autenticação + Autorização + Keycloak.

Quando você começa a estudar segurança em APIs, pode achar que a lógica é basicamente:

Tem login e senha? Então está protegida!

Seria ótimo se fosse tão simples.

O problema é que descobrir quem está entrando é apenas uma parte da história.

Depois ainda precisamos descobrir o que essa pessoa pode fazer lá dentro.

E é justamente aqui que autenticação, autorização, Spring Security e Keycloak começam a aparecer.

Primeiro, imagine um condomínio

Você chega para visitar uma amiga que mora em um condomínio.

Na portaria, o segurança pergunta:

"Quem é você?"

Você informa seu nome, mostra um documento e ele confirma com a moradora.

Pronto. Sua identidade foi confirmada.

Isso é autenticação.

Agora imagine que, depois disso, você resolve aproveitar a oportunidade para entrar no apartamento do vizinho, acessar a sala da administração e dar uma passadinha na garagem para escolher um carro.

Não vai rolar.

Você foi autorizado a entrar no condomínio, mas isso não significa que pode acessar qualquer lugar.

Isso é autorização.

Na nossa API, a lógica é praticamente a mesma:

Autenticação = Quem é você?

Autorização = O que você pode fazer?

Só essa diferença já resolve uma das maiores confusões quando começamos a estudar segurança.

E o Spring Security entra onde?

Agora vamos transformar nosso condomínio em uma aplicação.

Imagine uma API de uma loja com estas áreas:

/produtos

/pedidos

/admin

Um cliente pode consultar produtos e fazer pedidos.

Já alguém com perfil de administrador pode ter acesso a outras funcionalidades.

O problema seria deixar qualquer pessoa fazer isso:

Cliente → /admin

E a aplicação responder:

"Pode entrar, fique à vontade."

Definitivamente não queremos isso.

O Spring Security ajuda nossa aplicação a controlar quem pode acessar cada recurso.

Podemos pensar nele como parte do sistema de segurança do nosso condomínio.

Ele verifica as regras antes de liberar determinados acessos.

Entrou? Então pega seu crachá

Agora aparece outro conceito muito comum quando falamos de APIs: token.

Imagine novamente o condomínio.

Depois que sua entrada é autorizada, você recebe um crachá de visitante.

Enquanto estiver lá dentro, não precisa voltar à portaria, mostrar seu documento e ligar para sua amiga toda vez que passar por uma porta.

Você apresenta seu crachá.

Na API acontece algo parecido.

Depois que o usuário comprova sua identidade, ele pode receber um token.

Nas próximas requisições, esse token acompanha o usuário:

Usuário faz login

↓

Identidade confirmada

↓

Recebe um token

↓

Faz uma nova requisição

↓

API verifica o token

↓

Acesso permitido ou bloqueado

Então, quando encontrar aquele token enorme pela primeira vez, não precisa olhar para ele como se fosse um código secreto da NASA.

Pense:

"Esse é o crachá digital desse usuário."

Já fica bem menos assustador.

Então para que serve o Keycloak?

Aqui surge uma dúvida muito comum:

Se já temos Spring Security, por que precisamos de Keycloak?

Voltando ao nosso condomínio, alguém precisa cuidar dos cadastros, identificar as pessoas e entregar os crachás.

É aí que o Keycloak pode entrar.

Ele pode centralizar tarefas relacionadas à identidade dos usuários, como autenticação, usuários, permissões e emissão de tokens.

Enquanto isso, nossa aplicação utiliza essas informações para decidir se determinado acesso será permitido.

De forma bem simplificada:

Usuário

↓

Keycloak
"Quem é você?"

↓

Token

↓

API + Spring Security
"Você pode entrar aqui?"

↓

SIM ou NÃO

Assim fica mais fácil perceber que Spring Security e Keycloak não precisam disputar o mesmo emprego.

Eles podem trabalhar juntos.

3 coisas para não se perder no Spring Security

1. Separe autenticação de autorização

Sempre lembre:

Autenticação identifica.

Autorização dá ou nega permissão.

Entrar na festa não significa ganhar a chave do camarote.

2. Pense no token como um crachá

Antes de mergulhar nas configurações, entenda para que ele existe.

O token ajuda a aplicação a reconhecer aquele usuário nas próximas requisições.

Depois você pode aprofundar como tudo isso funciona por baixo dos panos.

3. Entenda o fluxo antes de decorar código

Quando você vê uma configuração de Spring Security pela primeira vez, pode parecer que alguém resolveu juntar várias palavras difíceis só para testar sua paciência.

Por isso, antes de decorar qualquer configuração, responda:

Quem está tentando entrar?

Como essa pessoa comprova quem é?

O que ela pode acessar?

Quem vai validar isso?

Quando você entende essas quatro perguntas, o código deixa de parecer tão aleatório.

Segurança é muito mais do que colocar uma senha

Se você guardar uma ideia deste artigo, que seja esta:

Login não significa acesso liberado para tudo.

Uma aplicação precisa identificar o usuário e depois controlar aquilo que ele pode fazer.

É por isso que conceitos como autenticação, autorização, tokens, Spring Security e Keycloak aparecem tanto quando começamos a desenvolver APIs mais completas.

E talvez Spring Security não seja tão assustador quanto parece.

Às vezes você só precisava imaginar que estava tentando entrar em um condomínio muito bem administrado.

E você, já confundiu autenticação com autorização ou essa diferença sempre foi clara para você?

_____________________

Indicação de livro

Spring Security in Action

Autor: Laurentiu Spilca

Uma boa leitura para quem quer entender Spring Security com mais profundidade e descobrir o que acontece por trás das configurações que encontramos nos projetos.

E sim, depois de entender o porteiro, o crachá e quem pode entrar em cada lugar, o código começa a fazer bem mais sentido.