Autenticação e autorização são conceitos fundamentais no gerenciamento de identidade e acesso (IAM) que, com frequência, são confundidos um com o outro. Embora ambos estejam relacionados à segurança da identidade, eles não são intercambiáveis.

• A autenticação verifica a identidade do usuário.
• A autorização determina o que o usuário pode fazer.

Você entra no GitHub (autenticação) e, em seguida, tenta excluir o repositório de outra pessoa. O GitHub sabe quem você é, mas impede qualquer ação (autorização).

A autenticação vem primeiro: é preciso comprovar sua identidade. A autorização ocorre em seguida: suas permissões determinam o que você pode acessar

A autenticação responde à pergunta: “Quem é você?”

Antes de permitir o acesso de uma pessoa, seu aplicativo precisa verificar a identidade dela. Quando os usuários fazem login, você valida as credenciais (ou outros fatores) para confirmar que eles são quem afirmam ser. A autenticação sempre vem em primeiro lugar. Você não pode definir o acesso de uma pessoa sem confirmar quem ela é.

Pense na autenticação como a segurança de um aeroporto. Você apresenta seus documentos para comprovar sua identidade, enquanto o agente verifica se você é quem seu documento afirma ser.

• Autenticação baseada em senha: os usuários fornecem credenciais validadas em relação a registros armazenados. As senhas sozinhas são cada vez mais insuficientes para os requisitos de segurança modernos.
• Chaves de acesso: os usuários fazem a autenticação com chaves criptográficas protegidas localmente por biometria ou por PINs de dispositivos. As chaves de acesso são credenciais FIDO resistentes a phishing que oferecem login mais rápido, fácil e seguro do que as senhas tradicionais.
• Logins sociais e identidade federada: os usuários se autenticam usando provedores externos confiáveis (como Google ou GitHub) com o OpenID Connect (OIDC). Isso delega a verificação de identidade a provedores de identidade especializados (IdPs).
• Login único (SSO): os usuários se autenticam uma vez para acessar vários aplicativos, sem precisar inserir novamente suas credenciais. Isso melhora a experiência do usuário (UX), principalmente em ambientes corporativos.
• Autenticação multifatorial (MFA): combina diferentes fatores de verificação (por exemplo, conhecimento, posse, herança) para fortalecer a segurança.

Quando um usuário solicita acesso a um aplicativo:

1. O usuário envia suas credenciais para o endpoint de autenticação.
2. O sistema valida as credenciais, seja localmente ou por meio de um IdP.
3. Após a validação bem-sucedida, o sistema emite tokens que representam a identidade autenticada.

A autorização responde à pergunta: “O que você pode fazer?”

A autorização determina o que os usuários autenticados podem fazer dentro de um sistema. As abordagens comuns incluem:

Método	Descrição	Exemplo
Controle de acesso baseado em funções (RBAC)	Funções predefinidas (administrador, editor, visualizador) com permissões fixas são atribuídas aos usuários	Um editor pode modificar documentos; um visualizador só pode lê-los
Controle de acesso baseado em atributos (ABAC)	Decisões de acesso baseadas em atributos dinâmicos (propriedades do usuário, metadados de recursos, contexto ambiental)	Os recursos financeiros só podem ser acessados pela rede corporativa durante o horário comercial
Controles de acesso baseados em relacionamento (ReBAC)	Autorização baseada nos relacionamentos entre usuários e recursos	Um funcionário pode editar seus próprios documentos, mas não os rascunhos privados de seus colegas de equipe

A autorização na prática

Considere um aplicativo de gerenciamento de projetos:

• A autenticação confirma que o usuário é Alex.

• A autorização determina que Alex (na função de gerente de projeto) pode visualizar todos os projetos da equipe de desenvolvimento, mas não pode excluir projetos nem acessar as configurações de faturamento.

Ao trabalhar com protocolos modernos, é muito importante saber qual é a diferença entre autenticação (AuthN) e autorização (AuthZ).

Aspecto	Autenticação (AuthN)	Autorização (AuthZ)
A pergunta	Quem é você?	O que você pode fazer?
O processo	Verifica a identidade	Verifica as permissões
Sequência	Deve acontecer primeiro	Ocorre após a autenticação
Métodos	Senhas, chaves de acesso, MFA, SSO, OIDC	RBAC, ABAC, ReBAC
Tipo de token	Token de identificação (declarações de identidade)	Token de acesso (permissões/escopos)
Status HTTP	401 Não autorizado (falha em comprovar a identidade)	403 Proibido (identidade conhecida, permissão negada)

O OAuth 2.0 é uma estrutura de autorização. Não se trata de um protocolo de autenticação.

O OAuth 2.0 fornece uma maneira padronizada para um aplicativo cliente obter um token de acesso de um servidor de autorização (com o consentimento do usuário) para acessar recursos protegidos. Ele foi desenvolvido para autorização delegada, permitindo que os usuários concedam acesso limitado aos recursos deles para aplicativos de terceiros sem compartilhar suas senhas.

O OpenID Connect (OIDC) entra em cena

O OIDC é um protocolo de autenticação interoperável construído sobre a estrutura OAuth 2.0. Ele simplifica o processo de verificação da identidade do usuário com base na autenticação realizada pelo servidor de autorização.

Ele faz o que o OAuth 2.0 não oferece:

• Define o token de identificação: um token de segurança padronizado (codificado como um JWT) que serve como prova de que o usuário foi autenticado.
• Ele padroniza as declarações de identidade do usuário (como nome e e-mail).

Em arquiteturas modernas:

• O OAuth 2.0 cuida da autorização (delegação de acesso a recursos).
• O OpenID Connect cuida da autenticação (confirmação da identidade do usuário).

Os dois protocolos geralmente operam em conjunto no mesmo fluxo.

Os aplicativos modernos são sistemas distribuídos construídos em torno de APIs e se tornaram um meio primordial de acesso a recursos.

A mudança fundamental: as APIs não autenticam o usuário diretamente. Elas validam tokens e aplicam a autorização da API.

Como funciona a autenticação baseada em token

1. O usuário se autentica com um servidor de autorização (provedor de identidade).
2. O servidor emite tokens após validar a identidade:
   • Token de identificação (autenticação): informações de identidade do usuário. O cliente utiliza isso para determinar quem fez login.
   • Token de acesso (autorização): informações de autorização (escopos, permissões). A API usa isso para determinar o que o usuário pode acessar.
3. O cliente faz chamadas à API com o token de acesso no cabeçalho [Authorization: Bearer].
4. A API valida o token e aplica regras de autorização com base nas declarações que ele contém.

Para entender a autenticação JWT

Os JSON Web Tokens (JWTs) são o formato de token mais comum. Eles são autossuficientes, uma vez que contêm todas as informações necessárias incorporadas no próprio token.

Um JWT é composto por um cabeçalho, uma carga útil (declarações) e uma assinatura.

Validação do JWT: o que a API deve verificar

Quando uma API recebe um JWT, a validação é imprescindível. Se qualquer uma dessas validações for ignorada, ocorrerão vulnerabilidades de segurança no aplicativo.

Cinco verificações de validação essenciais:

1. Estrutura do token: primeiro, verifique se o token corresponde à estrutura de um JSON Web Token.
2. Integridade do token: confira a assinatura para verificar se o token não foi adulterado.
3. Expiração do token: verifique se o token expirou, conforme definido pela declaração exp.
4. Autoridade esperada: confirme se o token foi emitido e assinado pelo remetente esperado.
   1. Compare com a declaração iss (emissor).
   2. Verifique se a chave usada para assinar o JWT pertence à autoridade esperada.
5. Público esperado: confirme se o token se destina ao seu aplicativo e se a declaração aud corresponde ao valor que identifica seu aplicativo.

JWT ou opaco: os prós e os contras

O OAuth 2.0 não exige um formato específico de token de acesso. Embora os JWTs sejam populares, uma alternativa é o token opaco, uma sequência aleatória que não contém nenhuma informação incorporada sobre o usuário ou o próprio token.

Destaque	Tokens de acesso JWT	Tokens de acesso opacos
Validação	Sem estado (API valida localmente)	Com estado (a API deve chamar o endpoint de introspecção do servidor de autorização em cada requisição)
Revogação	Difícil de revogar antes da expiração	Capacidade de revogação instantânea
Desempenho	Menor latência nas solicitações de API (mais rápido)	A consulta ao servidor de autorização aumenta a latência
Escalabilidade	Escala bem em arquiteturas distribuídas	O servidor de autorização se torna uma dependência crítica

Ambos são válidos para implementações do OAuth 2.0. Muitos sistemas utilizam JWTs com tempos de expiração curtos e rotação de token de atualização para equilibrar desempenho e segurança.

O fluxo de código de autorização com chave de prova para troca de código (PKCE) é o fluxo do OAuth 2.0 mais seguro para aplicativos web e móveis, demonstrando como a autenticação (AuthN) e a autorização (AuthZ) funcionam em conjunto. O uso do PKCE protege o fluxo contra ataques de interceptação.

1. O usuário inicia o login: o aplicativo redireciona o usuário para o servidor de autorização com os detalhes da solicitação (ID do cliente, escopos, desafio do código PKCE).
2. O usuário autentica: o login do usuário é realizado pela página de login hospedada. A autenticação está concluída.
3. Código de autorização emitido: o usuário é redirecionado de volta para o app com um código de autorização de curta duração.
4. Troca de tokens: o back-end do app troca o código de autorização por tokens, enviando o verificador de código PKCE. O servidor emite o token de identificação (AuthN) e o token de acesso (AuthZ).
5. Acesso à API: o app inclui o token de acesso nos cabeçalhos das solicitações ao chamar APIs protegidas.
6. Validação e aplicação de tokens: a API valida o token de acesso e aplica as permissões com base em suas declarações, garantindo a autorização adequada.

Considerações de segurança para desenvolvedores

Consideração	Recomendação
Tempo de vida do token	Use tokens de acesso de curta duração (15 a 60 minutos) e um token de atualização para adquirir novos tokens de acesso sem forçar os usuários a fazer login.
menor privilégio	Solicite os escopos obrigatórios mínimos que um aplicativo precisa para minimizar o risco de danos potenciais de tokens comprometidos.
Validação de token	Valide sempre os tokens para reduzir os riscos de segurança.
Armazenamento de tokens	Nunca armazene tokens sensíveis em localStorage ou sessionStorage. Utilize cookies HttpOnly seguros ou armazenamento de sessão seguro no back-end.

Para criar aplicativos seguros, é necessário compreender a diferença entre autenticação e autorização:

Conceito	O que resolve	Protocolo/token
Autenticação	Verificação de identidade	OpenID Connect, token de identificação
Autorização	Controle de acesso	OAuth 2.0, token de acesso

Lista de verificação para a implementação

• Use o OpenID Connect para autenticação de usuários.
• Use o OAuth 2.0 para autorização delegada.
• Valide os JWTs no servidor em cada solicitação de API.
• Retorne 401 para falhas de autenticação, 403 para negações de autorização.
• Utilize o fluxo de código de autorização com PKCE.
• Armazene os tokens com segurança (cookies HttpOnly).
• Use tokens de acesso de curta duração com rotação de token de atualização.

Para uma análise aprofundada sobre tipos de token, aprenda a diferença entre o token de identificação e o token de acesso.

A utilização de um serviço como Auth0 pode simplificar a implementação da autenticação e da autorização, permitindo que os desenvolvedores se concentre na lógica principal do aplicativo. Explore nossa série Introdução ao IAM para mais informações sobre tópicos relacionados ao gerenciamento de identidade e acesso.

Saiba mais

Este material destina-se apenas a fins informativos gerais. Você é responsável por obter aconselhamento sobre segurança, privacidade, conformidade ou negócios de seus próprios consultores profissionais e não deve confiar exclusivamente nas informações aqui fornecidas.