Auf einen Blick
| Login-Methode | Was deine Nutzer tun | Gesendete E-Mails | Mit Proxy Mail QA testen |
|---|---|---|---|
| E-Mail und Passwort | Ein Passwort wählen, dann die E-Mail bestätigen | Bestätigung, Passwort-Reset, E-Mail-Änderung | Ja, jede |
| E-Mail-Code | Einen kurzen Code aus einer E-Mail eintippen | Bei jeder Anmeldung ein neuer Code | Ja, mit Kopieren-Button |
| Magic Link | Auf einen Link in einer E-Mail klicken | Bei jeder Anmeldung ein neuer Link | Ja, und wir öffnen den Link nie vorher |
| Google, Apple, Microsoft oder GitHub | Auf einen Button klicken und das Konto wählen | Keine zum Anmelden | Nein: Nutze ein echtes Konto, das dir gehört |
| SMS-Code | Einen Code aus einer SMS eintippen | Keine: Es ist eine SMS | Nein: Wir empfangen nur E-Mails |
| Firmen-Anmeldung (SSO) | Über den Login des Arbeitgebers anmelden | Keine zum Anmelden | Nein |
Egal, wofür du dich entscheidest: Deine App verschickt weiterhin eigene E-Mails, etwa Einladungen, Belege und Benachrichtigungen. Mit jedem Login kannst du prüfen, ob diese ankommen und an die richtige Stelle verlinken.
E-Mail und Passwort
Die Methode, die jeder kennt. Nutzer wählen ein Passwort, und wenn die E-Mail-Bestätigung aktiv ist, bekommen sie eine E-Mail mit einem Link oder Code und können sich erst anmelden, wenn sie ihn verwenden.
Gesendete E-Mails: eine Bestätigung bei der Registrierung, Passwort-Resets und eine E-Mail zur Bestätigung einer neuen Adresse, wenn jemand seine ändert.
Was meistens schiefgeht:
- Die Bestätigung ist aus, sodass sich jeder mit einer fremden Adresse oder einem Tippfehler registrieren kann und du die Person nie erreichst.
- Die Bestätigung ist an, aber die E-Mail kommt nie an, oft weil die App noch den Start-Absender ihres Builders oder ihrer Datenbank nutzt, der niedrige Limits hat. Warum E-Mails nicht ankommen.
- Der Link öffnet localhost oder eine Vorschauadresse statt deiner veröffentlichten App. So behebst du es.
- Der Link zum Zurücksetzen des Passworts führt auf eine Seite, auf der man kein neues Passwort wählen kann.
So testest du es: Registriere dich mit einer neuen Adresse und nutze den Link oder Code. Melde dich ab und wieder an. Fordere dann einen Passwort-Reset an und schließe ihn ab. Schritt für Schritt.
E-Mail-Codes
Nutzer geben ihre E-Mail ein, bekommen einen kurzen Code (oft 6 Ziffern) und tippen ihn ein. Es gibt kein Passwort zu merken. Manche Apps nutzen einen Code auch zur Bestätigung der Registrierung: Base44 und Clerk tun das beide.
Gesendete E-Mails: bei jeder Anmeldung ein neuer Code.
Was meistens schiefgeht:
- Der Code läuft ab, bevor die E-Mail ankommt.
- Ein zweiter angeforderter Code macht den ersten nicht ungültig, oder macht beide ungültig.
- Wer zweimal anfragt, bekommt „too many requests“ und ist ausgesperrt.
So testest du es: Fordere einen Code an und nutze ihn. Fordere zwei hintereinander an und prüfe, dass nur der neueste funktioniert. Proxy Mail QA zeigt einen Countdown, wenn in der E-Mail steht, wie lange der Code gilt. Mehr zum Testen von Codes.
Magic Links
Nutzer geben ihre E-Mail ein und klicken auf den Link, den du ihnen schickst. Ein Klick, kein Passwort.
Gesendete E-Mails: bei jeder Anmeldung ein neuer Link.
Was meistens schiefgeht:
- Der Link öffnet localhost statt deiner App.
- Der Link funktioniert nicht in einem anderen Browser oder auf einem Handy, auf dem die Mail-App ihren eigenen Browser öffnet.
- E-Mail-Sicherheitsscanner mancher Arbeitgeber öffnen Links, bevor die Person es tut, und verbrauchen sie damit.
So testest du es: Fordere einen Link an und öffne ihn im selben Browser, dann probiere ihn auf einem anderen Gerät. Prüfe, dass ein benutzter oder abgelaufener Link erklärt, was zu tun ist. Proxy Mail QA öffnet oder lädt Links nie vorab, daher ist deiner noch frisch, wenn du klickst. Mehr zu Magic Links.
Buttons für Google, Apple, Microsoft und GitHub
Nutzer klicken auf Weiter mit Google (oder Apple, Microsoft oder GitHub) und wählen ihr Konto. Deine App verarbeitet nie ein Passwort, deshalb fügen KI-App-Builder diese so bereitwillig hinzu.
Gesendete E-Mails: keine zur Anmeldung. Das übernimmt der Anbieter.
Was meistens schiefgeht:
- In der Vorschau klappt es, aber nicht in der veröffentlichten App oder auf deiner eigenen Domain. Die neue Adresse steht nicht auf der Liste erlaubter Redirects des Anbieters, und Google zeigt
redirect_uri_mismatch. - Der Anmeldebildschirm zeigt den Namen deines Builders statt den deiner App. Lovable und Base44 bieten beide eine gemeinsame Konfiguration, die sofort funktioniert. Wechsle vor dem Launch zu deinen eigenen Zugangsdaten, wenn dir das wichtig ist.
- Jemand registriert sich mit E-Mail und Passwort und klickt später mit derselben Adresse auf Weiter mit Google. Entscheide, ob das ein Konto oder ein Fehler sein soll, und teste es.
- Sign in with Apple kann die E-Mail-Adresse verbergen. Deine App erhält eine Adresse, die auf
privaterelay.appleid.comendet, und deine E-Mails erreichen die Person nur, wenn du deine Absenderdomain bei Apple registriert hast.
So testest du es: Diese Buttons brauchen ein echtes Konto, nutze also ein eigenes Google- oder Apple-Konto, in der veröffentlichten App ebenso wie in der Vorschau.
Telefon-Codes
Nutzer geben ihre Telefonnummer ein und bekommen einen Code per SMS. Dafür braucht es einen SMS-Anbieter wie Twilio, und jede SMS kostet Geld. Proxy Mail QA empfängt nur E-Mails und kann hier nicht helfen.
Firmen-Anmeldung (SSO)
Für Apps, die an Unternehmen verkauft werden: Mitarbeitende melden sich über den Login ihres Arbeitgebers an, etwa Okta oder Microsoft Entra ID, meist über einen Standard namens SAML. Lovable und Base44 unterstützen das beide. Zur Anmeldung wird keine E-Mail verschickt, Team-Einladungen gehen aber meist weiterhin per E-Mail raus.
Anmeldung mit dem Konto des Builders
Manche Builder lassen Nutzer sich mit einem Konto beim Builder selbst anmelden. Mit Replit Auth melden sich deine Nutzer mit einem Replit-Konto auf einer Seite mit Replit-Branding an, und Replit verschickt die E-Mails, etwa Passwort-Resets. Lovable bietet ebenfalls Sign in with Lovable. Das passt für interne Tools und Apps für andere Builder. Für eine öffentliche App willst du meist eigene Konten: Bei Replit ist das Clerk Auth.
Was sollte eine neue App nutzen?
Für die meisten Apps: E-Mail plus Google.
- Google ist für die meisten Menschen die schnellste Registrierung.
- E-Mail deckt alle anderen ab: Menschen ohne Google, Menschen mit einer Arbeitsadresse und alle, die ihr Konto lieber nicht verknüpfen.
- Nimm lieber Codes oder Magic Links, wenn du keine Passwörter willst. Codes funktionieren besser, wenn Leute E-Mails auf dem Handy lesen, deine App aber am Laptop nutzen.
- Lass die E-Mail-Bestätigung an und verschicke E-Mails vor dem Launch von deiner eigenen Domain.
Welchen Login richtet dein Builder ein?
| Gebaut mit | Login, den du bekommst | Anmeldeoptionen |
|---|---|---|
| Lovable | Lovable Cloud oder dein eigenes Supabase-Projekt | E-Mail (Standard), Google, Apple, Microsoft, Telefon, SAML SSO, Sign in with Lovable |
| Replit | Replit Auth (Replit-Konten) oder Clerk Auth (deine eigenen Konten) | E-Mail, Google, GitHub, Apple, X |
| Bolt | Die integrierte Datenbank von Bolt | E-Mail, Google |
| Base44 | Der integrierte Login von Base44 | E-Mail und Passwort mit Code per E-Mail, Google, Microsoft, Facebook, Firmen-SSO |
| v0 | Meist Supabase, manchmal Clerk | E-Mail und Passwort, Codes, Magic Links, Google und andere |
| Antigravity | Meist Firebase Authentication | E-Mail und Passwort, E-Mail-Links, Google und andere |
| Claude Code, Codex, Cursor | Was immer du verlangst | Meist Supabase, Clerk, Firebase, Auth.js oder Better Auth |
Login-Dienste, die Coding-Agents nutzen
Wenn du mit einem Coding-Agent baust, verbindet er deine App mit einem Login-Dienst. Jeder verschickt andere E-Mails, und bei jedem gibt es eine Sache, die sie am häufigsten kaputt macht:
| Login-Dienst | Gesendete E-Mails | Was sie am häufigsten kaputt macht |
|---|---|---|
| Supabase Auth | Bestätigung, Magic Link oder Code, Passwort-Reset, Einladung, Adressänderung | Die Site URL und der integrierte Absender, der nur an dein Supabase-Team liefert, 2 pro Stunde, bis du eigenes SMTP einrichtest |
| Clerk | Ein Verifizierungscode (oder Link), Anmeldecodes, Codes zum Zurücksetzen des Passworts | Entwicklung und Produktion sind getrennt, mit getrennten Nutzern; Produktion braucht DNS-Einträge deiner eigenen Domain |
| Firebase Authentication | Verifizierungslink, Link zum Zurücksetzen des Passworts, Anmeldung per E-Mail-Link | Nutzer können sich vor der Verifizierung anmelden, wenn deine App das nicht prüft; Links müssen auf eine autorisierte Domain zeigen |
| Auth.js | Magic Links, über einen E-Mail-Anbieter wie Resend | Registrierung mit Passwort hat keine eingebauten E-Mails: Verifizierung und Resets sind Code, den du ergänzt |
| Better Auth | Verifizierung, Passwort-Reset sowie Magic Links oder Codes über Plugins | Es ruft eine Sendefunktion auf, die du schreibst, daher geht nichts raus, bis sie mit einem E-Mail-Anbieter verbunden ist |