FixVibe

// docs / baas security / auth0 hardening

Checklist de segurança Auth0: 22 itens

O Auth0 é uma plataforma identidade-como-serviço com uma enorme superfície — aplicações, APIs (resource servers), tenants, actions, rules (legacy), connections e grants. Configuração incorreta de qualquer um é um bypass de auth. Este checklist é uma auditoria de 22 itens através de aplicações, allowlists de callback / logout, tokens e rotação de refresh, actions customizadas, RBAC, deteção de anomalias e monitorização contínua. Cada item é verificável no painel Auth0 em menos de 10 minutos.

Para o checklist equivalente no Clerk, veja Checklist de segurança Clerk. Para contexto sobre porque é que configurações incorretas em nível de identidade são pontos cegos de ferramentas de IA, veja Porque é que ferramentas de codificação com IA deixam lacunas de segurança.

Tipo de aplicação e tipos de grant

O tipo de aplicação e os tipos de grant habilitados são as configurações de maior impacto no Auth0. Errá-los abre classes de ataque que nenhuma quantidade de código frontend vai fechar.

  1. Use Application Type = Single Page Application para apps apenas no navegador e Regular Web Application para apps renderizados no servidor. O tipo errado permite os grants errados — p. ex., uma Regular Web App com o grant SPA habilita o flow Implicit sem PKCE, que vaza tokens via fragmentos de URL.
  2. Desabilite o tipo de grant Implicit em cada aplicação. Painel → Application → Advanced Settings → Grant Types → desmarque Implicit. O flow Implicit devolve tokens em fragmentos de URL, onde são registados no histórico do navegador e analytics. Use Authorization Code com PKCE no lugar.
  3. Desabilite o grant Password a menos que tenha uma necessidade documentada. O grant Resource Owner Password Credentials (ROPC) requer que lide com palavras-passe de utilizador você mesmo — derrotando a maior parte do que comprou no Auth0. Desabilite a menos que esteja a integrar um sistema legacy.
  4. Habilite Authorization Code com PKCE em cada cliente público. Painel → Advanced Settings → OAuth → JsonWebToken Signature Algorithm = RS256, OIDC Conformant = habilitado. PKCE é requerido para apps móveis e SPAs para prevenir intercetação de código.

Allowlists de URL de callback e logout

Redirecionamentos abertos no caminho de callback OAuth são uma primitiva de roubo de token. A allowlist do Auth0 é a sua única defesa.

  1. Defina Allowed Callback URLs ao seu caminho de callback de produção exato — sem wildcards. https://yourapp.com/callback, não https://yourapp.com/*. Callbacks com wildcard deixam atacantes redirecionar tokens para subcaminhos arbitrários do seu domínio.
  2. Defina Allowed Logout URLs como uma lista finita. Mesma regra: apenas URLs explícitas. Um redirecionamento de logout aberto deixa atacantes criar páginas de phishing que se parecem com o seu estado pós-logout.
  3. Defina Allowed Web Origins apenas à sua origem de produção. Usado para autenticação silenciosa (renovação de token via iframe oculto). Uma origem wildcard deixa páginas de atacantes realizar auth silenciosa contra o seu tenant.
  4. Defina Allowed CORS origins para os endpoints de API, não para a aplicação. Tenant Settings → Advanced → Allowed CORS origins. Padrão é vazio (restrito); adicione apenas origens explícitas que controla.

Tokens e rotação de refresh

Tempo de vida de token, rotação de refresh e algoritmo de assinatura decidem o raio de explosão de qualquer vazamento de token.

  1. Habilite Rotação de Refresh Token. Application → Refresh Token Settings → Rotation. Cada refresh emite um novo refresh token e invalida o antigo. Combinado com expiração absoluta, isto contém roubo de token.
  2. Defina Refresh Token Reuse Interval em 0 (ou tão baixo quanto a sua tolerância a replay permita). O intervalo de reuso deixa um token ser usado duas vezes na mesma janela — desligue a menos que tenha uma razão específica para mantê-lo.
  3. Defina Absolute Refresh Token Expiry em 14-30 dias, não infinito. Application → Refresh Token Expiration → Absolute Expiration. Auth0 por defeito usa apenas Inactivity, o que significa que uma sessão ociosa pode persistir por anos.
  4. Defina JWT Signature Algorithm em RS256. Application → Advanced → OAuth → JsonWebToken Signature Algorithm. RS256 usa assinatura assimétrica para o cliente não conseguir forjar tokens. Nunca use HS256 para aplicações voltadas ao cliente.
  5. Verifique claims aud e iss em cada JWT que a sua API recebe. Use o SDK Auth0 oficial no lado do servidor — verifica-os automaticamente. Parsing JWT feito à mão geralmente salta a validação de audiência, o que é um bypass de auth.

Actions e código customizado

Actions do Auth0 (e Rules legacy) correm do lado do servidor no login e outros eventos de ciclo de vida. Têm acesso a todo o contexto do pedido. Código inseguro aqui é uma vulnerabilidade em todo o tenant.

  1. Nunca registe event.user ou event.transaction como objeto completo. Contêm endereços de e-mail, endereços IP e outros PII. Use apenas registo em nível de campo, e registe apenas o que precisa.
  2. Use a loja de segredos para qualquer chave de API ou URL de webhook. Actions → Edit → Secrets. Nunca coloque inline uma chave de API como literal string no código da action — o código é visível para qualquer um com acesso de editor de Actions no tenant.
  3. Valide entradas antes de persisti-las como user_metadata ou app_metadata. Uma action self-service que escreve event.body.name em user.user_metadata.display_name é um vetor de XSS armazenado se o seu frontend renderiza esse campo sem escape.

RBAC e resource servers

Se usa Auth0 RBAC, o mapeamento role-para-permissão é a sua camada de autorização. Erre e qualquer utilizador autenticado pode atingir endpoints de admin.

  1. Defina Resource Servers (APIs) explicitamente no painel Auth0, não na hora. Cada API tem um identificador (a audience), scopes e configurações de assinatura. Sem uma API registada, todos os tokens são emitidos para a implícita "Auth0 Management API" — audiência errada.
  2. Configure Permissions por API e exija-as no seu código com o claim scope. Não verifique membresia de role na lógica da sua aplicação; verifique scopes no token de acesso. Scopes são o mecanismo de autorização nativo do OAuth.
  3. Teste que um utilizador autenticado sem o role / scope requerido não pode atingir endpoints privilegiados. Entre como utilizador normal, tente chamar POST /api/admin/users/delete. Resposta deve ser 403.

Deteção de anomalias e logs de tenant

Auth0 emite eventos de alto sinal. Configure-os para alertar a sua equipa, não apenas ficar num buffer de log.

  1. Habilite Attack Protection: Bot Detection, Brute Force, Suspicious IP Throttling. Painel → Security → Attack Protection. Cada um está desligado por defeito em planos gratuitos; ligue todos para produção.
  2. Faça stream de logs de tenant para um SIEM ou os seus logs de aplicação. Painel → Monitoring → Streams. Auth0 retém logs por 30 dias na maioria dos planos; retenção de longo prazo requer um stream para o seu próprio sistema.
  3. Alerte em picos de fcoa (auth cross-origin falha) e fp (login falho). Uma rajada destes numa janela curta é credential stuffing. Encaminhe para o seu canal de plantão.

Próximos passos

Execute um varrimento do FixVibe contra a sua URL de produção — a verificação baas.clerk-auth0 sinaliza client secrets Auth0 no bundle JavaScript e outras classes de exposição de fornecedor de identidade. Para o equivalente no Clerk, veja Checklist de segurança Clerk. Para a visão geral sobre fornecedores BaaS, leia Scanner de configurações incorretas de BaaS.

// varra a sua superfície baas

Encontre a tabela aberta antes que outra pessoa o faça.

Coloque uma URL de produção. O FixVibe enumera os fornecedores BaaS com que a sua app fala, identifica os seus endpoints públicos e reporta o que um cliente não autenticado pode ler ou escrever. Grátis, sem instalação, sem cartão.

  • Plano gratuito — 3 varrimentos/mês, sem cartão de registo.
  • Identificação BaaS passiva — sem necessidade de verificação de domínio.
  • Supabase, Firebase, Clerk, Auth0, Appwrite e mais.
  • Prompts de correção com IA em cada achado — cole de volta no Cursor / Claude Code.
Executar varrimento BaaS gratuito →

sem necessidade de registo

Checklist de segurança Auth0: 22 itens — Docs · FixVibe