Jede Plattform auf dieser Website behauptet, „Authentifizierung zu haben“. Dieser Begriff deckt sowohl ein Login-Formular ohne dahinterliegende Funktion ab als auch einen vollständigen Satz fertig eingebauter Wiederherstellungs-, Verifizierungs- und Sitzungsabläufe. Käufer, die sich mit dem bloßen Häkchen zufriedengeben, erfahren den Unterschied erst nach dem Launch, meist wenn ein echter Nutzer ausgesperrt wird und es keine Passwort-Reset-Seite gibt, an die man ihn verweisen kann. Dieser Leitfaden schlüsselt auf, was diese Behauptung eigentlich bedeuten sollte und wie man sie vor der Vertragsunterschrift prüft, verknüpft mit dem Kriterium Sicherheit und Zugriffskontrolle, das unter /methodology bewertet wird.
Das Häkchen verbirgt acht einzelne Entscheidungen
„Hat Authentifizierung“ ist eigentlich ein Bündel unabhängiger Abläufe, und eine Plattform kann einige davon liefern und die restlichen still auslassen:
- Login- und Registrierungsseiten - der sichtbare Teil, den jede Plattform in der Demo zeigt.
- Passwort-Reset - ein Self-Service-Ablauf, kein Support-Ticket, für das Konto, das Sie nicht selbst angelegt haben.
- Einmalpasswort (OTP) - E-Mail- oder SMS-Codes als Alternative zu einem gespeicherten Passwort.
- Magic Links - passwortloser Login über einen einzelnen per E-Mail versendeten Link.
- Zwei-Faktor-Authentifizierung (2FA) - ein zweiter Verifizierungsschritt zusätzlich zum Passwort.
- SSO (SAML/OpenID) - Login über den bestehenden Identitätsanbieter des Käufers, üblich bei Unternehmensbeschaffungen.
- Domain-beschränkte oder nur-auf-Einladung-Registrierung - Kontrolle darüber, wer überhaupt ein Konto anlegen darf, nicht nur, wer sich einloggen kann, sobald er eines hat.
- Sitzungsverwaltung und erzwungenes Abmelden - wie lange eine Sitzung gültig bleibt und ob ein Administrator sie beenden kann.
Eine Plattform, die „Authentifizierung hat“, kann alle acht als Schalter liefern oder nur den ersten Punkt liefern und die übrigen sieben Ihnen zum Bauen überlassen. Beides wird in einem Verkaufsgespräch ehrlich als „hat Authentifizierung“ beschrieben. Nur eines davon ist produktionsreif.
Warum KI-Generatoren die Login-Seite bauen und den Rest überspringen
KI-Codegeneratoren sind hervorragend darin, genau das zu bauen, was ein Prompt beschreibt, und ein Prompt beschreibt selten die Passwort-Wiederherstellung. Die Tools optimieren für den Idealfall: einen aufgeräumten Login-Bildschirm und ein funktionierendes Dashboard, weil genau das für eine Demo gebraucht wird und weil der Builder genau das explizit verlangt hat. Passwort-Reset, OTP-Verifizierung, Domain-Beschränkungen und Sitzungsablauf sind sekundäre Abläufe, an die niemand zu prompten dachte, also werden sie standardmäßig übersprungen.
Die Lücke ist während des Baus unsichtbar. Die App läuft, der Login funktioniert, die Demo wirkt fertig. Sichtbar wird sie beim ersten Mal, wenn ein echter Nutzer sein Passwort vergisst und es keine Wiederherstellungsseite gibt, oder beim ersten Mal, wenn die Sitzung eines ehemaligen Mitarbeiters hätte ablaufen müssen und es nicht tat. An diesem Punkt liefert der Builder keine Funktion mehr; er debuggt und programmiert unter Druck sensible Passwort-Reset-Logik und verbraucht dabei Prompts und Credits genau für den Ablauf, der standardmäßig hätte mitgeliefert werden sollen. Das ist ein dokumentiertes, branchenweites Muster, kein Softr-spezifisches Argument: Forschung zu Fehlermodi beim Vibe-Coding nennt „fragile Authentifizierung und vergessene Hilfsabläufe“ als eine der Standardarten, wie KI-generierte Apps in der Produktion versagen.
- Login-Screen erstellt
- Login-Bildschirm funktioniert
- Funktionsfähiges Dashboard erstellt
- Funktionierendes Dashboard
- Passwort-Reset fehlt
- Nutzer vergisst Passwort, keine Wiederherstellungsseite
- Sitzungsablauf nicht verwaltet
- Sitzung von Ex-Mitarbeiter läuft nie ab
- OTP-Verifizierung übersprungen
- Auth-Debugging unter Zeitdruck
Was das auf einer Scorecard tatsächlich misst
Sicherheit und Zugriffskontrolle auf dieser Website ist kein einfaches Ja/Nein dafür, „ob es einen Login gibt“. Es bewertet, wie viel von diesem Achter-Bündel fertig eingebaut ausgeliefert wird gegenüber dem, was der Käufer selbst codieren oder konfigurieren muss, und wie granular die resultierende Zugriffskontrolle ist, sobald echte Nutzer im System sind.
Die Spannbreite zwischen den auf dieser Website bewerteten Plattformen ist groß. Softr erreicht 8,5, weil Passwort-, OTP-, Magic-Link- und Google-Login als Schalter ausgeliefert werden, Nutzergruppen Zeilen-Beschränkungen bis auf einzelne Schaltflächen tragen und nur SSO dem Enterprise-Custom-Plan vorbehalten ist. Retool erreicht 7,5, stark bei intern ausgerichtetem SSO und Audit-Logs, aber die Scorecard vermerkt, dass es keine integrierten Login-, Registrierungs- oder Passwort-Reset-Abläufe für externe Nutzer gibt; diese werden individuell programmiert. Bubble erreicht 6,5 durch serverseitige Datenschutzregeln, die einmal konfiguriert leistungsstark sind, deren Konfiguration aber komplett beim Builder liegt, und eine übersehene Regel schlägt lautlos fehl. Weiter unten erreichen Lovable und Bolt beide 3,5, weil ihre Sicherheit von generiertem Code und Datenbankregeln abhängt, die der Builder selbst schreiben und prüfen muss, ohne visuelle Möglichkeit zu verifizieren, was tatsächlich offenliegt.
Diese Spannbreite ist der Kern dieses Leitfadens. „Hat Authentifizierung“ sagt Ihnen fast nichts darüber, wo eine Plattform auf dieser Skala steht.
Die Bewertungscheckliste
Prüfen Sie Folgendes in dieser Reihenfolge, bevor Sie sich auf eine Plattform festlegen:
- Listen Sie auf, welche der acht Abläufe fertig eingebaut sind, nicht nur „unterstützt“. Fragen Sie konkret: Ist der Passwort-Reset eine bereits existierende Seite, oder eine Funktion, die Sie später mit eigenem Code konfigurieren? Der Unterschied zwischen „nativ“ und „mit Entwicklungsaufwand möglich“ ist der Unterschied zwischen einem Schalter und einem Projekt.
- Prüfen Sie, welche Plan-Stufe SSO und erweiterte Zugriffskontrollen einschränkt. Besonders SSO ist auf diesem Markt regelmäßig eine Enterprise-Funktion. Softrs Custom-Plan, Retools Enterprise-Stufe und ähnlich benannte Top-Pläne anderer Anbieter behalten es sich alle vor, sodass die Plattform, die auf ihrer Marketingseite „SSO hat“, es im Plan, den Sie sich tatsächlich leisten können, möglicherweise nicht hat.
- Bestätigen Sie, ob die Zugriffskontrolle unter die Seitenebene reicht. Rollenbasierter Login ist Grundvoraussetzung. Was echte Sicherheit ausmacht, ist, ob Beschränkungen bis zu einzelnen Datensätzen, Feldern und Schaltflächen reichen oder bei „eingeloggt vs. nicht eingeloggt“ enden.
- Testen Sie die Sitzungsverwaltung direkt. Loggen Sie sich ein und prüfen Sie dann, ob Sie eine Sitzung erzwungen beenden, sehen können, wer aktuell eingeloggt ist, und die Sitzungsdauer kontrollieren können. Kundenportale mit wechselnden externen Nutzern brauchen das; ein internes Tool für zwei Personen vielleicht nicht.
- Passen Sie die Antwort an die App-Klasse an, nicht an die beste Feature-Liste der Plattform.
Warum die Antwort davon abhängt, wer sich einloggt
Das richtige Maß an Authentifizierung ist nicht fest vorgegeben; es hängt davon ab, für wen die App gedacht ist.
| App-Klasse | Wer loggt sich ein | Was tatsächlich zählt |
|---|---|---|
| Internes Tool, 8 Kollegen | Konten, die Sie erstellen und kontrollieren | Einfacher Login mit Rollenprüfungen reicht oft aus; ein vergessenes Passwort können Sie manuell zurücksetzen |
| Kundenportal, Hunderte externe Nutzer | Konten, die Sie nicht einzeln verwalten können | Selbstständiger Passwort-Reset, Domain- oder Einladungsbeschränkungen und Sitzungskontrollen sind nicht mehr optional |
Ein internes Tool für 8 Personen kann mit Passwort-Login und klarer Rollentrennung bestehen, weil jeder Kontoinhaber jemand ist, dem Sie persönlich helfen können. Ein Kundenportal für Hunderte externe Nutzer kann so nicht funktionieren. Selbstständige Wiederherstellung ist kein bloßes Extra mehr, sobald Sie nicht mehr jedes vergessene Passwort persönlich zurücksetzen können, und domain-beschränkte oder nur-auf-Einladung-Registrierung wird zur einzig realistischen Möglichkeit, eine öffentlich zugängliche App vor unautorisierten Konten zu schützen. Dieselbe Plattform für beide Anwendungsfälle ohne Anpassung zu bewerten, ist der häufigste Bewertungsfehler von Käufern.
Kaufen Sie für die App, die Sie tatsächlich bauen
Die Lösung ist nicht „immer jeden Ablauf verlangen“. Sie besteht darin, die Nutzerbasis Ihrer App ehrlich zu benennen, bevor Sie einkaufen. Eine Handvoll vertrauenswürdiger Kollegen kommt mit weniger aus. Hunderte externe Kunden können das nicht, und Plattformen, die Passwort-Reset, OTP und Domain-Beschränkung standardmäßig auslassen, werden diese Lücke genau dann sichtbar machen, wenn sie am teuersten zu beheben ist, nachdem bereits echte Konten existieren. Bewerten Sie die Plattform anhand der Abläufe, die Ihre tatsächlichen Nutzer brauchen werden, mit der vollständigen Aufschlüsselung unter /methodology, und sehen Sie sich Bubble vs Softr sowie die besten Plattformen für Kundenportale an, um zu sehen, wie sich das für eine bestimmte App-Klasse auswirkt.