# Autenticacao e autorizacao web: guia completo

> Autenticação e autorização web são processos distintos e complementares. Autenticação verifica a identidade do usuário, enquanto autorização determina os recursos e ações permitidos. Protocolos como OAuth 2.0 e OpenID Connect implementam esses conceitos em aplicações web. Erros comuns incluem confundir os dois processos e negligenciar validações de token.

*Bombou na Web · Tecnologia · 18 de julho de 2026 · Larissa Quintela*

Autenticacao verifica quem voce e; autorizacao define o que voce pode fazer. Neste guia, voce aprendera os conceitos, protocolos e passos praticos para implementar ambos em aplicacoes web, com exemplos reais e erros comuns a evitar.

## Como diferenciar autenticacao de autorizacao e implementar ambas na web?

Autenticacao e autorizacao web sao dois processos distintos, mas frequentemente confundidos. Autenticacao verifica **quem** o usuario e, tipicamente com login e senha, biometria ou SSO. Autorizacao define **o que** esse usuario pode fazer apos ser autenticado, quais recursos, endpoints ou acoes estao liberados. A promessa e que, dominando ambos, sua aplicacao fica segura e usavel. A evidencia: segundo o relatorio Verizon 2024, 74% das violacoes envolvem comprometimento de credenciais, muitas por autorizacao mal configurada.

Este guia cobre os protocolos mais usados (OAuth 2.0, JWT, SAML), as etapas praticas de implementacao e os erros que custam caro. Nao ha numero magico de seguranca, cada camada exige decisao de engenharia.

### Pre-requisitos

- Conhecimento basico de HTTP e APIs REST
- Familiaridade com uma linguagem de backend (Node.js, Python, Java)
- Um servidor web ou ambiente de desenvolvimento configurado

## Passo 1: Escolher o protocolo de autenticacao adequado ao cenario

Antes de codificar, defina o protocolo. Tres dominam o ecossistema web:

- OAuth 2.0: padrao para delegar acesso a recursos em nome do usuario (ex.: "Login com Google"). Nao e um protocolo de autenticacao _per se_, mas e usado com OpenID Connect para autenticar.
- JWT (JSON Web Token): formato de token compacto e auto-contido, ideal para APIs stateless. O servidor nao precisa manter sessoes; o token carrega as claims (dados do usuario e permissoes).
- SAML (Security Assertion Markup Language): protocolo baseado em XML, comum em ambientes corporativos e federacoes de identidade (ex.: integracao com Active Directory).

**Dica**: Para aplicacoes web modernas com frontend separado (SPA), OAuth 2.0 + JWT e a escolha mais leve e escalavel. SAML ainda e forte em legacy enterprise, mas a complexidade de parsing XML e maior.

**Erro comum**: usar JWT como sessao sem expiracao ou revogacao. Um JWT roubado vale ate expirar. Implemente refresh tokens e blacklist de tokens revogados.

## Passo 2: Implementar o fluxo de autenticacao (login e verificacao de identidade)

A autenticacao e a primeira barreira. O fluxo tipico:

- Usuario envia credenciais (email + senha) para o endpoint /login.
- Servidor valida as credenciais contra o banco de dados (hash da senha com bcrypt ou Argon2).
- Se valido, gera um token de acesso (JWT) com expiracao curta (15-60 minutos) e um refresh token (longo, armazenado em cookie httpOnly).
- O token e enviado ao frontend, que o inclui no header Authorization: Bearer nas requisicoes subsequentes.

**Dica**: Nunca armazene o JWT no localStorage, vulneravel a XSS. Use cookie httpOnly e secure para o refresh token, e mantenha o access token em memoria (variavel JS) ou em cookie com SameSite=Strict.

**Erro comum**: nao validar a assinatura do JWT no servidor. Qualquer um pode forjar um token se a chave secreta for fraca ou exposta. Use algoritmos assimetricos (RS256) em vez de simetricos (HS256) quando possivel, e nunca confie em tokens recebidos sem verificar a origem.

## Passo 3: Mapear permissoes e regras de autorizacao

Autorizacao comeca antes do codigo: e necessario modelar quem pode fazer o que. Duas abordagens principais:

- RBAC (Role-Based Access Control): usuarios tem papeis (ex.: admin, editor, viewer). Cada papel agrupa permissoes. Simples de implementar, mas rigido para cenarios complexos.
- ABAC (Attribute-Based Access Control): permissoes sao avaliadas com base em atributos do usuario, recurso e contexto (ex.: "usuario pode editar apenas documentos que criou"). Mais flexivel, mas exige motor de politicas (ex.: Open Policy Agent).

**Dica**: Comece com RBAC. So migre para ABAC quando o modelo de permissoes ficar insustentavel com papeis (mais de 20 papeis ou regras condicionais frequentes).

**Erro comum**: hardcodar permissoes no codigo. Toda mudanca exige deploy. Centralize as regras em um servico de autorizacao ou em um arquivo de configuracao versionado.

## Passo 4: Proteger endpoints com middleware de autorizacao

No backend, cada endpoint protegido deve passar por um middleware que:

- Extrai o token do header Authorization.
- Valida a assinatura e expiracao do JWT.
- Decodifica as claims (ex.: role, user_id).
- Verifica se o usuario tem permissao para a acao solicitada (ex.: role === 'admin' ou user_id === resource.owner_id).
- Se falhar, retorna HTTP 401 (token invalido) ou 403 (sem permissao).

Exemplo conceitual em Node.js com Express:

function authorize(requiredRole) { return (req, res, next) => { const token = req.headers.authorization?.split(' ')[1]; if (!token) return res.status(401).json({ error: 'Token ausente' }); try { const decoded = jwt.verify(token, process.env.JWT_SECRET); if (decoded.role !== requiredRole && decoded.role !== 'admin') { return res.status(403).json({ error: 'Acesso negado' }); } req.user = decoded; next(); } catch (err) { return res.status(401).json({ error: 'Token invalido' }); } }; }

**Dica**: Nao confie apenas no papel. Para recursos especificos (ex.: editar um post), verifique a propriedade do recurso no banco antes de autorizar.

**Erro comum**: esquecer de proteger endpoints de listagem ou busca. Um usuario comum pode enumerar registros de outros usuarios se a query nao filtrar por user_id.

## Passo 5: Gerenciar sessoes e tokens de forma segura

A seguranca nao termina na implementacao. Mantenha:

- Rotacao de chaves: troque a chave secreta do JWT periodicamente (ex.: a cada 90 dias) e mantenha versoes anteriores para tokens ainda validos.
- Revogacao de tokens: se um usuario for desligado, invalide todos os tokens ativos. Use um Redis com TTL para blacklist de JWT, ou force logout com incremento de token_version no banco.
- Rate limiting: evite brute force em endpoints de login. Limite tentativas por IP e por usuario (ex.: 5 tentativas por minuto).

**Dica**: Para logout, limpe o refresh token no servidor (delete do banco ou Redis) e instrua o frontend a descartar o access token. Sozinho, o access token expira em minutos.

**Erro comum**: nao implementar expiracao de refresh token. Um refresh token roubado pode gerar novos access tokens indefinidamente. Defina expiracao (ex.: 7 dias) e renovacao com rotation (novo refresh token a cada uso).

## Checklist final: o que voce implementou

- [ ] Protocolo de autenticacao definido (OAuth 2.0 + OpenID Connect, JWT ou SAML)
- [ ] Fluxo de login com hash de senha seguro (bcrypt/Argon2) e token JWT
- [ ] Modelo de autorizacao escolhido (RBAC ou ABAC)
- [ ] Middleware de autorizacao protegendo todos os endpoints relevantes
- [ ] Gerenciamento de tokens com expiracao, rotacao de chaves e revogacao
- [ ] Rate limiting em endpoints de autenticacao

## Perguntas frequentes sobre autenticacao e autorizacao web

### Qual a diferenca pratica entre autenticacao e autorizacao?

Autenticacao responde "quem e voce?" (ex.: login com email e senha). Autorizacao responde "o que voce pode fazer?" (ex.: um usuario comum pode ler, mas nao editar). Um sistema pode autenticar sem autorizar, mas sem autorizacao, qualquer usuario autenticado tem acesso total.

### OAuth 2.0 e um protocolo de autenticacao?

Nao exatamente. OAuth 2.0 e um framework de autorizacao, ele delega acesso a recursos. Para autenticacao, usa-se OpenID Connect, que e uma camada sobre OAuth 2.0 que adiciona um token de identidade (ID token). Muitos implementam OAuth 2.0 sozinho e tentam usar access token como prova de identidade, o que e inseguro.

### Quando usar JWT em vez de sessoes tradicionais?

JWT e ideal para APIs stateless e microservicos, onde nao se quer manter estado de sessao no servidor. Sessoes tradicionais (com cookie de sessao e armazenamento em Redis/banco) sao mais faceis de revogar e controlar, mas escalam pior em arquiteturas distribuídas.

### Como revogar um JWT se ele nao expirou?

JWT por design nao pode ser revogado apos emissao, a menos que o servidor mantenha uma blacklist (ex.: Redis com TTL). Alternativa: usar token_version no banco de dados do usuario, ao alterar a versao, todos os tokens antigos sao invalidados na verificacao.

### O que e RBAC e quando usar?

RBAC (Role-Based Access Control) atribui permissoes a papeis (admin, gerente, usuario). E simples de implementar e entender. Use quando o numero de papeis for pequeno (ate 10-15) e as regras de acesso forem estaveis. Para cenarios com muitas excecoes ou regras contextuais, prefira ABAC.

### Qual o erro mais comum em autorizacao web?

Esquecer de verificar a propriedade do recurso. Um middleware que so checa papel (ex.: "editor") permite que um editor edite posts de outros editores. A autorizacao correta exige checar se o usuario e o dono ou tem permissao explicita sobre aquele recurso especifico.

---

Fonte (canonical): https://www.bombounaweb.com.br/tecnologia/autenticacao-e-autorizacao-web-guia-completo/