Social-Login und Captcha aktivieren

Social-Login und Captcha sind beide standardmäßig aus. Beides wird rein über Konfiguration aktiviert — keine Datenbanktabelle, keine Migration, keine Lizenz (beides ist in der Community-Edition enthalten, siehe ADR 0064).

Hinweis

Jedes Secret unten wird erst aus der Umgebung, dann aus der supacloud/app-Map in OpenBao aufgelöst (siehe ADR 0036 — konsolidiertes Secret-Provisioning). Nutze in Produktion den Vault; der Wert landet weder in einer Config-Struktur noch in einer Logzeile.

Social-Login aktivieren

SupaCloud liefert Google und GitHub mit. Ein Provider erscheint erst dann auf der Anmeldeseite, wenn beide — Client-ID und Client-Secret — auflösbar sind; andernfalls fehlt der Button schlicht. So kann nie ein Button angeboten werden, der nicht funktionieren kann.

1. OAuth-App beim Provider registrieren

Lege beim Provider eine OAuth-App an und trage als autorisierte Redirect-URI ein:

<deine öffentliche URL>/api/auth/social/google/callback
<deine öffentliche URL>/api/auth/social/github/callback

<deine öffentliche URL> ist exakt die SUPACLOUD_PUBLIC_URL, unter der deine Instanz ausgeliefert wird (ohne abschließenden Schrägstrich). Angefragte Scopes sind openid email profile (Google) bzw. die User- und E-Mail-Scopes (GitHub) — genug, um eine verifizierte E-Mail-Adresse zu lesen, mehr nicht.

Achtung

SupaCloud verlangt eine verifizierte Adresse: Google muss email_verified zusichern, und die GitHub-Adresse muss die primäre und verifizierte E-Mail des Kontos sein. Ein Provider, der die Adresse nicht belegen kann, wird abgelehnt.

2. Zugangsdaten konfigurieren

Variable	Zweck
SUPACLOUD_SOCIAL_GOOGLE_CLIENT_ID	Google-OAuth-Client-ID
SUPACLOUD_SOCIAL_GOOGLE_CLIENT_SECRET	Google-OAuth-Client-Secret (vault-fähig)
SUPACLOUD_SOCIAL_GITHUB_CLIENT_ID	GitHub-OAuth-Client-ID
SUPACLOUD_SOCIAL_GITHUB_CLIENT_SECRET	GitHub-OAuth-Client-Secret (vault-fähig)

Starte den Server neu. Die Anmeldeseite zeigt nun je konfiguriertem Provider einen Button, und GET /config weist die aktivierten Methoden aus.

3. Was deine Nutzer erleben

• Eine neue E-Mail-Adresse legt ein Konto an, genau wie eine normale Registrierung (wartende Workspace-Einladungen für diese Adresse werden eingelöst).
• Eine Adresse, die bereits zu einem Konto gehört, wird niemals automatisch zusammengeführt. Der Nutzer erfährt, dass ein Konto existiert, meldet sich mit seiner bisherigen Methode an und verknüpft den Provider unter Einstellungen → Verbundene Konten.
• Ein Nutzer mit Authenticator-App durchläuft nach dem Provider-Redirect weiterhin seinen zweiten Faktor. Die 2FA gehört zu SupaCloud, nicht zum Provider.
• Die letzte verbleibende Anmeldemethode lässt sich nie trennen.

Captcha aktivieren

SupaCloud nutzt ALTCHA, eine selbst gehostete Proof-of-Work-Prüfung. Der Browser löst sie per WebCrypto; der Server verifiziert sie zustandslos gegen eine HMAC-signierte Challenge. Es gibt kein Fremdskript und keinen Fremd-Netzwerkaufruf — es verlassen keine Besucherdaten deine Instanz.

Das Setzen des HMAC-Secrets schaltet die Funktion ein; alles Weitere ist optional.

Variable	Default	Zweck
SUPACLOUD_CAPTCHA_HMAC_SECRET	(nicht gesetzt — Captcha aus)	Signiert und verifiziert Challenges. Setzen zum Aktivieren.
SUPACLOUD_CAPTCHA_MAXNUMBER	eingebaut	Schwierigkeit des Proof-of-Work (Suchraum). Höher bremst Bots — und echte Browser.
SUPACLOUD_CAPTCHA_TTL_SECS	eingebaut	Gültigkeitsdauer einer Challenge.
SUPACLOUD_CAPTCHA_LOGIN_FAILURE_THRESHOLD	eingebaut	Fehlanmeldungen aus einer Quelle, bevor das Anmeldeformular ein Captcha scharfschaltet.

Wo es scharf wird. register, Magic-Link-Anforderung, Passwort-Reset-Anforderung und Bestätigungsmail-Anforderung verlangen immer eine Lösung. Die Anmeldung schaltet es erst nach LOGIN_FAILURE_THRESHOLD Fehlversuchen aus derselben Quelle scharf — eine normale Anmeldung sieht also nie eines.

Fail-closed und Einmalnutzung

Mit gesetztem Secret ist das Gate fail-closed — eine fehlende oder ungültige Lösung wird abgelehnt. Jede gelöste Challenge ist einmalig nutzbar; eine verbrauchte Lösung lässt sich nicht erneut einreichen, auch nicht in der letzten Sekunde ihrer Gültigkeit.

Die Prüfung benötigt einen sicheren (HTTPS-)Kontext. Auf einer reinen http://-Herkunft stellt der Browser kein crypto.subtle bereit — die Oberfläche sagt das dann ausdrücklich, statt einen Retry anzubieten, der nie gelingen kann. Liefere über HTTPS aus.

Rate-Limits abstimmen

Zwei unabhängige Limits schützen die Authentifizierungs-Endpunkte:

• Das bestehende Per-IP-Transportlimit (tower_governor).
• Ein Fixed Window pro Identität (5 / 60 s) auf login, register, magic, reset und verify — denn ein Per-IP-Limit stoppt keine verteilte Credential-Stuffing-Kampagne gegen ein einzelnes Konto.

Das Anmelde-Limit ist zusätzlich nach Quelle gescoped, damit jemand, der lediglich die E-Mail-Adresse eines Opfers kennt, nicht das gemeinsame Fenster erschöpfen und den rechtmäßigen Inhaber aussperren kann. Die mailversendenden Endpunkte bleiben rein per E-Mail geschlüsselt — dort begrenzt die Drossel den ausgehenden Mailversand.

Betrieb hinter einem Reverse-Proxy

Gefahr

Die Sicherheitszähler ignorieren CF-Connecting-IP und X-Real-IP, es sei denn, du deklarierst das Deployment als proxy-fronted. Setze SUPACLOUD_TRUSTED_FORWARDING nur dann, wenn ein von dir kontrollierter Proxy die Forwarding-Header bei jeder eingehenden Anfrage überschreibt. Sonst kann ein Angreifer den Headerwert pro Anfrage rotieren und das Captcha dauerhaft entschärft halten.

Mit gesetztem SUPACLOUD_TRUSTED_FORWARDING wird die Client-IP aus X-Forwarded-For über denselben Rechts-nach-links-Lauf abgeleitet, der vertrauenswürdige Hops überspringt; lässt sich keine vertrauenswürdige Adresse ableiten, gilt der rohe Socket-Peer.

Prüfen

1. Öffne die Anmeldeseite in einem privaten Fenster. Jeder konfigurierte Provider zeigt einen Button.

2. Melde dich über den Provider mit einer der Instanz unbekannten Adresse an — es entsteht ein Konto und du bist angemeldet.

3. Melde dich ab und versuche denselben Provider mit einer Adresse, die bereits ein Passwortkonto hat: Du erfährst, dass ein Konto existiert, und wirst nicht angemeldet.

4. Hast du das Captcha aktiviert, sende das Anmeldeformular LOGIN_FAILURE_THRESHOLD mal mit falschem Passwort ab — der Prüfschritt erscheint.

Verwandt

• Mit Google oder GitHub anmelden — die Endnutzer-Sicht
• OIDC-SSO konfigurieren — Enterprise-Single-Sign-on (ein anderer Mechanismus)