Autenticacao e autorizacao web: guia completo

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:

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

1. Extrai o token do header Authorization.
2. Valida a assinatura e expiracao do JWT.
3. Decodifica as claims (ex.: role, user_id).
4. Verifica se o usuario tem permissao para a acao solicitada (ex.: role === 'admin' ou user_id === resource.owner_id).
5. 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.