O que é Autenticação e Autorização?

Autenticação e autorização são os dois pilares do controle de acesso em sistemas de software. Apesar de frequentemente serem confundidas, elas respondem a perguntas completamente diferentes — e a falha em qualquer uma delas pode comprometer completamente a segurança de uma aplicação.

TL;DR Autenticação (AuthN) verifica quem você é — confirma a identidade de um usuário ou sistema. Autorização (AuthZ) determina o que você tem permissão de fazer — controla quais recursos um usuário autenticado pode acessar. Autenticação sempre vem antes da autorização. Em HTTP, falha de autenticação retorna 401 Unauthorized; falha de autorização retorna 403 Forbidden. Implementar ambas corretamente requer escolher os protocolos certos (OAuth 2.0, JWT, SAML, OIDC) e modelos de controle de acesso adequados (RBAC, ABAC).

Autenticação vs. Autorização

Uma analogia útil: em um hotel, apresentar seu passaporte na recepção é autenticação — você prova quem é. O cartão-chave que abre apenas o seu quarto é autorização — define o que você pode acessar.

O que é autenticação?

Autenticação é o processo de verificar a identidade de um usuário, dispositivo ou serviço. O sistema precisa confirmar que você é quem afirma ser antes de conceder qualquer acesso.

Os três fatores de autenticação

Autenticação pode se basear em um ou mais dos seguintes fatores:

Autenticação multifator (MFA) combina dois ou mais fatores. Por exemplo, senha (algo que você sabe) + código TOTP enviado ao celular (algo que você tem). MFA reduz drasticamente o risco de comprometimento de conta — mesmo que a senha seja vazada, o atacante ainda precisa do segundo fator.

Métodos de autenticação

O que é autorização?

Autorização é o processo de determinar se um usuário autenticado tem permissão para realizar uma ação específica ou acessar um recurso específico. A autorização sempre pressupõe que a autenticação já ocorreu.

Mesmo que um usuário tenha feito login com sucesso (autenticado), ele não necessariamente pode fazer tudo no sistema — a autorização define os limites de acesso.

Controle de Acesso Baseado em Papéis (RBAC)

No RBAC, as permissões são atribuídas a papéis (roles), e usuários são atribuídos a papéis. Em vez de gerenciar permissões individuais para cada usuário, você gerencia papéis.

Exemplo:

RBAC é simples de gerenciar e amplamente suportado. É adequado para a maioria das aplicações com hierarquias de permissão claras.

Controle de Acesso Baseado em Atributos (ABAC)

No ABAC, as decisões de acesso são baseadas em atributos do usuário, do recurso e do ambiente. As políticas são expressas como regras que combinam múltiplos atributos.

Exemplo de política ABAC:

PERMITIR acesso SE:
  usuario.departamento == recurso.departamento_proprietario
  AND usuario.nivel_clearance >= recurso.classificacao
  AND hora_atual BETWEEN 09:00 AND 18:00

ABAC oferece controle de granularidade muito mais fina que o RBAC, mas é mais complexo de implementar e auditar. É preferível em ambientes com requisitos de conformidade complexos ou estruturas de acesso altamente dinâmicas.

Listas de Controle de Acesso (ACL)

ACLs definem permissões diretamente em recursos, especificando quais usuários ou grupos podem realizar quais operações. São comuns em sistemas de arquivos e em regras de firewall de rede.

Exemplo:

arquivo_relatorio_financeiro.pdf:
  - alice: ler, escrever
  - bob: ler
  - grupo_auditoria: ler

Autenticação em APIs

APIs têm padrões de autenticação distintos das aplicações web tradicionais, porque geralmente não têm uma interface de usuário para login interativo.

Como JWT funciona na autenticação de API

Um JSON Web Token (JWT) é um token compacto e autocontido que codifica claims (afirmações) sobre o usuário. Ele é composto por três partes separadas por pontos: Header, Payload e Signature.

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ1c2VyXzEyMyIsInJvbGUiOiJhZG1pbiIsImV4cCI6MTc1NDAwMDAwMH0.assinatura

O servidor verifica a assinatura sem consultar um banco de dados — isso torna o JWT ideal para arquiteturas distribuídas e microsserviços. O payload pode conter claims de autorização como role: admin, permitindo que o JWT sirva tanto para autenticação quanto para autorização.

Como OAuth 2.0 funciona

OAuth 2.0 é um framework de delegação de autorização — não um protocolo de autenticação. Ele permite que um usuário conceda acesso limitado aos seus recursos em um serviço (provider) para outro serviço (client) sem compartilhar sua senha.

Fluxo de Authorization Code (o mais seguro para aplicações web):

1. O usuário clica em “Login com Google”
2. O client redireciona para o servidor de autorização do Google
3. O usuário autentica no Google e concede permissões
4. O Google redireciona de volta ao client com um código de autorização
5. O client troca o código por um access token (server-to-server)
6. O client usa o access token para acessar recursos protegidos

OpenID Connect (OIDC) adiciona uma camada de identidade sobre o OAuth 2.0, emitindo um ID token (JWT) que contém informações sobre o usuário autenticado.

Single Sign-On (SSO)

SSO permite que usuários se autentiquem uma única vez e acessem múltiplas aplicações sem precisar fazer login novamente em cada uma.

Como o SSO funciona

1. O usuário tenta acessar uma aplicação (Service Provider — SP)
2. O SP redireciona o usuário para o Identity Provider (IdP)
3. O IdP autentica o usuário (se ainda não estiver autenticado)
4. O IdP emite um token/asserção (SAML, OIDC ID token)
5. O SP valida o token e concede acesso
6. Quando o usuário acessa uma segunda aplicação, o IdP reconhece a sessão existente e emite um novo token sem exigir novo login

Protocolos comuns para SSO:

• SAML 2.0: Padrão XML amplamente usado em ambientes corporativos
• OIDC: Padrão moderno baseado em JSON/OAuth 2.0; preferido para aplicações web e mobile
• Kerberos: Protocolo de SSO interno para redes Windows (Active Directory)

Melhores práticas de autenticação e autorização

Autenticação

• Exija MFA para contas de alto privilégio e, idealmente, para todos os usuários
• Faça hash de senhas com algoritmos modernos: bcrypt, Argon2 ou scrypt — nunca MD5 ou SHA-1 simples
• Implemente rate limiting em endpoints de login para prevenir ataques de força bruta
• Use sessões com tempo de expiração e revogue tokens ao fazer logout
• Adote passkeys/WebAuthn onde possível — eliminam o risco de phishing de senha

Autorização

• Aplique o princípio do menor privilégio — conceda apenas as permissões mínimas necessárias
• Valide autorização no servidor — nunca confie em verificações do lado do cliente
• Registre todas as decisões de acesso para fins de auditoria e detecção de anomalias
• Revogue tokens imediatamente quando um usuário é desativado ou suas permissões são alteradas
• Teste falhas de autorização — Broken Access Control é a vulnerabilidade #1 no OWASP Top 10 2021

Perguntas frequentes

Qual é a diferença entre autenticação e autorização? Autenticação verifica quem você é — confirma sua identidade. Autorização determina o que você pode fazer — controla seu acesso a recursos. Um usuário pode ser autenticado (logado) mas não autorizado a acessar um recurso específico. Em HTTP, a distinção aparece nos códigos de status: 401 significa não autenticado; 403 significa autenticado mas não autorizado.

O que é autenticação multifator (MFA)? MFA exige que o usuário comprove sua identidade usando dois ou mais fatores independentes — algo que sabe (senha), algo que tem (código TOTP no celular) e/ou algo que é (biometria). MFA torna a comprometimento de conta muito mais difícil, mesmo que a senha seja vazada. O método mais comum é TOTP (Time-based One-Time Password) via apps como Google Authenticator ou Authy.

O que é JWT e como ele é usado para autenticação? JWT (JSON Web Token) é um token compacto, assinado criptograficamente, que contém claims sobre um usuário. Quando um usuário faz login, o servidor emite um JWT contendo informações de identidade e expiração. O cliente envia esse token em requisições subsequentes no header Authorization: Bearer. O servidor valida a assinatura do token sem consultar o banco de dados, tornando o JWT ideal para APIs distribuídas.

Qual é a diferença entre RBAC e ABAC? RBAC atribui permissões a papéis (roles) e usuários a papéis — simples e adequado para a maioria das aplicações. ABAC toma decisões de acesso com base em atributos do usuário, do recurso e do contexto — mais flexível e granular, mas mais complexo. Escolha RBAC quando as permissões são bem definidas por função; escolha ABAC quando precisar de políticas de acesso dinâmicas e contextuais.

O que é OAuth 2.0 e para que serve? OAuth 2.0 é um framework de delegação de autorização que permite que um serviço acesse recursos em outro serviço em nome de um usuário, sem que o usuário compartilhe sua senha. É a base do “Login com Google” e da maioria das integrações de API modernas. OAuth 2.0 por si só não é um protocolo de autenticação — OpenID Connect (OIDC) adiciona essa camada.

Como o SSO melhora a segurança e a experiência do usuário? SSO reduz a quantidade de senhas que os usuários precisam lembrar, diminuindo a probabilidade de reutilização de senhas fracas. Centraliza a autenticação em um único Identity Provider (IdP), facilitando o enforcement de políticas de segurança como MFA e o provisionamento/desprovisionamento de acesso. Para usuários, elimina a necessidade de logins repetidos entre aplicações integradas.

Por que a autorização deve sempre ser verificada no servidor? Verificações de autorização no lado do cliente (JavaScript) podem ser facilmente contornadas por um atacante que modifica as requisições HTTP diretamente. O servidor deve sempre verificar se o usuário autenticado tem permissão para realizar a ação solicitada, independentemente do que o cliente afirma. Confiar no cliente para impor permissões é uma vulnerabilidade de Broken Access Control.

O que é Broken Access Control e por que é tão comum? Broken Access Control ocupa o #1 no OWASP Top 10 2021, presente em 94% das aplicações testadas. Ocorre quando uma aplicação não impõe adequadamente restrições sobre o que usuários autenticados podem fazer — por exemplo, um usuário comum que pode acessar endpoints administrativos alterando a URL, ou um usuário que pode ver dados de outros usuários modificando um ID em uma requisição. A prevenção requer testes sistemáticos de todos os controles de acesso e adoção do princípio do menor privilégio.