Kaum eine Entscheidung wird in neuen Projekten so schnell getroffen und so lange bereut wie die zur Authentifizierung. Ein Login-Formular gegen eine Nutzertabelle schreibt man an einem Nachmittag. Alles, was danach kommt, ist der eigentliche Aufwand — und den sieht man am ersten Nachmittag nicht.
Ich habe beides gemacht: eigenen Login-Code in kleinen Projekten und fertige Dienste in größeren. Die Antwort ist nicht “immer kaufen”, auch wenn das oft behauptet wird. Sie hängt daran, wie viel von der Liste unten du tatsächlich brauchst.
Was “Login” wirklich alles heißt
Der Teil, den man sich vorstellt, ist Registrierung, Login, Logout. Der Teil, der die Zeit frisst, ist der Rest:
Passwort vergessen mit zeitlich begrenzten, einmalig nutzbaren Tokens. E-Mail-Verifizierung. E-Mail-Adresse ändern — mit Bestätigung an beide Adressen, sonst hast du eine Kontoübernahme eingebaut. Sitzungsverwaltung inklusive der Möglichkeit, alle anderen Geräte abzumelden. Sperren nach zu vielen Fehlversuchen, ohne dass ein Angreifer damit fremde Konten aussperren kann. Zwei-Faktor-Authentifizierung samt Wiederherstellungscodes. Anmeldung über Drittanbieter und die Frage, was passiert, wenn dieselbe E-Mail-Adresse auf zwei Wegen ankommt. Einladungen in Teams, Rollen, Kontowechsel. Und schließlich Löschung und Export der Daten, weil Nutzer das verlangen dürfen.
Diese Liste ist keine Theorie — es ist die Reihenfolge, in der die Anforderungen in echten Projekten auftauchen, meistens einzeln und immer dann, wenn gerade etwas anderes wichtig wäre.
Wann eigener Code völlig in Ordnung ist
Selbst bauen ist eine gute Entscheidung, wenn dein Bedarf klein und dein Kontext einfach ist: ein einzelner Nutzerkreis, E-Mail und Passwort, keine Teams, keine Fremdanbieter-Anmeldung, kein Bedarf an Einmalanmeldung für Firmenkunden.
Was dabei nicht verhandelbar ist: Passwörter werden mit einem für diesen Zweck gedachten, absichtlich langsamen Verfahren gespeichert — Argon2 oder bcrypt, nie ein normaler Hash-Algorithmus, nie ein selbst ausgedachtes Verfahren. Sitzungs-Tokens werden kryptografisch zufällig erzeugt und serverseitig widerrufbar gehalten. Cookies sind httpOnly, Secure und mit SameSite gesetzt. Fehlermeldungen verraten nicht, ob eine E-Mail-Adresse existiert. Und Login- sowie Passwort-vergessen-Endpunkte haben eine Ratenbegrenzung, sonst genügt eine Liste geleakter Zugangsdaten, um deine Nutzerkonten durchzuprobieren.
Was du dagegen wirklich nicht selbst bauen solltest, ist Kryptografie. Nimm die etablierten Bibliotheken deiner Plattform, und wenn du dich für Token-basierte Sitzungen entscheidest, nimm eine ausgereifte Bibliothek statt eigener Signaturlogik.
Ein Hinweis zu selbstgebauten JSON-Web-Tokens: Sie wirken elegant, weil man ohne Datenbankabfrage prüfen kann, wer jemand ist. Der Preis ist, dass du eine Sitzung nicht ohne Weiteres beenden kannst — ein einmal ausgestelltes Token gilt bis zum Ablauf. Wer daraufhin eine Sperrliste einführt, hat die Datenbankabfrage wieder und den Komplexitätsgewinn verloren. Für klassische Webanwendungen sind serverseitige Sitzungen fast immer die einfachere und sicherere Wahl.
Wann ein Dienst die klar bessere Entscheidung ist
Drei Signale sprechen ziemlich eindeutig für einen fertigen Anbieter oder eine ausgereifte Bibliothek statt Eigenbau.
Du verkaufst an Firmen. Sobald Geschäftskunden nach Einmalanmeldung über ihren Identitätsanbieter fragen, nach SCIM für automatische Nutzerbereitstellung oder nach Audit-Protokollen, wird der Eigenbau zu einem eigenen Produkt. Das ist der Punkt, an dem selbst hartgesottene Selbstbauer wechseln.
Du brauchst viele Anmeldewege. Jeder zusätzliche Drittanbieter ist nicht nur eine Integration, sondern ein neuer Satz Randfälle bei der Kontoverknüpfung. Wenn drei oder mehr Wege absehbar sind, ist das gekaufte Zusammenführen von Identitäten die Zeit wert.
Du hast niemanden, der es pflegt. Authentifizierungscode ist nichts, das man einmal schreibt und liegen lässt. Wenn niemand im Projekt regelmäßig Sicherheitsmeldungen verfolgt und nachzieht, ist ein Dienst die ehrlichere Wahl als eigener Code, der langsam veraltet.
Der Preis, den du dafür zahlst, ist real: laufende Kosten, die typischerweise mit der Nutzerzahl wachsen, eine Abhängigkeit, deren Ausfall dein gesamtes Produkt lahmlegt, und mögliche Fragen zum Speicherort der Daten, wenn deine Kunden europäische Datenhaltung erwarten. Prüf das vor der Entscheidung, nicht danach.
Und schau dir das Preismodell genau an, bevor du dich bindest. Bei manchen Anbietern kostet ausgerechnet das, was Firmenkunden verlangen — Einmalanmeldung, Rollenverwaltung, Protokolle — den Sprung in einen deutlich teureren Tarif. Das ist nicht per se unfair, aber es sollte keine Überraschung sein, wenn der erste größere Kunde unterschreibt und du feststellst, dass deine Marge gerade um einen dreistelligen Monatsbetrag geschrumpft ist. Rechne einmal durch, was der Dienst bei der Nutzerzahl kostet, die du in zwei Jahren erreichen willst.
Zweiter Punkt, den man vorher klären sollte: Kommst du an deine Nutzerdaten heran, inklusive der Passwort-Hashes? Manche Anbieter geben sie auf Anfrage heraus, andere nicht — und ohne sie bedeutet ein Wechsel, dass sämtliche Nutzer ihr Passwort zurücksetzen müssen. Das ist machbar, kostet aber garantiert einen Teil der Nutzerbasis.
Der Mittelweg, den viele übersehen
Zwischen “alles selbst” und “alles beim Anbieter” liegt die Option, die in der Praxis oft am besten passt: eine etablierte Authentifizierungs-Bibliothek in der eigenen Anwendung, mit den Nutzerdaten in der eigenen Datenbank.
Du bekommst geprüfte Implementierungen für Sitzungen, Passwort-Zurücksetzen und Drittanbieter-Anmeldung, hast aber keine Fremdabhängigkeit im Betrieb und keine nutzungsabhängigen Kosten. Für die meisten SaaS-Produkte kleinerer Größe ist das der beste Kompromiss — und der Weg zu einem Dienst bleibt später offen, weil die Nutzertabelle bei dir liegt.
Denk beim Bauen schon an den Ausstieg
Egal wie du dich entscheidest: Die Nutzeridentität ist die am tiefsten verwobene Komponente deiner Anwendung. Fast jede Tabelle verweist irgendwann auf sie.
Deshalb der einzige Rat, der in beide Richtungen funktioniert: Halte eine eigene Nutzertabelle mit deiner eigenen internen Kennung, auch wenn ein externer Dienst die Anmeldung übernimmt. Die externe Kennung ist dann nur ein Feld darin, nicht der Schlüssel, an dem dein halbes Datenmodell hängt. Und kapsle den Zugriff auf die Identität hinter einer schmalen Stelle in deinem Code, statt Anbieter-Aufrufe über die ganze Anwendung zu verteilen.
Mit diesen zwei Vorkehrungen ist ein späterer Wechsel — in beide Richtungen — eine Aufgabe von Tagen statt von Wochen. Ohne sie ist er ein Migrationsprojekt, das erfahrungsgemäß nie stattfindet, egal wie sehr die aktuelle Lösung stört.
Wenn du bei einer konkreten Abwägung feststeckst: Im Discord der Community sitzen genug Leute, die genau diesen Wechsel schon hinter sich haben.