Resposta rápida
Se uma API protegida pelo Cloudflare Access começou a responder 401 ou 403 em vez de redirecionar para o login, verifique se a organização usa o modo estrito de service tokens. Nesse modo, apenas políticas com a ação Service Auth autorizam a requisição de máquina. Uma política Allow e um cookie CF_Authorization já existente não substituem o service token.
Envie CF-Access-Client-Id e CF-Access-Client-Secret em todas as requisições, confirme que o token está ativo e incluído em uma política Service Auth da aplicação correta. O Access não cria um cookie depois do sucesso no modo estrito, por isso chamadas seguintes sem os headers voltam a falhar.
O que muda a partir de 5 de outubro de 2026
A Cloudflare anunciou em 2 de outubro um controle de organização chamado strict service token authentication. Organizações criadas em 5 de outubro de 2026 ou depois recebem o modo estrito por padrão e não podem desativá-lo. Organizações anteriores podem ligar ou desligar a opção enquanto preparam as integrações.
Com o modo estrito, uma falha de autenticação ou autorização retorna 401 ou 403, em vez do redirecionamento 302 para uma página de login. A alteração torna o erro mais adequado para APIs e automações, mas revela configurações que antes dependiam de uma política Allow, de um cookie do navegador ou do envio do token apenas na primeira chamada.
Como interpretar 302, 401 e 403 sem adivinhar
Um 302 normalmente indica que a aplicação ainda usa o comportamento não estrito e está redirecionando a requisição não autorizada para o fluxo interativo. Já 401 e 403 aparecem no modo estrito quando autenticação ou autorização falha. A documentação não promete que um único código identifique sozinho a causa exata, então use status, headers, política e logs em conjunto.
Confirme também quem gerou a resposta. Um 401 ou 403 da aplicação de origem, do API Gateway ou de outro proxy pode ter corpo e headers diferentes dos retornados pelo Access. Registre o timestamp, o hostname e o request ID disponível, mas nunca copie o Client Secret para tickets, logs ou ferramentas públicas.
- 302: confira se a URL Location aponta para o login do Access e se o modo estrito está desativado.
- 401 ou 403: valide os headers do token, a validade da credencial e a política Service Auth.
- Erro só em uma rota: confira se o cliente mudou de hostname ou aplicação protegida durante redirecionamentos.
- Erro em todos os serviços: consulte o Cloudflare Status antes de alterar políticas em massa.
Configure a política Service Auth correta
No Cloudflare One, abra a aplicação do Access e crie uma política com a ação Service Auth. Use o seletor Service Token para incluir a credencial destinada à automação. Uma política Allow é voltada ao fluxo de identidade do usuário e não autoriza service tokens quando o modo estrito está ativo.
Evite resolver o problema com Bypass. Essa ação desativa os controles e o registro de decisões do Access para o tráfego correspondente. Se o serviço deve aceitar apenas a automação, restrinja a Service Auth ao token necessário e, quando fizer sentido, combine com uma faixa de IP de origem conhecida. Revise a ordem das políticas porque Service Auth e Bypass são avaliadas antes de Block e Allow.
- Abra Cloudflare One > Access controls > Applications e selecione a aplicação.
- Adicione uma política com ação Service Auth e seletor Service Token.
- Inclua somente o token usado por essa integração e salve a política.
- Ative o modo estrito primeiro em um ambiente de teste, quando a organização permitir a opção.
- Execute uma chamada válida e outra sem credencial para confirmar o comportamento esperado.
Envie o service token em todas as requisições
O formato padrão usa os headers CF-Access-Client-Id e CF-Access-Client-Secret. O segredo deve vir do gerenciador de credenciais do ambiente, nunca do repositório ou de uma linha de comando salva no histórico. Um teste com curl pode ler as duas variáveis do processo e mostrar apenas o status HTTP.
Também é possível configurar a aplicação para ler o token de um único header. Nesse caso, defina read_service_tokens_from_header e envie um objeto JSON com client_id e client_secret no header escolhido, como Authorization. Esse formato não funciona por suposição: o nome precisa estar configurado na aplicação do Access.
- Exporte o Client ID e o Client Secret por um cofre ou segredo protegido do CI.
- Faça a chamada enviando os dois headers em todas as requisições, inclusive depois de uma resposta bem-sucedida.
- Use curl -sS -o /dev/null -w '%{http_code}\n' para conferir o código sem imprimir o corpo ou o segredo.
- Remova qualquer debug que registre headers antes de promover a mudança.
Por que o cookie deixou de funcionar
No comportamento anterior, uma autenticação de service token podia produzir um cookie CF_Authorization usado em chamadas posteriores. No modo estrito, o Access ignora esse cookie para a autenticação máquina a máquina e não emite outro cookie depois de validar o token.
Clientes que enviam o token apenas na primeira requisição, seguem um redirecionamento e depois dependem do cookie precisam ser corrigidos. Aplique os headers no cliente HTTP compartilhado, no interceptor ou no middleware responsável por todas as chamadas ao hostname protegido. Revise também retries e downloads que abrem uma nova conexão.
Use os logs, mas conheça os pontos cegos
Os logs de autenticação do Access reconhecem causas como token expirado ou desativado, Client Secret incorreto e token que não está autorizado para a aplicação. Essa informação ajuda a separar credencial inválida de política errada sem expor o segredo.
Há um limite importante: requisições com headers malformados ou Client IDs desconhecidos não aparecem nesses logs de autenticação. Se não houver evento no horário esperado, valide a grafia dos headers, o hostname e o Client ID no próprio ambiente do cliente. Use logs do proxy ou da aplicação apenas para metadados seguros, sem capturar o Client Secret.
Rotacione sem interromper a automação
A rotação mantém o Client ID e cria um novo Client Secret. A Cloudflare permite um período de carência para o segredo antigo entre uma hora e 30 dias. Distribua o novo segredo, valide uma chamada em cada ambiente e só então deixe o antigo expirar no prazo escolhido.
Se o token apenas está perto do vencimento e não houve exposição, a documentação também permite renovar sua validade. Rotação e renovação têm objetivos diferentes: gire o segredo quando ele pode ter vazado ou quando a política interna exige troca; renove somente quando a mesma credencial ainda é confiável.
- Escolha um período de carência compatível com a janela de deploy.
- Gere o novo Client Secret e atualize primeiro o ambiente de teste.
- Promova o segredo para os demais consumidores sem remover o anterior de imediato.
- Confirme sucesso nos logs e deixe o segredo antigo expirar no prazo definido.
Limitações e próxima ação útil
Este guia foi verificado em 3 de outubro de 2026. O modo estrito se aplica à autenticação por service token no Cloudflare Access; ele não corrige permissões da API de origem, certificados, DNS, regras do Gateway ou credenciais OAuth. Um status 401 ou 403 ainda precisa ser correlacionado com o componente que o devolveu.
Inventarie hoje as aplicações máquina a máquina, identifique políticas Allow usadas por automações e teste cada cliente enviando os headers em todas as requisições. Para organizações antigas, ative o modo estrito de forma controlada. Para organizações criadas a partir de 5 de outubro, trate o comportamento como padrão e não dependa de cookies ou redirecionamentos interativos.
Faça o próximo teste
Fontes consultadas
Os links abaixo servem para conferir conceitos, orientações oficiais e o critério editorial usado neste conteúdo.
- Strict service token authenticationCloudflare Changelog
- Service tokensCloudflare Docs
- Access policiesCloudflare Docs
- Common Access policiesCloudflare Docs
- Cloudflare StatusCloudflare