Generic-OIDC-Anmeldung

Unter Einstellungen → Integrationen konfigurierst du den OIDC-Provider (Authentik, Keycloak, Zitadel, …), mit dem sich Nutzer anmelden können.

In der App-Datenbank stehen nur nicht-geheime Werte; das Client Secret gehört immer in die Umgebung des Auth-Backends.

Public Client oder Confidential Client?

Beides funktioniert — entscheide dich für eine Variante:

Public Client (ohne Secret)

Im IdP: App als public Client mit PKCE anlegen.
Redirect-URI: die Callback-URL aus Einstellungen → Integrationen.
Auth-Backend: Issuer/Discovery-URL und Client-ID setzen, die Secret-Variable weglassen.

Confidential Client (mit Secret)

Im IdP: App als confidential Client anlegen und das Secret kopieren.
Auth-Backend: die Secret-Variable zusätzlich setzen.
Das Secret niemals in die App-Einstellungen eintragen — diese Tabelle ist für alle angemeldeten Nutzer lesbar.

Welche Umgebungsvariablen brauche ich?

Das selbst gehostete Auth-Backend (GoTrue/Supabase Auth) benennt seine Variablen nach der Provider-ID, und der generische OIDC-Provider ist dort unter der ID keycloak registriert. Diese ID gibt das Auth-Backend vor, die Variablennamen lassen sich also nicht umbenennen — nur die Beschriftung in dieser App heisst „Generic OIDC“.

GOTRUE_EXTERNAL_KEYCLOAK_ENABLED=true
GOTRUE_EXTERNAL_KEYCLOAK_URL=https://auth.example.com/application/o/cashflow/
GOTRUE_EXTERNAL_KEYCLOAK_CLIENT_ID=cashflow
GOTRUE_EXTERNAL_KEYCLOAK_REDIRECT_URI=https://<supabase-host>/auth/v1/callback
# nur bei Confidential Client:
GOTRUE_EXTERNAL_KEYCLOAK_SECRET=<client secret>

Bei einem Public Client lässt du die letzte Zeile einfach weg. Nach Änderungen den Auth-Container neu starten.

Wie prüfe ich die Konfiguration?

Trage die Discovery-URL (…/.well-known/openid-configuration) unter Einstellungen → Integrationen ein und klicke Test. Das Dokument wird serverseitig geladen und Issuer, Authorize-Endpoint und Laufzeit werden angezeigt. Ein Fehler bedeutet falsche URL, TLS- oder Netzwerkprobleme — das Client Secret wird dabei nicht geprüft, ein falsches Secret zeigt sich erst beim echten Login (invalid_client).

Verknüpfen schlägt mit „manual_linking_disabled“ fehl

Manuelles Identity-Linking ist im Auth-Backend standardmässig deaktiviert. Aktiviere es und starte den Auth-Container neu:

GOTRUE_SECURITY_MANUAL_LINKING_ENABLED=true

Solange die Variable fehlt, liefern die Verknüpfen-Buttons unter Einstellungen → Verknüpfte Konten und der Hinweis nach dem Login manual_linking_disabled. Das hat nichts mit dem OIDC-Test zu tun, der nur das Discovery-Dokument prüft.

Bestehendes Konto mit gleicher E-Mail

Meldest du dich per OIDC mit einer E-Mail an, die bereits ein Passwort-Konto hat, entsteht kein zweites Konto, sofern du die Verknüpfung bestätigst. Methoden lassen sich jederzeit unter Einstellungen → Verknüpfte Konten verbinden und trennen (setzt aktiviertes manuelles Linking voraus, siehe oben).