Erro do Supabase: "Unsupported provider: provider is not enabled"

Você coloca um botão "Entrar com Google" no seu app e clica nele. Em vez do seletor de contas do Google, o navegador mostra isto:

{"code":400,"error_code":"validation_failed","msg":"Unsupported provider: provider is not enabled"}

A barra de endereços mostra o seu projeto do Supabase, algo como https://abcdefghij.supabase.co/auth/v1/authorize?provider=google&redirect_to=…. Você fez o app com Lovable, Bolt, v0, Cursor, Claude Code ou Replit, o botão veio junto com o código, e nada nesse código parece errado.

"Unsupported provider: provider is not enabled" significa que o Supabase Auth, a parte do Supabase que faz o login das pessoas, está com o Google desligado no projeto com que o seu app fala. A correção é uma chave e dois valores que o Google te dá. Depois disso, o Google confere uma lista própria, e é dessa lista que vem o erro seguinte, redirect_uri_mismatch.

A armadilha está nessa segunda lista. O endereço que parece certo para ela é o do seu próprio app, e o Google nunca usa esse endereço, porque o Google nunca manda ninguém para o seu app.

O que significa "Unsupported provider: provider is not enabled"?

Significa que o Supabase se recusou a começar um login com Google, porque o Google está desligado no projeto que recebeu o pedido.

Entrar com Google é uma ida e volta por duas recepções. O seu app manda a pessoa para a recepção do Supabase. O Supabase manda a pessoa para a recepção do Google para provar quem ela é, o Google devolve a pessoa ao Supabase, e o Supabase manda a pessoa de volta para casa, para o seu app, já logada. Cada recepção só manda as pessoas para onde as próprias configurações permitem. Esta mensagem é a recepção do Supabase avisando que o guichê do Google está fechado.

No código-fonte do Supabase Auth, um pedido para /auth/v1/authorize primeiro procura o provedor, e qualquer problema com ele volta como um 400, com o código validation_failed e Unsupported provider: na frente do motivo. provider is not enabled é a primeira coisa que essa busca confere.

Então o Google nunca viu o pedido, e nada no console do Google vai explicar o erro. O seu app também não vê o erro: a biblioteca JavaScript do Supabase manda o navegador inteiro para esse endereço, então a página que falha é do Supabase, e o console do seu app fica vazio.

A mesma mensagem aparece com GitHub, Apple ou qualquer outro provedor desligado, e a chave fica no mesmo lugar. Apps no backend embutido do Lovable são configurados de outro jeito: a documentação de autenticação do Lovable descreve o Google como "managed by Lovable with no setup, or your own Google Cloud OAuth credentials." Este post é para apps no seu próprio projeto do Supabase, seja qual for a ferramenta que os construiu.

É o projeto certo do Supabase?

Confira isso antes de mudar qualquer coisa, porque a página de erro diz qual projeto respondeu.

O endereço da página de erro começa com a referência do seu projeto, a sequência de letras antes de .supabase.co. Abra o painel do Supabase e olhe a barra de endereços dele: a mesma referência vem depois de /project/. Se as duas forem diferentes, o seu app fala com outro projeto, como um que um builder criou para você ou uma cópia que você fez para testes. É nesse projeto que o Google tem de ser ligado.

Como corrigir "Unsupported provider: provider is not enabled"

Crie um cliente OAuth no Google e depois ligue o Google no Supabase com os dois valores que ele te dá. O guia de login com Google do Supabase tem os passos; aqui estão na ordem em que os dois consoles pedem. Os nomes são os das duas interfaces em inglês.

No Supabase, copie primeiro a URL de callback. Vá em Authentication, depois em Sign In / Providers, e abra Google. O painel mostra uma Callback URL com um botão para copiar. Ela tem esta cara: https://<project-ref>.supabase.co/auth/v1/callback.

No Google Cloud, crie o cliente. Na página Clients do Google Auth Platform, crie um ID de cliente OAuth do tipo Web application.

• Em Authorized JavaScript origins, adicione o endereço do seu app, por exemplo https://yourapp.com.
• Em Authorized redirect URIs, cole a URL de callback que você copiou no Supabase.
• Clique em Create e copie na hora o Client ID e o Client Secret. A página de ajuda do Google sobre clientes OAuth avisa: "you will only be able to view and download the full client secret once, at the time of its creation."

De volta ao Supabase, ligue. Ligue Enable Sign in with Google, cole o Client ID em Client IDs e o secret em Client Secret (for OAuth), e salve. O painel não salva o Google ligado sem um Client ID, mas salva com o campo do secret vazio. A descrição desse campo diz que o secret é para "the OAuth flow on the web", e um botão num app web é exatamente esse fluxo.

Depois clique de novo no seu botão. Se a mensagem ainda começar com "Unsupported provider", o final dela diz o que falta:

Por que o Google responde depois redirect_uri_mismatch

Porque a sua URL de callback não está na lista do cliente, escrita exatamente como o Supabase manda.

Esta é a segunda recepção. Quando o Supabase começa o login, ele passa a pessoa para o Google com um bilhete dizendo para onde devolvê-la: a URL de callback do seu projeto. O Google compara esse bilhete com as Authorized redirect URIs do cliente que você criou. A documentação de OAuth do Google descreve a falha em uma linha: "The redirect_uri passed in the authorization request does not match an authorized redirect URI for the OAuth client ID."

A comparação é exata. A mesma página diz: "the http or https scheme, case, and trailing slash ('/') must all match." Então uma entrada que termina em /auth/v1/callback/, com uma barra no fim, não bate com o endereço que o Supabase manda.

O endereço do seu próprio app não faz nada nessa lista. O Google devolve as pessoas ao Supabase, então o único endereço que ele confere é o callback do Supabase. O endereço do seu app vai na lista da outra recepção, Redirect URLs no Supabase, que decide para onde o Supabase manda as pessoas no fim de tudo. Quando essa lista está errada, as pessoas voltam logadas em localhost:3000, e isso tem um post só dele.

Depois de salvar, dê um tempo ao Google. A página de ajuda dele sobre clientes OAuth diz: "It may take 5 minutes to a few hours for changes made to these settings to take effect."

Onde fica o Client Secret

No painel do Supabase, e em nenhum outro lugar. O código do seu app nunca precisa dele.

O Client ID é público: ele vai no endereço da página de login do Google, onde qualquer um pode ler. O Client Secret é o que prova ao Google que um pedido vem do seu lado, e nessa montagem só o Supabase tem esse valor. Quando o seu app chama signInWithOAuth, a biblioteca manda o navegador para o Supabase, e é o Supabase Auth que fala com o Google usando o secret.

Então, se o seu builder colocou o secret no código do seu app, ou numa variável cujo nome começa com VITE_ ou NEXT_PUBLIC_, ele está no navegador de cada visitante. Essas variáveis são públicas de propósito. A página de ajuda do Google é direta: "Never add client secrets directly in your code or check them into version control systems such as Git or Subversion." Troque o secret na página do cliente no console do Google: clique em Add Secret, cole o novo secret no Supabase, depois Disable no antigo e apague. Tire o valor antigo do seu código também.

Para conferir o que o seu app no ar entrega aos visitantes, não é preciso abrir o builder. O nosso scan gratuito lê o seu app no ar do jeito que o navegador de um visitante lê e aponta as chaves secretas que reconhece, além de tabelas que respondem a qualquer um e cabeçalhos que faltam. Leva uns 20 segundos e não precisa de conta: escaneie o seu app.

Cuidando do app em que as pessoas agora fazem login

Assim que as pessoas entram com Google, as contas delas vivem no seu projeto do Supabase, e o app em que elas entram muda a cada deploy.

Reeve Monitor continua verificando o seu app no ar:

• se ele está no ar, a cada 60 segundos
• as nove verificações a cada hora, em até três apps, incluindo chaves secretas no código que o seu app envia aos visitantes
• uma mensagem quando um resultado muda, para que uma chave que sai num deploy posterior chegue até você sem você precisar ir olhar
• um relatório mensal, em linguagem simples, do que ele viu

Reeve Care guarda uma cópia do seu banco de dados Supabase, contas incluídas:

• uma cópia criptografada em uma programação, no armazenamento próprio da Reeve na UE, fora da sua conta do Supabase
• o schema auth, onde o Supabase guarda cada usuário e a identidade do Google com que ele entrou, para que voltem com todo o resto
• cada cópia verificada antes de contar, contando as linhas de cada tabela
• seus arquivos enviados também, assim que você conectar uma credencial do Storage
• uma restauração com um clique, com uma cópia de segurança do estado atual feita antes
• tudo o que o Monitor faz

O que fazer agora

Se as pessoas passam pelo Google e depois caem na página errada, o post sobre os redirecionamentos continua dali. O checklist de segurança de 10 minutos cobre o que mais olhar antes do lançamento.