Erro HTTP 401 Unauthorized: O Que Significa e Como Corrigir

O Que É o Erro 401 Unauthorized?

O erro 401 Unauthorized é um código de status HTTP que significa que o servidor requer autenticação para o recurso solicitado, mas a solicitação não incluiu credenciais ou as credenciais fornecidas eram inválidas.

A especificação HTTP (RFC 9110, Seção 15.5.2) o define assim: a solicitação não possui credenciais de autenticação válidas para o recurso de destino. O servidor que gera a resposta 401 deve incluir um header WWW-Authenticate indicando qual esquema de autenticação usar.

Em termos simples: o servidor está perguntando "quem é você?" antes de permitir o acesso. Ou você não forneceu nenhuma identificação, ou a identificação que forneceu estava errada.

Como o Erro 401 Aparece

O erro 401 aparece de formas diferentes dependendo do servidor, navegador e aplicação. Aqui estão as mensagens mais comuns que você encontrará.

• 401 Unauthorized — a mensagem de resposta HTTP padrão

• HTTP Error 401 – Unauthorized — comum em aplicações IIS e ASP.NET

• 401 Authorization Required — página de erro padrão do Nginx

• Error 401 — forma abreviada nas barras de endereço do navegador

• Access Denied: Invalid credentials — páginas de erro personalizadas de aplicações

• Authentication Required — popup do navegador solicitando autenticação Basic/Digest

• Invalid API Key — comum em respostas de APIs REST

• Token Expired — o token JWT ou OAuth precisa ser renovado

Quando um servidor envia um 401, a maioria dos navegadores exibe um popup de login pedindo nome de usuário e senha. Se o servidor usa autenticação baseada em token (como APIs), você verá o erro no corpo da resposta JSON.

401 vs 403: Qual a Diferença?

Os códigos de status 401 e 403 são frequentemente confundidos, mesmo por desenvolvedores experientes. A distinção é simples: 401 significa "não sei quem você é" enquanto 403 significa "sei quem você é, mas você não tem permissão."

Uma regra prática: se fornecer o nome de usuário e senha corretos (ou chave de API) resolver o problema, o servidor deve retornar 401. Se o usuário já está autenticado mas simplesmente não tem acesso àquele recurso, o servidor deve retornar 403 Forbidden.

Causas Comuns do Erro 401

Entender por que um erro 401 ocorre depende de você ser um usuário comum, um desenvolvedor chamando uma API ou um administrador de servidor. Aqui estão as causas mais frequentes.

• Nome de usuário ou senha incorretos — a causa mais básica, especialmente após uma redefinição de senha

• Token de autenticação expirado — tokens JWT, tokens de acesso OAuth e cookies de sessão têm prazo de validade

• Header Authorization ausente — a solicitação não incluiu nenhuma credencial

• Chave de API inválida — a chave foi revogada, rotacionada ou copiada incorretamente

• Esquema de autenticação incorreto — servidor espera Bearer token mas recebeu Basic auth, ou vice-versa

• Desvio de relógio (clock skew) — a validação JWT falha quando os relógios do servidor e do cliente estão dessincronizados em mais de alguns minutos

• CORS preflight removendo headers — o navegador remove o header Authorization das solicitações preflight OPTIONS

• Cache do navegador desatualizado — o navegador envia um cookie de sessão em cache e expirado em vez de solicitar um novo

• Configuração incorreta do proxy reverso — Nginx ou Apache remove o header Authorization antes de encaminhar ao backend

• Credenciais com rate limit ou revogadas — muitas tentativas falhadas ativaram o bloqueio da conta

Como Corrigir o Erro 401 Como Visitante

Se você encontrar um erro 401 em um site que está tentando acessar, o problema quase sempre está relacionado às suas credenciais de login. Siga estes passos na ordem.

1. Verifique Suas Credenciais de Login

A causa mais comum de um erro 401 é simplesmente credenciais incorretas. Se o site mostra um popup ou formulário de login, verifique novamente seu nome de usuário e senha.

Erros comuns: Caps Lock está ativado, você está usando uma senha antiga (especialmente após uma redefinição recente), ou está fazendo login na conta errada. Se você usa um gerenciador de senhas, deixe-o preencher automaticamente as credenciais para evitar erros de digitação.

2. Limpe o Cache e os Cookies do Navegador

Seu navegador pode estar enviando um cookie de sessão expirado ou token de autenticação em cache. Limpar esses dados força o navegador a solicitar novas credenciais ao servidor.

Chrome:  Settings → Privacy → Clear browsing data → Cookies + Cached images
Firefox: Settings → Privacy → Clear Data → Cookies + Cache
Safari:  Settings → Privacy → Manage Website Data → Remove All
Edge:    Settings → Privacy → Clear browsing data → Cookies + Cache

Após limpar, feche o navegador completamente (não apenas a aba), reabra-o e navegue até a página novamente. Você deve ver um novo prompt de login.

3. Tente o Modo Anônimo ou Privado

Abra a URL em uma janela anônima (Chrome) ou privada (Firefox/Safari). Isso ignora todos os cookies em cache, extensões e credenciais armazenadas.

Se a página funciona no modo anônimo mas não no navegador normal, o problema é um cookie em cache ou uma extensão do navegador interferindo na autenticação. Desative as extensões uma por uma para encontrar a culpada.

4. Verifique a URL

Certifique-se de que está visitando a URL correta. Alguns servidores retornam 401 para caminhos que exigem autenticação, mesmo que o caminho esteja errado. Você pode estar tentando acessar uma área restrita que não deveria visitar.

Verifique se existe uma versão pública da página em uma URL diferente. Por exemplo, example.com/admin/ pode retornar 401 enquanto example.com/ é acessível publicamente.

Como Corrigir o Erro 401 Como Desenvolvedor

Para desenvolvedores trabalhando com APIs, erros 401 geralmente estão relacionados ao header Authorization, formato do token ou ciclo de vida das credenciais. Estas são as correções mais comuns.

5. Verifique o Header Authorization

O erro mais comum de desenvolvedores é um header Authorization malformado. O header WWW-Authenticate da resposta do servidor diz exatamente qual esquema ele espera.

Verifique se seu header corresponde ao formato exigido. Os esquemas mais comuns são Bearer (para tokens) e Basic (para usuário:senha codificados em Base64).

# Bearer token authentication (most APIs)
curl -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIs..." https://api.example.com/data

# Basic authentication (username:password in Base64)
curl -u "username:password" https://api.example.com/data
# Equivalent to:
curl -H "Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=" https://api.example.com/data

# Common mistakes that cause 401:
# Missing "Bearer " prefix:  Authorization: eyJhbGci...  ← WRONG
# Extra space:               Authorization: Bearer  eyJ... ← WRONG
# Wrong scheme:              Authorization: Basic eyJhbGci... ← WRONG

Sempre verifique o header WWW-Authenticate na resposta 401. Ele informa exatamente o que o servidor espera. Use a ferramenta HTTP Headers do DNS Robot para inspecionar a resposta completa.

6. Verifique a Validade da Chave de API

Chaves de API podem parar de funcionar silenciosamente por vários motivos: a chave foi rotacionada, a conta associada foi rebaixada, a chave atingiu seu limite de taxa, ou ela foi configurada para endpoints diferentes dos que você está chamando.

Verifique se sua chave ainda está ativa no painel do provedor. Muitas APIs (Google, AWS, Stripe) permitem que você teste a chave diretamente no console.

# Test if your API key is valid
curl -I -H "Authorization: Bearer YOUR_API_KEY" https://api.example.com/me
# 200 = key is valid
# 401 = key is invalid or expired
# 403 = key is valid but lacks permission for this endpoint

# Check common API key issues:
# 1. Trailing whitespace in .env file:  API_KEY="abc123 " ← trailing space
# 2. Wrong environment:                 using test key on production
# 3. Missing prefix:                    some APIs need "sk_live_" prefix

7. Resolva Expiração e Renovação de Tokens

Tokens JWT e tokens de acesso OAuth têm um tempo de vida limitado — geralmente de 15 minutos a 24 horas. Quando expiram, cada chamada de API retorna 401 até que você obtenha um novo token.

A correção depende do seu fluxo de autenticação. OAuth 2.0 usa um refresh token para obter um novo token de acesso sem reautenticação. Sistemas baseados em JWT geralmente exigem um novo login.

# Decode a JWT token to check its expiry (works on macOS and Linux)
echo "eyJhbGciOiJIUzI1NiIs..." | cut -d'.' -f2 | base64 -d 2>/dev/null | python3 -m json.tool
# Look for "exp" field — it's a Unix timestamp
# Compare with current time: date +%s

# OAuth 2.0 refresh token flow
curl -X POST https://auth.example.com/token \
  -d "grant_type=refresh_token" \
  -d "refresh_token=YOUR_REFRESH_TOKEN" \
  -d "client_id=YOUR_CLIENT_ID"

8. Corrija Problemas de CORS Preflight

Quando um navegador envia uma solicitação cross-origin com um header Authorization, ele primeiro envia uma solicitação preflight OPTIONS. O navegador remove automaticamente o header Authorization desta solicitação preflight. Se seu servidor exige autenticação na solicitação OPTIONS, ele retorna 401 antes que a solicitação real seja enviada.

A correção: configure seu servidor para permitir solicitações OPTIONS sem autenticação em endpoints habilitados para CORS.

# Nginx — allow OPTIONS requests without auth
location /api/ {
    if ($request_method = OPTIONS) {
        add_header Access-Control-Allow-Origin *;
        add_header Access-Control-Allow-Methods "GET, POST, PUT, DELETE, OPTIONS";
        add_header Access-Control-Allow-Headers "Authorization, Content-Type";
        add_header Access-Control-Max-Age 86400;
        return 204;
    }

    # Normal auth for other methods
    auth_basic "Restricted";
    auth_basic_user_file /etc/nginx/.htpasswd;
}

Como Corrigir o Erro 401 Como Proprietário do Site

Se seus visitantes ou usuários estão reportando erros 401, o problema está na configuração de autenticação do seu servidor. Siga estas verificações.

9. Revise a Configuração de Autenticação do Servidor

Verifique se a autenticação está habilitada apenas nas rotas que precisam dela. Um erro comum é proteger um diretório ou site inteiro quando apenas caminhos específicos deveriam exigir login.

No Nginx, verifique suas diretivas auth_basic. No Apache, verifique as diretivas AuthType e Require. No Node.js/Express, verifique a ordem dos seus middlewares — middleware de autenticação colocado antes dos manipuladores de rota bloqueará tudo.

# Nginx — WRONG: protects everything, including public pages
server {
    auth_basic "Restricted";
    auth_basic_user_file /etc/nginx/.htpasswd;
    # All pages now require login — including your homepage!
}

# Nginx — CORRECT: only protect admin routes
server {
    location / {
        # Public — no auth required
    }
    location /admin/ {
        auth_basic "Admin Area";
        auth_basic_user_file /etc/nginx/.htpasswd;
    }
}

10. Verifique as Regras de Autenticação do .htaccess

Em servidores Apache, arquivos .htaccess podem habilitar autenticação Basic ou Digest para diretórios específicos. Se um arquivo .htaccess existe em um diretório público com diretivas AuthType, todos os visitantes receberão um prompt de login 401.

Verifique se existem arquivos .htaccess no diretório afetado e em todos os diretórios pai — o Apache aplica regras de todos os arquivos .htaccess no caminho.

# Find all .htaccess files with auth rules
find /var/www/html -name '.htaccess' -exec grep -l 'AuthType\|AuthUserFile\|Require valid-user' {} \;

# Example .htaccess that causes 401 for everyone:
# AuthType Basic
# AuthName "Restricted Area"
# AuthUserFile /etc/apache2/.htpasswd
# Require valid-user

# Fix: remove auth lines from public directories,
# or move them to the specific /admin/.htaccess only

11. Corrija a Remoção de Headers pelo Proxy Reverso

Se sua aplicação está atrás do Nginx, Apache ou um balanceador de carga, o proxy pode remover o header Authorization antes de encaminhar a solicitação ao backend. Esta é uma das causas mais frustrantes de erros 401 porque o cliente envia credenciais corretas mas o servidor nunca as recebe.

Verifique a configuração do seu proxy para garantir que ele encaminha o header Authorization.

# Nginx reverse proxy — pass Authorization header to backend
location /api/ {
    proxy_pass http://localhost:3000;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header Authorization $http_authorization;  # ← Critical!
    proxy_pass_header Authorization;                      # ← Also add this
}

# Apache reverse proxy
<Location /api/>
    ProxyPass http://localhost:3000/api/
    ProxyPassReverse http://localhost:3000/api/
    RequestHeader set Authorization "expr=%{HTTP:Authorization}"  # Pass auth header
</Location>

Depurando Erros 401 com HTTP Headers

A maneira mais rápida de diagnosticar um erro 401 é inspecionar os headers da resposta. O header WWW-Authenticate na resposta do servidor informa exatamente qual método de autenticação é necessário.

Use a ferramenta HTTP Headers do DNS Robot ou curl no terminal para ver a resposta completa.

# Check the WWW-Authenticate header in the 401 response
curl -I https://api.example.com/protected-endpoint

# Typical 401 response headers:
# HTTP/1.1 401 Unauthorized
# WWW-Authenticate: Bearer realm="api", error="invalid_token"
# WWW-Authenticate: Basic realm="Admin Area"
# Content-Type: application/json

# The WWW-Authenticate header tells you:
# - The auth scheme (Bearer, Basic, Digest)
# - The realm (which area is protected)
# - The error reason (invalid_token, expired, etc.)

Preste muita atenção ao header WWW-Authenticate. Se ele diz Bearer, você precisa de um token. Se diz Basic, você precisa de um nome de usuário e senha. Se inclui error=invalid_token, seu token existe mas está malformado ou expirado. Este único header geralmente indica exatamente qual é o problema.

O Erro 401 Afeta o SEO?

Um erro 401 em páginas públicas prejudicará seu SEO. Quando o Googlebot encontra um 401, ele não consegue rastrear a página e eventualmente a removerá do índice.

No entanto, erros 401 em páginas que devem exigir autenticação (painéis de administração, dashboards de usuários, endpoints de API) são completamente normais. O Google espera que essas páginas sejam protegidas e não penalizará seu site por isso.

O problema surge quando erros 401 aparecem em páginas que deveriam ser acessíveis publicamente. Isso geralmente acontece quando o middleware de autenticação está mal configurado ou quando um CDN/proxy reverso exige credenciais incorretamente em rotas públicas.

Como Prevenir Erros 401

A prevenção evita depuração depois. Siga estas práticas para minimizar erros 401 em suas aplicações e sites.

• Implemente renovação automática de tokens — use refresh tokens para obter novos tokens de acesso silenciosamente antes que expirem

• Defina escopos de autenticação adequados — proteja apenas rotas que genuinamente precisam de autenticação, mantenha páginas públicas abertas

• Use mensagens de erro claras — retorne corpos de erro JSON úteis junto com o 401, não apenas o código de status

• Monitore falhas de autenticação — configure alertas para picos em respostas 401, que podem indicar problemas de credenciais ou ataques

• Sincronize os relógios dos servidores — use NTP para manter todos os servidores dentro de poucos segundos do UTC, prevenindo rejeições JWT por desvio de relógio

• Teste com a [ferramenta HTTP Headers](/http-headers) — verifique regularmente se páginas públicas retornam 200 e páginas protegidas retornam 401 conforme esperado

• Documente seu esquema de autenticação — deixe o formato esperado do header Authorization claro na documentação da sua API

• Trate o CORS preflight — sempre permita solicitações OPTIONS sem autenticação em endpoints de API