Anmeldung in deine App einbauen: Passwörter, Magic Links, Google und Rollen

Um eine Anmeldung in deine App einzubauen, wählst du eine Methode aus, also E-Mail und Passwort, Magic Links (ein einmaliger Anmeldelink per E-Mail) oder „Mit Google anmelden“, und setzt sie mit einer bewährten Auth-Bibliothek oder einem gehosteten Anbieter um, statt alles selbst zu schreiben. Danach legst du fest, was jede Art von Nutzer darf (Rollen), und erzwingst das auf dem Server bei jeder Seite und jeder API-Anfrage. Sitzungen sollten sichere Cookies verwenden, ablaufen und beim Abmelden ordentlich beendet werden.

Dieser Leitfaden geht durch jede Wahl und die Details, die eine funktionierende Anmeldung von einer sicheren unterscheiden. Die Konzepte dahinter erklärt was Authentifizierung ist.

Zuerst entscheiden: Brauchst du überhaupt eine Anmeldung?

Eine Anmeldung bringt Aufwand und Verantwortung. Du brauchst sie, wenn:

• Nutzer private Daten haben (ihre Buchungen, Dokumente, Rechnungen)
• Nutzer Dinge ändern können, die andere sehen
• du für den Zugang Geld verlangst
• verschiedene Personen verschiedene Berechtigungen brauchen (Inhaber, Mitarbeiter, Kunde)

Für eine Marketing-Website, ein öffentliches Verzeichnis oder ein Formular, das dir nur eine E-Mail schickt, brauchst du keine. Eine Warteliste braucht keine Konten; ein E-Mail-Feld reicht.

Die vier gängigen Anmeldemethoden

Viele Apps kombinieren zwei Methoden: Anmeldung mit Google plus E-Mail-Magic-Links ist eine beliebte Kombination, die die meisten Menschen abdeckt, ohne Passwörter zu speichern.

E-Mail und Passwort

Wenn du Passwörter anbietest, sind diese Punkte nicht verhandelbar:

• Hashe Passwörter mit einem langsamen Hash-Verfahren. Die OWASP-Empfehlungen zur Passwortspeicherung nennen Argon2id, alternativ scrypt, bcrypt oder PBKDF2. Speichere Passwörter nie im Klartext oder mit einem schnellen allgemeinen Hash.
• Passwort-Zurücksetzen nutzt einen zufälligen Link, der nur einmal gilt, abläuft und an die bestätigte E-Mail-Adresse geschickt wird.
• Verrate nicht, welche E-Mails Konten haben. „Falls diese E-Mail registriert ist, haben wir einen Link zum Zurücksetzen gesendet“ ist besser als „Kein Konto gefunden“.
• Begrenze die Anzahl der Versuche bei Anmeldung und Zurücksetzen, damit Passwort-Raten gebremst wird.
• Erlaube lange Passwörter und Passwort-Manager; verzichte auf Regeln, die bestimmte Zeichenmischungen erzwingen.

Magic Links und Einmalcodes

Ein Magic Link ist ein Anmeldelink, der per E-Mail an den Nutzer geht. Ein Klick meldet ihn an. Ein Einmalcode folgt dem gleichen Prinzip, wird aber eingetippt statt angeklickt.

• Links und Codes laufen schnell ab und funktionieren nur einmal.
• Der Link sollte den Nutzer auf dem Gerät anmelden, auf dem er geklickt wurde, und das Token darf nicht in Protokollen oder Analytics-Tools landen.
• Du brauchst zuverlässigen E-Mail-Versand. Siehe wie du E-Mails aus deiner App verschickst. Teste mit Gmail und Outlook und prüfe den Spam-Ordner.

Mit Google anmelden (und andere OAuth-Anbieter)

„Mit Google anmelden“ nutzt OAuth und OpenID Connect: Google bestätigt, wer der Nutzer ist, und teilt deiner App seine E-Mail-Adresse und seinen Namen mit. Die Einrichtung erfolgt Stand September 2026 im Bereich Google Auth Platform der Google Cloud Console:

1. Lege ein Projekt an oder wähle eines aus und fülle die Seite Branding aus: Was Nutzer auf dem Zustimmungsbildschirm sehen (App-Name, Support-E-Mail, Logo).
2. Lege auf der Seite Clients einen Client vom Typ „Webanwendung“ an.
3. Trage die autorisierten JavaScript-Ursprünge und Weiterleitungs-URIs ein, also die genauen Adressen, unter denen deine App läuft und zu denen Google die Nutzer nach der Anmeldung zurückschickt.
4. Speichere Client-ID und Client-Secret in den Geheimnissen deiner App.

Laut der OAuth-Dokumentation von Google geht dabei häufig etwas schief:

• redirect_uri_mismatch: Die Weiterleitungsadresse muss exakt übereinstimmen, einschließlich http vs. https, Groß- und Kleinschreibung und eines abschließenden Schrägstrichs. Trage eine für deine Vorschau-Adresse und eine für deine Live-Domain ein.
• HTTPS ist Pflicht: Weiterleitungs-URIs müssen HTTPS verwenden, außer localhost während der Entwicklung.
• Der Parameter state sollte bei der Rückkehr geprüft werden, um vor Cross-Site-Request-Forgery zu schützen. Gute Bibliotheken erledigen das für dich.

Wenn du nur grundlegende Anmeldedaten anforderst (Name, E-Mail, Profil), sagt Google, dass eine App-Verifizierung nicht zwingend ist. Der Zugriff auf Gmail, Drive oder Kalender der Nutzer ist etwas anderes und erfordert eine Verifizierung.

Selbst bauen oder einen Anbieter nutzen?

Die ersten beiden Ansätze sind beide vernünftig. Gehostete Anbieter übernehmen mehr, bringen aber eine Abhängigkeit mit und kosten manchmal pro aktivem Nutzer; prüfe die aktuellen Preise auf deren Websites. Bibliotheken halten alles in deiner Datenbank, überlassen dir aber mehr Konfiguration. Was du auch wählst: Lass die KI diesen Weg nutzen, statt Passwort- oder Sitzungslogik selbst zu basteln.

Rollen und Berechtigungen

Die Anmeldung sagt dir, wer jemand ist. Berechtigungen legen fest, was er tun darf. Halte es zunächst einfach:

Regeln, die wichtiger sind als die Namen der Rollen:

• Prüfe auf dem Server, jedes Mal. Einen Button auf der Seite auszublenden hält niemanden davon ab, die API direkt aufzurufen.
• Begrenze auf den Besitzer. Ein Mitglied, das „Buchung 123“ abruft, soll sie nur bekommen, wenn sie ihm gehört.
• Nutzer können sich nicht selbst befördern. Ignoriere Rollenfelder, die der Browser bei Profilaktualisierungen schickt.
• Standardmäßig kein Zugriff. Neue Routen sollten eine Anmeldung verlangen, sofern du nicht bewusst etwas anderes entscheidest.

Teste mit zwei Konten: Melde dich als eines an, notiere die ID eines Datensatzes, melde dich als das andere an und versuche, ihn zu öffnen. Unsere Sicherheits-Checkliste enthält den vollständigen Test.

Sitzungssicherheit

Nach der Anmeldung merkt sich die App den Nutzer mit einer Sitzung, meist über ein Cookie. Die Leitlinien von OWASP zum Sitzungsmanagement empfehlen:

• Sitzungs-Cookies mit Secure (nur HTTPS), HttpOnly (für Seiten-Skripte nicht lesbar) und SameSite
• Eine neue Sitzungs-ID bei der Anmeldung und erneut, wenn sich Rechte ändern
• Ein Leerlauf-Timeout und eine maximale absolute Lebensdauer, serverseitig durchgesetzt
• Abmelden, das die Sitzung auf dem Server beendet, nicht nur das Cookie löscht
• Sitzungen werden ungültig, wenn ein Nutzer sein Passwort ändert

Anmelde-Token im lokalen Speicher des Browsers abzulegen ist in Tutorials verbreitet, macht sie aber für jedes Skript auf der Seite zugänglich. Sichere Cookies sind bei Web-Apps meist die bessere Standardwahl.

Ein Prompt, der das Wesentliche abdeckt

Füge dieser App Nutzerkonten hinzu. Nutzer können sich mit E-Mail und Passwort registrieren und anmelden oder mit Google. Nutze [Bibliothek oder Anbieter] statt eigenem Auth-Code. Hashe Passwörter mit Argon2id oder bcrypt. Füge ein Zurücksetzen des Passworts per E-Mail hinzu, mit einem Link, der nur einmal gilt und nach einer Stunde abläuft. Speichere Sitzungen in sicheren HttpOnly-Cookies. Schütze /dashboard und jede /api-Route, sodass nur angemeldete Nutzer sie verwenden können, und stelle sicher, dass Nutzer nur ihre eigenen Projekte sehen. Füge eine Rolle „admin“ hinzu, die alle Nutzer sehen kann; nur Admins erreichen /admin, auf dem Server geprüft.

Dann testen: registrieren, abmelden, anmelden, Passwort zurücksetzen, eine private URL im abgemeldeten Zustand aufrufen und den Datensatz eines anderen Nutzers versuchen.

Häufige Fehler bei KI-gebauter Anmeldung

• Schutz nur in der Seite. Die Seite leitet abgemeldete Nutzer um, aber die API gibt Daten an jeden zurück.
• Geheimnisse im Browser. OAuth-Client-Secrets und Admin-Schlüssel von Auth-Anbietern gehören auf den Server.
• Vorschau- und Live-URL verwechselt. Die Weiterleitungs-URI von Google oder der Link im Zurücksetzungs-E-Mail zeigt auf die Vorschau, sodass die Anmeldung nach dem Veröffentlichen bricht.
• Keine E-Mail-Bestätigung. Jeder kann sich als anyone@firma.de registrieren. Bestätige die E-Mail, bevor du etwas gewährst, das an diese Adresse gebunden ist.
• Nur der Idealfall wird getestet. Probiere falsche Passwörter, abgelaufene Links und ein zweites Konto.

Anmeldung in Mythex hinzufügen

Auf Mythex ist die Anmeldung für die Nutzer deiner App etwas, das du deiner App hinzufügst. Sie ist getrennt von deinem eigenen Mythex-Konto. Mythex bietet kein eingebautes Auth-Produkt, deshalb bringst du eine Auth-Bibliothek oder einen Anbieter und dessen Schlüssel mit:

1. Wähle einen Ansatz, zum Beispiel E-Mail und Passwort in deiner eigenen Datenbank oder das SDK eines gehosteten Anbieters.
2. Wenn du Nutzer selbst speicherst, braucht die App eine Datenbank; frag im Chat danach oder nutze /database.
3. Lege Anbieter-Schlüssel in den Projekt-Geheimnissen ab (/secrets oder Projekteinstellungen).
4. Nutze einen Prompt wie oben und teste in der Vorschau. Für Anmeldung mit Google trägst du Weiterleitungs-URIs für Vorschau und veröffentlichte Adresse ein.

Siehe Anmeldung zu deiner App hinzufügen in der Dokumentation. Wenn du ein kostenpflichtiges Produkt baust, behandelt wie du ein SaaS-MVP baust Konten und Abrechnung gemeinsam.

Fragen