🔐 Auth vs AuthZ - Diferenca Fundamental
Autenticacao e autorizacao sao dois conceitos que muitos desenvolvedores confundem, mas que resolvem problemas completamente diferentes. Autenticacao (AuthN) responde a pergunta "quem e voce?". Autorizacao (AuthZ) responde "o que voce pode fazer?". Toda aplicacao SaaS precisa dos dois, e confundir um com o outro e uma das fontes mais comuns de vulnerabilidades de seguranca.
Pense assim: quando voce mostra seu RG na portaria de um predio, isso e autenticacao. O seguranca confirma que voce e quem diz ser. Quando voce tenta entrar em um andar especifico e o elevador exige um cartao de acesso, isso e autorizacao. Voce ja provou quem e, mas agora o sistema precisa verificar se voce tem permissao para aquele recurso. Um SaaS funciona da mesma forma: primeiro autentica o usuario, depois verifica se ele tem permissao para a acao que esta tentando executar.
Conceito Principal
Autenticacao (AuthN) e o processo de verificar a identidade de um usuario. Os metodos mais comuns sao: email + senha, OAuth (Google, GitHub), magic links, passkeys, e autenticacao biometrica. Quando um usuario faz login, ele esta se autenticando. O resultado da autenticacao e geralmente um token (JWT) ou uma sessao que identifica aquele usuario.
Autorizacao (AuthZ) e o processo de verificar se um usuario autenticado tem permissao para acessar um recurso ou executar uma acao. O metodo mais comum e RBAC (Role-Based Access Control), onde usuarios sao atribuidos a roles (admin, user, viewer) e cada role tem um conjunto de permissoes. Outros modelos incluem ABAC (Attribute-Based) e ReBAC (Relationship-Based).
Na pratica, autenticacao acontece uma vez (no login) e autorizacao acontece em cada request. Um usuario pode estar autenticado (logado) mas nao autorizado para uma acao especifica (ex: tentar acessar o painel de admin sendo um usuario comum). Seu sistema precisa tratar ambos os cenarios de forma independente e robusta.
Vulnerabilidades Mais Comuns
das brechas de seguranca em apps web sao por falhas de autorizacao (OWASP 2025)
Broken Object Level Authorization: vulnerabilidade #1 em APIs (OWASP API Top 10)
dos SaaS que sofreram data breach tinham falhas de AuthZ, nao AuthN
Insecure Direct Object Reference: acessar dados de outro usuario mudando um ID na URL
Dica Pratica
Use servicos especializados para autenticacao (Clerk, Auth.js, Supabase Auth, Firebase Auth) em vez de construir do zero. O login e a parte mais sensivel do sistema e servicos dedicados ja lidam com hashing de senhas, rate limiting, 2FA, e sessoes de forma segura. Construir isso do zero e uma receita para vulnerabilidades.
Ja a autorizacao geralmente precisa ser custom, porque depende da logica de negocio do seu SaaS. Defina suas roles e permissoes cedo no projeto, documente a permission matrix, e implemente checks de autorizacao em TODAS as rotas e endpoints, nao apenas no frontend.
Fazer
- ✓Separar claramente AuthN e AuthZ na sua arquitetura
- ✓Usar servicos especializados para autenticacao
- ✓Verificar autorizacao no backend, nunca confiar apenas no frontend
- ✓Documentar a permission matrix antes de implementar
Evitar
- ✗Implementar hash de senhas manualmente (use bcrypt ou argon2)
- ✗Confiar que esconder um botao no frontend e "autorizacao"
- ✗Armazenar senhas em texto puro ou com MD5/SHA1
- ✗Tratar autenticacao e autorizacao como a mesma coisa
🎫 JWT e Tokens
JSON Web Tokens (JWT) sao o padrao dominante para autenticacao em APIs modernas. Um JWT e basicamente um pacote de informacoes assinado digitalmente que o servidor emite quando o usuario faz login. Esse token viaja em cada request subsequente, permitindo que o servidor identifique o usuario sem precisar consultar o banco de dados a cada chamada.
A beleza do JWT e que ele e stateless: o servidor nao precisa manter uma sessao em memoria. Toda a informacao necessaria esta dentro do proprio token. Isso facilita a escalabilidade horizontal, ja que qualquer instancia do servidor pode validar o token independentemente. Mas essa mesma caracteristica traz desafios serios de seguranca que voce precisa entender antes de implementar.
Anatomia de um JWT
Um JWT e composto por tres partes separadas por pontos: Header.Payload.Signature. Cada parte e um JSON codificado em Base64URL.
Header
Contem o tipo do token (JWT) e o algoritmo de assinatura (HS256, RS256). Exemplo: {"alg": "HS256", "typ": "JWT"}. O algoritmo define como a signature e calculada. HS256 usa uma chave secreta compartilhada; RS256 usa um par de chaves publica/privada.
Payload
Contem os "claims" (afirmacoes sobre o usuario). Claims padrao incluem: sub (subject/user ID), iat (issued at), exp (expiration), iss (issuer). Voce pode adicionar claims customizados como role, org_id, plan.
Signature
E o HMAC ou RSA do header + payload usando a chave secreta. Garante que o token nao foi adulterado. Se alguem mudar qualquer byte do header ou payload, a signature nao bate e o token e rejeitado. Nunca exponha sua chave secreta no frontend ou em repositorios publicos.
// Exemplo de payload decodificado:
{
"sub": "user_abc123",
"email": "joao@example.com",
"role": "admin",
"org_id": "org_xyz",
"iat": 1710000000,
"exp": 1710003600
}
Estrategia de Tokens: Access + Refresh
A pratica padrao em SaaS modernos e usar dois tokens: um Access Token de vida curta (15-60 minutos) e um Refresh Token de vida longa (7-30 dias). O access token e enviado em cada request. Quando expira, o frontend usa o refresh token para obter um novo access token sem forcar o usuario a fazer login novamente.
expiracao recomendada para access tokens em aplicacoes sensiveis
expiracao tipica de refresh tokens com rotacao automatica
cookies httpOnly + Secure + SameSite=Strict para armazenar tokens
cada uso do refresh token gera um novo, invalidando o anterior
Dica Pratica: Armazenamento Seguro
NUNCA armazene JWTs em localStorage. Qualquer script XSS pode ler localStorage e roubar o token. A abordagem mais segura e armazenar tokens em cookies httpOnly, que nao sao acessiveis via JavaScript. Combine com os flags Secure (HTTPS only) e SameSite=Strict (previne CSRF).
Se voce usa um servico como Clerk ou Supabase Auth, eles ja gerenciam isso corretamente. Se esta implementando manualmente, use a library jose (JavaScript) ou PyJWT (Python) para criar e validar tokens. Sempre valide a signature, o issuer, e a expiracao em cada request.
Fazer
- ✓Usar access tokens curtos (15-60 min) + refresh tokens longos
- ✓Armazenar tokens em cookies httpOnly Secure SameSite
- ✓Implementar rotacao de refresh tokens
- ✓Incluir apenas claims essenciais no payload do JWT
Evitar
- ✗Guardar JWT em localStorage (vulneravel a XSS)
- ✗Usar tokens sem expiracao ou com expiracao muito longa
- ✗Colocar dados sensiveis no payload (senhas, dados pessoais)
- ✗Usar o algoritmo "none" ou HS256 com chave fraca
👥 RBAC - Role-Based Access Control
RBAC e o modelo de autorizacao mais usado em SaaS porque equilibra simplicidade com flexibilidade. Em vez de definir permissoes para cada usuario individualmente (o que nao escala), voce define roles (papeis) e atribui permissoes a esses roles. Cada usuario recebe uma ou mais roles, herdando automaticamente todas as permissoes associadas.
A maioria dos SaaS usa entre 3 e 5 roles. O modelo mais comum e: Admin (acesso total), Member/User (acesso padrao), Viewer (somente leitura). Conforme o SaaS cresce, voce pode adicionar roles como Billing Admin, Team Lead, ou roles customizaveis. O importante e comecar simples e expandir conforme a necessidade real.
Permission Matrix: Como Estruturar
Uma permission matrix mapeia roles contra recursos e acoes. Cada celula indica se aquela role pode executar aquela acao naquele recurso. Essa matrix e o documento-fonte de toda a logica de autorizacao do seu SaaS.
| Recurso / Acao | Admin | User | Viewer |
|---|---|---|---|
| Projetos: criar | ✓ | ✓ | ✗ |
| Projetos: editar | ✓ | ✓ | ✗ |
| Projetos: deletar | ✓ | ✗ | ✗ |
| Projetos: visualizar | ✓ | ✓ | ✓ |
| Usuarios: gerenciar | ✓ | ✗ | ✗ |
| Billing: acessar | ✓ | ✗ | ✗ |
| Settings: editar | ✓ | ✗ | ✗ |
Heranca de roles: Viewer herda permissoes basicas. User herda tudo de Viewer + permissoes de edicao/criacao. Admin herda tudo de User + permissoes administrativas. Esse modelo hierarquico simplifica a manutencao.
Implementacao em Codigo
A forma mais limpa de implementar RBAC e definir as permissoes como constantes e criar funcoes de verificacao reutilizaveis. Veja um exemplo pratico da estrutura:
// permissions.ts
const ROLES = {
ADMIN: 'admin',
USER: 'user',
VIEWER: 'viewer'
};
const PERMISSIONS = {
[ROLES.VIEWER]: ['project:read'],
[ROLES.USER]: ['project:read', 'project:create', 'project:update'],
[ROLES.ADMIN]: ['project:read', 'project:create', 'project:update',
'project:delete', 'user:manage', 'billing:access', 'settings:edit']
};
function hasPermission(role: string, permission: string): boolean {
return PERMISSIONS[role]?.includes(permission) ?? false;
}
Dica Pratica: Comece com 3 Roles
Nao crie 15 roles antes de ter usuarios. Comece com Admin, User, e Viewer. A maioria dos SaaS em estagio inicial funciona perfeitamente com essas tres roles. Adicione mais roles quando a demanda real surgir, nao quando voce imaginar que talvez um dia precisara.
Armazene a role do usuario tanto no JWT (para verificacao rapida no frontend) quanto no banco de dados (como fonte de verdade para o backend). Se a role mudar, o JWT antigo continua valido ate expirar, entao use access tokens curtos (15 min) para que mudancas de role se propaguem rapidamente.
Fazer
- ✓Criar uma permission matrix antes de escrever qualquer codigo
- ✓Usar constantes tipadas para roles e permissoes
- ✓Implementar heranca de roles para simplificar a gestao
- ✓Testar cada combinacao role + acao com testes automatizados
Evitar
- ✗Hardcodar permissoes em cada rota individualmente (use middleware)
- ✗Criar roles demais antes de ter demanda real
- ✗Misturar logica de negocio com logica de autorizacao
- ✗Confiar apenas no JWT para autorizacao (sempre checar no DB para acoes criticas)
🛡️ Rotas Protegidas
Rotas protegidas sao endpoints (no backend) ou paginas (no frontend) que so podem ser acessados por usuarios autenticados e/ou autorizados. Proteger rotas e a implementacao pratica de tudo que discutimos sobre AuthN e AuthZ. E onde a teoria vira codigo real.
A protecao de rotas acontece em duas camadas: no backend (API middleware) e no frontend (page guards / route protection). As duas sao necessarias. O backend e a camada de seguranca real: sem ele, qualquer pessoa com um curl ou Postman acessa seus endpoints. O frontend e a camada de experiencia: ele evita que o usuario veja paginas que ele nao deveria ver, melhorando a UX e reduzindo requests desnecessarios.
Protecao em Camadas
API Middleware Guard (Backend)
Um middleware que intercepta cada request antes de chegar ao handler da rota. Extrai o JWT do header Authorization ou cookie, valida a signature e expiracao, decodifica o payload, e injeta o usuario no contexto do request. Se o token for invalido ou ausente, retorna 401 Unauthorized.
// middleware/auth.ts (Express)
export function requireAuth(req, res, next) {
const token = req.cookies.access_token;
if (!token) return res.status(401).json({error: 'Not authenticated'});
try {
const decoded = jwt.verify(token, process.env.JWT_SECRET);
req.user = decoded;
next();
} catch (err) {
return res.status(401).json({error: 'Invalid token'});
}
}
Role-Based Middleware (Backend)
Apos autenticar, um segundo middleware verifica se o usuario tem a role necessaria para a rota. Isso separa AuthN de AuthZ em middleware independentes e reutilizaveis.
// middleware/authorize.ts
export function requireRole(...roles: string[]) {
return (req, res, next) => {
if (!roles.includes(req.user.role)) {
return res.status(403).json({error: 'Forbidden'});
}
next();
};
}
// Uso:
app.delete('/api/projects/:id', requireAuth, requireRole('admin'), deleteProject);
Page-Level Protection (Frontend)
No frontend (React/Next.js), use Higher-Order Components, route guards, ou middleware de pagina para verificar autenticacao antes de renderizar. Se o usuario nao esta logado, redirecione para /login. Se nao tem permissao, redirecione para /403 ou mostre uma mensagem de acesso negado. No Next.js App Router, use middleware.ts para protecao server-side.
Conditional Rendering (Frontend)
Alem de proteger rotas inteiras, esconda elementos UI baseado na role do usuario. Botoes de delete so aparecem para admins. Links para billing so aparecem para roles com permissao. Isso melhora a UX, mas nao e seguranca: a protecao real esta no backend.
Fluxo Completo de uma Request Protegida
1. Cliente envia request com cookie/header contendo o access token
2. Auth Middleware extrai e valida o token. Se invalido: 401. Se valido: injeta user no request.
3. Role Middleware verifica se user.role tem permissao para a acao. Se nao: 403.
4. Route Handler executa a logica de negocio com a garantia de que o usuario esta autenticado e autorizado.
5. Resource Check (opcional mas recomendado) verifica se o usuario tem acesso ao recurso especifico (ex: e dono do projeto que esta tentando editar).
Dica Pratica: Redirect Logic
Quando um usuario nao autenticado tenta acessar uma rota protegida, salve a URL original antes de redirecionar para /login. Apos o login, redirecione de volta para a URL original. Isso melhora dramaticamente a UX. No Next.js: redirect(`/login?callbackUrl=${encodeURIComponent(request.url)}`).
Diferencie 401 (nao autenticado) de 403 (autenticado mas nao autorizado) tanto na API quanto na UI. Para 401, redirecione para login. Para 403, mostre uma pagina de "Acesso Negado" que explique por que e sugira contatar o admin. Tratar ambos como um redirect generico confunde o usuario.
Fazer
- ✓Proteger TODAS as rotas de API que acessam dados privados
- ✓Separar middleware de AuthN e AuthZ em funcoes reutilizaveis
- ✓Implementar redirect com callbackUrl apos login
- ✓Verificar ownership de recursos alem de roles (BOLA prevention)
Evitar
- ✗Proteger rotas apenas no frontend (backend e obrigatorio)
- ✗Esquecer de proteger rotas de API usadas por AJAX/fetch
- ✗Retornar 200 com body vazio em vez de 401/403 correto
- ✗Duplicar logica de autorizacao em cada handler (use middleware)
⚙️ Middleware de Seguranca
Alem de autenticacao e autorizacao, seu SaaS precisa de uma camada de middleware de seguranca que protege contra ataques comuns na web. CORS, CSP, HTTPS enforcement, e security headers sao os pilares dessa protecao. Negligenciar qualquer um deles deixa brechas que atacantes exploram rotineiramente.
A boa noticia e que a maioria dessas protecoes pode ser implementada com configuracao, nao com codigo complexo. Bibliotecas como helmet (Node.js) configuram a maioria dos security headers com uma linha de codigo. O importante e entender o que cada header faz para configurar corretamente em vez de aceitar defaults cegamente.
Os 4 Pilares da Seguranca Web
CORS (Cross-Origin Resource Sharing)
CORS controla quais dominios podem fazer requests para sua API. Sem CORS configurado, qualquer site pode chamar sua API. Com CORS, voce define uma whitelist de origens permitidas. Para SaaS, permita apenas seu dominio frontend (ex: app.seusite.com) e bloqueie todo o resto.
// CORS config (Express)
app.use(cors({
origin: ['https://app.seusite.com'],
credentials: true,
methods: ['GET', 'POST', 'PUT', 'DELETE'],
allowedHeaders: ['Content-Type', 'Authorization']
}));
CSP (Content Security Policy)
CSP define quais recursos (scripts, estilos, imagens, fontes) o browser pode carregar na sua pagina. E a defesa primaria contra XSS (Cross-Site Scripting). Uma CSP bem configurada impede que scripts injetados por atacantes sejam executados, mesmo que consigam inserir HTML malicioso na pagina.
HTTPS Enforcement
HTTPS encripta toda a comunicacao entre cliente e servidor. Em 2026, nao existe desculpa para nao usar HTTPS. Use o header HSTS (Strict-Transport-Security) para forcar o browser a sempre usar HTTPS, mesmo que o usuario digite http://. Servicos como Vercel, Railway e Cloudflare oferecem HTTPS automatico.
Security Headers
Headers HTTP que instruem o browser a se comportar de forma mais segura:
- X-Frame-Options: DENY - impede que sua pagina seja carregada em um iframe (previne clickjacking)
- X-Content-Type-Options: nosniff - impede o browser de "adivinhar" o tipo MIME de arquivos
- X-XSS-Protection: 1; mode=block - ativa o filtro XSS do browser (legacy, mas nao custa nada)
- Referrer-Policy: strict-origin-when-cross-origin - controla quanta informacao de referrer e enviada
- Permissions-Policy - desabilita APIs desnecessarias (camera, microfone, geolocation)
Setup Rapido com Helmet
A biblioteca helmet para Node.js/Express configura 11 security headers com uma unica linha de codigo. E o caminho mais rapido para uma configuracao de seguranca robusta.
// Instalacao: npm install helmet
import helmet from 'helmet';
app.use(helmet()); // Configura 11 headers de seguranca
// Customizar CSP:
app.use(helmet.contentSecurityPolicy({
directives: {
defaultSrc: ["'self'"],
scriptSrc: ["'self'", "https://cdn.stripe.com"],
styleSrc: ["'self'", "'unsafe-inline'"],
imgSrc: ["'self'", "data:", "https:"],
connectSrc: ["'self'", "https://api.stripe.com"]
}
}));
Dica Pratica: Teste seus Headers
Use o site securityheaders.com para analisar os headers de seguranca do seu SaaS apos deploy. Ele da uma nota (A+ a F) e explica exatamente o que falta. Objetivo: A+ antes de lancar para o publico. Demora 5 minutos para configurar e faz uma diferenca enorme.
Outra ferramenta util e o Mozilla Observatory (observatory.mozilla.org). Ele analisa nao so headers mas tambem configuracao de TLS, cookies, e outras praticas de seguranca. E gratuito e devolve um relatorio detalhado com recomendacoes especificas.
Fazer
- ✓Usar helmet ou equivalente desde o dia 1 do projeto
- ✓Configurar CORS com whitelist restrita (nunca origin: '*' em producao)
- ✓Forcar HTTPS via HSTS com max-age longo
- ✓Testar com securityheaders.com apos cada deploy
Evitar
- ✗Usar CORS com origin: '*' em producao (permite qualquer site)
- ✗Deixar CSP desabilitado "porque da conflito com scripts"
- ✗Aceitar HTTP em producao, mesmo como fallback
- ✗Ignorar security headers por "nao ser prioridade agora"
🛠️ Exercicio: RBAC Funcional
Hora de colocar tudo em pratica. Neste exercicio voce vai implementar um sistema completo de autenticacao e autorizacao com 3 roles, permission matrix, middleware de protecao, e rotas protegidas. Ao final, voce tera um backend funcional que autentica usuarios, emite JWTs, e controla acesso por roles.
O exercicio e desenhado para ser implementado com IA (Cursor, Claude Code, ou a ferramenta de sua escolha). Use o Vibe Coding: descreva a arquitetura, deixe a IA gerar o codigo, revise, ajuste, e itere. Foque em entender a logica, nao em decorar a sintaxe.
Passo a Passo do Exercicio
Setup do Projeto
Crie um projeto Node.js/Express (ou Next.js API Routes) com as seguintes dependencias:
- express - servidor HTTP
- jsonwebtoken - criacao e validacao de JWT
- bcrypt - hashing de senhas
- helmet - security headers
- cors - configuracao de CORS
Definir 3 Roles + Permission Matrix
Crie o arquivo permissions.ts com:
- Roles: admin, user, viewer
- Recursos: projects, users, billing, settings
- Acoes por recurso: read, create, update, delete
- Funcao hasPermission(role, permission) que retorna boolean
Implementar Auth Endpoints
Crie as rotas de autenticacao:
- POST /auth/register - cria usuario com senha hasheada (bcrypt)
- POST /auth/login - valida credenciais, retorna JWT (access + refresh)
- POST /auth/refresh - troca refresh token por novo access token
- POST /auth/logout - invalida o refresh token
Criar Middleware de AuthN + AuthZ
Implemente dois middleware separados: requireAuth (valida JWT, injeta user no request) e requireRole (verifica se user.role esta na lista de roles permitidos). Aplique-os nas rotas de forma composavel.
Rotas Protegidas por Role
Crie endpoints protegidos para testar cada role:
- GET /api/projects - viewer, user, admin (todos podem ler)
- POST /api/projects - user, admin (criar projeto)
- DELETE /api/projects/:id - admin only
- GET /api/admin/users - admin only
Testar com curl ou Postman
Registre 3 usuarios (um de cada role). Faca login com cada um. Teste acessar rotas que nao deveria (viewer tentando criar projeto, user tentando acessar admin). Verifique que os status codes sao corretos: 401 para nao autenticado, 403 para nao autorizado, 200 para sucesso.
Checklist de Entregaveis
Dica Pratica: Prompt para a IA
Use este prompt como ponto de partida com Claude Code ou Cursor: "Crie um servidor Express com autenticacao JWT (access + refresh tokens), 3 roles (admin, user, viewer), permission matrix, middleware de auth e autorizacao, e 4 rotas protegidas por role. Use bcrypt para senhas, helmet para security headers, e armazene usuarios em um array em memoria (nao precisa de banco de dados). Inclua endpoints de register, login, refresh, e logout."
Depois de gerar o codigo base, itere: "Adicione rate limiting no login (maximo 5 tentativas por minuto por IP)." Em seguida: "Adicione validacao de input com zod nos endpoints de register e login." A cada iteracao, voce reforca a seguranca sem complicar o exercicio inicial.
Fazer
- ✓Usar IA para gerar o boilerplate e focar na revisao
- ✓Testar cada cenario de permissao individualmente
- ✓Verificar que status codes estao corretos (401 vs 403)
- ✓Documentar a permission matrix como referencia
Evitar
- ✗Copiar o codigo sem entender o fluxo de autenticacao
- ✗Pular os testes manuais ("parece que funciona")
- ✗Adicionar banco de dados neste exercicio (mantenha simples)
- ✗Gastar tempo demais no frontend (o exercicio e backend-focused)
Resumo do Modulo 6.3
Voce agora entende os fundamentos de seguranca que todo SaaS precisa: autenticacao, autorizacao, JWT, RBAC, e middleware de protecao.