Supabase-Fehler: "Unsupported provider: provider is not enabled"

Du baust einen Knopf "Mit Google anmelden" in deine App ein und drückst ihn. Statt der Kontoauswahl von Google zeigt dein Browser das hier:

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

In der Adressleiste steht dein Supabase-Projekt, etwa https://abcdefghij.supabase.co/auth/v1/authorize?provider=google&redirect_to=…. Du hast die App mit Lovable, Bolt, v0, Cursor, Claude Code oder Replit gebaut, der Knopf kam mit dem Code, und in diesem Code sieht nichts falsch aus.

"Unsupported provider: provider is not enabled" heißt: Supabase Auth, der Teil von Supabase, der Leute anmeldet, hat Google in dem Projekt ausgeschaltet, mit dem deine App redet. Die Lösung ist ein Schalter und zwei Werte, die du von Google bekommst. Danach prüft Google eine eigene Liste, und von dieser Liste kommt der nächste Fehler, redirect_uri_mismatch.

Die Falle steckt in dieser zweiten Liste. Die Adresse, die sich dort richtig anfühlt, ist die deiner eigenen App, und Google benutzt sie nie, weil Google niemanden zu deiner App schickt.

Was bedeutet "Unsupported provider: provider is not enabled"?

Es bedeutet, dass Supabase sich geweigert hat, eine Anmeldung mit Google zu beginnen, weil Google in dem Projekt ausgeschaltet ist, das die Anfrage bekommen hat.

Die Anmeldung mit Google ist eine Rundreise über zwei Empfangstresen. Deine App schickt die Person zum Tresen von Supabase. Supabase schickt sie weiter zum Tresen von Google, wo sie zeigt, wer sie ist, Google schickt sie zurück zu Supabase, und Supabase schickt sie angemeldet nach Hause zu deiner App. Jeder Tresen schickt Leute nur dorthin, wo seine eigenen Einstellungen es erlauben. Diese Meldung ist der Tresen von Supabase, der sagt, dass sein Google-Schalter geschlossen ist.

Im Quellcode von Supabase Auth schlägt eine Anfrage an /auth/v1/authorize zuerst den Anbieter nach, und jedes Problem damit kommt als 400 zurück, mit dem Code validation_failed und Unsupported provider: vor dem Grund. provider is not enabled ist das Erste, was diese Prüfung ansieht.

Google hat die Anfrage also nie gesehen, und nichts in der Konsole von Google wird sie erklären. Deine App sieht den Fehler auch nicht: Die JavaScript-Bibliothek von Supabase schickt den ganzen Browser zu dieser Adresse, die Seite, die scheitert, gehört also Supabase, und die Konsole deiner App bleibt leer.

Dieselbe Meldung kommt bei GitHub, Apple oder jedem anderen Anbieter, der ausgeschaltet ist, und der Schalter sitzt an derselben Stelle. Apps auf dem eingebauten Backend von Lovable sind anders eingerichtet: Die Doku zur Authentifizierung von Lovable führt Google als "managed by Lovable with no setup, or your own Google Cloud OAuth credentials." Dieser Beitrag ist für Apps auf deinem eigenen Supabase-Projekt, egal mit welchem Werkzeug sie gebaut sind.

Ist es das richtige Supabase-Projekt?

Prüf das, bevor du etwas änderst, denn die Fehlerseite nennt das Projekt, das geantwortet hat.

Die Adresse auf der Fehlerseite beginnt mit der Referenz deines Projekts, der Buchstabenfolge vor .supabase.co. Öffne dein Supabase-Dashboard und sieh in seine eigene Adressleiste: Dieselbe Referenz steht hinter /project/. Weichen die beiden ab, redet deine App mit einem anderen Projekt, etwa einem, das ein Builder für dich angelegt hat, oder einer Kopie, die du zum Testen gemacht hast. In diesem Projekt muss Google eingeschaltet werden.

So behebst du "Unsupported provider: provider is not enabled"

Leg bei Google einen OAuth-Client an und schalte dann Google in Supabase mit den zwei Werten ein, die du von dort bekommst. Supabases Anleitung zur Anmeldung mit Google hat die Schritte; hier stehen sie in der Reihenfolge, in der die beiden Konsolen danach fragen. Die Bezeichnungen sind die englischen aus beiden Oberflächen.

In Supabase zuerst die Callback-URL kopieren. Geh zu Authentication, dann Sign In / Providers, und öffne Google. Dort steht eine Callback URL mit einem Knopf zum Kopieren. Sie sieht so aus: https://<project-ref>.supabase.co/auth/v1/callback.

In Google Cloud den Client anlegen. Leg auf der Seite Clients der Google Auth Platform eine OAuth-Client-ID vom Typ Web application an.

• Trag unter Authorized JavaScript origins die Adresse deiner App ein, etwa https://yourapp.com.
• Füg unter Authorized redirect URIs die Callback-URL ein, die du bei Supabase kopiert hast.
• Drück Create und kopier die Client ID und das Client Secret sofort. Googles Hilfeseite zu OAuth-Clients warnt: "you will only be able to view and download the full client secret once, at the time of its creation."

Zurück in Supabase einschalten. Schalte Enable Sign in with Google ein, füg die Client ID unter Client IDs und das Secret unter Client Secret (for OAuth) ein und speichere. Ohne Client ID speichert das Dashboard Google nicht als eingeschaltet, mit leerem Secret-Feld aber schon. Die Beschreibung dieses Felds sagt, das Secret sei für "the OAuth flow on the web", und ein Knopf in einer Web-App ist genau dieser Ablauf.

Drück dann deinen Knopf noch einmal. Beginnt die Meldung immer noch mit "Unsupported provider", sagt ihr Ende, was noch fehlt:

Warum Google danach redirect_uri_mismatch meldet

Weil deine Callback-URL nicht auf der Liste des Clients steht, genau so geschrieben, wie Supabase sie schickt.

Das ist der zweite Tresen. Wenn Supabase die Anmeldung beginnt, übergibt es die Person an Google, mit einem Zettel, wohin sie zurückgeschickt werden soll: zur Callback-URL deines Projekts. Google vergleicht diesen Zettel mit Authorized redirect URIs des Clients, den du angelegt hast. Seine OAuth-Dokumentation beschreibt den Fehler in einer Zeile: "The redirect_uri passed in the authorization request does not match an authorized redirect URI for the OAuth client ID."

Der Abgleich ist exakt. Dieselbe Seite sagt: "the http or https scheme, case, and trailing slash ('/') must all match." Ein Eintrag, der auf /auth/v1/callback/ endet, mit einem Schrägstrich am Ende, passt also nicht zu der Adresse, die Supabase schickt.

Die Adresse deiner eigenen App bewirkt auf dieser Liste nichts. Google schickt die Leute zurück zu Supabase, die einzige Adresse, die es je prüft, ist also der Callback von Supabase. Die Adresse deiner App gehört auf die Liste des anderen Tresens, Redirect URLs bei Supabase, die entscheidet, wohin Supabase die Leute ganz am Ende schickt. Ist diese Liste falsch, landen die Leute angemeldet auf localhost:3000, und dazu gibt es einen eigenen Beitrag.

Gib Google nach dem Speichern etwas Zeit. Seine Hilfeseite zu OAuth-Clients sagt: "It may take 5 minutes to a few hours for changes made to these settings to take effect."

Wo das Client Secret hingehört

Ins Supabase-Dashboard und nirgendwo sonst hin. Der Code deiner App braucht es nie.

Die Client ID ist öffentlich: Sie steht in der Adresse der Anmeldeseite von Google, wo jeder sie lesen kann. Das Client Secret ist das, was Google beweist, dass eine Anfrage von deiner Seite kommt, und in diesem Aufbau hat es nur Supabase. Wenn deine App signInWithOAuth aufruft, schickt die Bibliothek den Browser zu Supabase, und Supabase Auth ist es, das mit dem Secret mit Google redet.

Hat dein Builder das Secret also in den Code deiner App gesteckt, oder in eine Variable, deren Name mit VITE_ oder NEXT_PUBLIC_ beginnt, liegt es im Browser jedes Besuchers. Diese Variablen sind absichtlich öffentlich. Googles Hilfeseite sagt es deutlich: "Never add client secrets directly in your code or check them into version control systems such as Git or Subversion." Ersetz es auf der Seite des Clients in der Konsole von Google: Drück Add Secret, füg das neue Secret bei Supabase ein, dann Disable beim alten und lösch es. Nimm den alten Wert auch aus deinem Code.

Um zu prüfen, was deine Live-App an Besucher ausliefert, musst du den Builder nicht öffnen. Unser kostenloser Scan liest deine Live-App so, wie der Browser eines Besuchers es tut, und meldet die geheimen Schlüssel, die er erkennt, dazu Tabellen, die jedem antworten, und fehlende Header. Er dauert etwa 20 Sekunden und braucht kein Konto: scanne deine App.

Die App im Blick behalten, bei der sich jetzt Leute anmelden

Sobald sich Leute mit Google anmelden, liegen ihre Konten in deinem Supabase-Projekt, und die App, bei der sie sich anmelden, ändert sich mit jedem Deploy.

Reeve Monitor prüft deine Live-App weiter:

• ob sie erreichbar ist, alle 60 Sekunden
• alle neun Prüfungen jede Stunde, für bis zu drei Apps, einschließlich geheimer Schlüssel im Code, den deine App an Besucher schickt
• eine Nachricht, wenn sich ein Ergebnis ändert, damit dich ein Schlüssel, der mit einem späteren Deploy hinausgeht, erreicht, ohne dass du nachsehen musst
• ein monatlicher Bericht in klarer Sprache über das, was er gesehen hat

Reeve Care hält eine Kopie deiner Supabase-Datenbank, samt Konten:

• eine verschlüsselte Kopie nach Zeitplan, auf Reeves eigenem Speicher in der EU, außerhalb deines Supabase-Kontos
• das Auth-Schema, in dem Supabase jeden Nutzer und die Google-Identität hält, mit der er sich angemeldet hat, damit sie mit allem anderen zurückkommen
• jede Kopie geprüft, bevor sie zählt, durch Zählen der Zeilen in jeder Tabelle
• auch deine hochgeladenen Dateien, sobald du einen Storage-Zugang verbindest
• eine Wiederherstellung per Klick, mit einer Sicherheitskopie des aktuellen Stands vorab
• alles, was Monitor tut

Was du jetzt tun solltest

Kommen die Leute durch Google und landen dann auf der falschen Seite, macht der Beitrag zu den Weiterleitungen dort weiter. Die 10-Minuten-Sicherheitscheckliste zeigt, was du vor dem Start sonst noch ansehen solltest.