Causa: Frontend recebeu segredo de longa duração
Melhoria: Prefira cookie HttpOnly para sessão web e reduza vida e escopo de credenciais.
Cookies, sessão e tokens
Quem autentica, quem emite e o que acontece quando expira
Objetivo
Distinguir cookie, sessão, access token, refresh token e autorização, observando expiração e roubo de credencial.
História
Cleiton entra pelo provedor corporativo. O provedor comprova identidade e o backend cria uma sessão ou aceita um access token. A API ainda recalcula se aquela identidade pode agir sobre a OS 742.
Hipótese a testar
Atividade do usuário não torna um access token eterno. Renovação é uma nova decisão controlada, e não a edição silenciosa do token antigo.
Pré-requisitos
- HTTP
- headers
- autenticação versus autorização
Simulador
Altere uma variável, antecipe o efeito e compare com o indicador. A escala mostra pressão relativa, não uma garantia de segurança.
Faixa controladaReveja o contrato e os testes antes de concluir.
Fluxo observado
- usuário
- provedor de identidade
- código + PKCE
- tokens/sessão
- API
- política de autorização
O que observar
- O emissor confiável cria e assina o token; o frontend não inventa credenciais válidas.
- HttpOnly impede JavaScript de ler o cookie; Secure limita envio a HTTPS; SameSite reduz envio entre sites.
- JWT assinado não é necessariamente criptografado: claims não devem conter segredos.
Erros comuns e melhoria
Causa: Backend confundiu identidade com permissão
Melhoria: Autorize cada recurso e função no servidor; negue por padrão.
Exercício guiado
- Desenhe login OIDC com Authorization Code + PKCE.
- Marque onde ficam access token, refresh token e cookie.
- Simule expiração com usuário ativo e descreva renovação, falha e logout.
Desafio independente
Projete revogação quando um celular corporativo for perdido, sem depender de esperar todo token expirar.
Evidência exigida
Diagrama de sequência e matriz de ameaças com roubo, replay, CSRF, XSS, expiração e revogação.