Warum du dein eigenes Authentifizierungssystem nicht bauen solltest: Lektionen aus dutzenden Kundeninterviews

Authentifizierung sieht aus wie etwas, das man mal eben selbst lösen kann. E-Mail, Passwort, hashen, beim Login vergleichen. Wie schwer kann es sein, sein eigenes Authentifizierungssystem zu bauen?

Du kannst es tun. Das ist die Falle.

Wir haben mit dutzenden Teams gesprochen, die ihre Authentifizierung selbst gebaut haben. Die meisten wandten sich aus dem gleichen Grund an uns: Sie hielt das Geschäft zurück.

Unterschiedliche Branchen, Tech-Stacks und Größen, aber das gleiche Ende. Die selbstgebauten Auth-Systeme waren zu einer Schulde geworden, die das Team mit sich herumtrug.

Das Merkwürdige: Es zeigt sich nie als Ausfall. Das System lässt Menschen einloggen und läuft gut, bis eine Geschäftsänderung alles blockiert: ein Security-Audit, der erste Enterprise-Kunde, eine Übernahme, ein Feature, das zwei Produkte verbindet.

Letzte Woche war alles „okay“. Jetzt aber hängt das nächste Roadmap-Element daran fest.

Der größte Fehler bei selbstgebauter Auth ist, sie wie ein Feature zu behandeln. Du kannst sie an Tag eins schreiben. Aber sobald echter Traffic durchläuft, verknüpft sie sich mit deinen Usern, Unternehmen und Berechtigungen.

Authentifizierung ist kein Feature. Es ist Identitätsinfrastruktur.

Hinter der Login-Seite verbirgt sich ein komplettes Identitätsmodell#

Jedes selbstgebaute Auth-System beginnt gleich. Nimm eine E-Mail und ein Passwort, hashe es, speichere es, vergleiche es beim Login. Vierzig Zeilen Code, sauber und fertig.

Das Problem beginnt nach dem Launch. Bots bombardieren den Signup-Endpunkt, also kommen Rate Limiting, CAPTCHA, Device-Fingerprinting dazu. SMS-Codes gehen eines Morgens plötzlich nicht mehr raus, also werden Retries und ein Tageslimit angebaut. Dann kommen die harten Teile: sicheres Passwort-Reset, MFA und Recovery-Flow, Sessions und Refresh-Tokens, und ein Berechtigungsmodell, das viel mehr ist als ein is_admin-Boolean.

Nichts davon ist für sich schwierig. Alles passt in einen Sprint. Aber jedes Mal beantwortest du damit eine größere Frage im Produkt.

Sammele diese Antworten, und du hast das Identitätsmodell, das dein Produkt nun stillschweigend annimmt: Wer gilt als Nutzer, kann eine Person in mehreren Organisationen sein, wie dockt das Identity-System eines Enterprise-Kunden an, und wie wird Zugriff entzogen, wenn jemand geht.

Jedes Feature danach geht davon aus, dass diese Antworten in Stein gemeißelt sind – und je länger sie existieren, desto schwerer sind sie zu ändern.

Wir haben das bei einer Firma erlebt: Ein vertikaler B2B-SaaS, zwanzig Jahre am Markt, beliefert stationäre Betreiber. Die haben vor über zehn Jahren ihre eigene Auth gebaut, mit separatem Login pro Kunde und Berechtigungsprüfungen direkt in die Business-Module geschrieben. Zur Zeit war das einleuchtend.

Zwanzig Jahre später wollten sie etwas, das klein klingt: eine einheitliche Login-Seite, E-Mail als Username. Es war kein Page-Redesign – diese Prüfungen zogen sich durch Hunderte von Modulen. Eine Login-Vereinheitlichung bedeutete, das Usermodell, das Organisationsmodell, Credential-Migration und jede Berechtigungsgrenze anzupassen. Keiner wollte das absegnen, also zog es sich jahrelang hin.

Als sie damals die Login-Seite schrieben, war es ein Feature. Was sie zurückließen, war ein ganzes Identitätsmodell.

Wenn dein Business wächst, reicht DIY-Auth meist nicht mehr aus#

Fairerweise läuft selbstgebaute Auth in der Regel jahrelang. Sie lässt Leute einloggen, erneuert Sessions, sichert den Geschäftsalltag über Jahre. Die Komplexität wächst langsam, nie auf einmal, du managst sie schrittweise und denkst, alles im Griff zu haben.

Aber dass es „reicht“, heißt oft nur: Das Business ist noch nicht gegen die Wand gelaufen. Wenn es so weit ist, liegt das Problem meist nicht in der Auth selbst, sondern am Geschäft daneben. „Reicht“ wird über Nacht zu „steht im Weg“.

Die Situationen unten tauchen bei den meisten Produkten beim Skalieren auf. Sie sehen verschieden aus, sind aber im Kern dasselbe: Das Geschäft entwickelt sich weiter, das alte Identitätsmodell hält nicht mit.

Enterprise-Kunden fordern SSO#

Das Szenario: Ein Kunde will mit seinem eigenen IdP einloggen, aber dein Auth-System kennt das Konzept „fremder Identity-Provider“ gar nicht.

Der erste echte Enterprise-Deal kommt, Beschaffung schickt Anforderungen. Erst SSO via Microsoft Entra oder Google Workspace. Dann müssen es SAML und OIDC sein, weil der nächste Kunde etwas anderes nutzt. Dann kommt SCIM, um Mitarbeiter automatisch zu (de-)provisionieren.

Jeder Kunde hat andere Setups: verschiedene Protokolle, Feldzuordnungen, Zertifikatsrotation, und jedes Mal passen die Orgs unterschiedlich zusammen.

Fast keine Arbeit davon zieht durch. Der nächste Kunde bringt einen anderen IdP und eine neue Konfiguration, vieles beginnt von vorn. SSO ist kein Feature, das du einmal baust. Jeder große Kunde bringt es erneut, und die Kosten steigen mit der Kundenzahl.

Auth ist nicht mehr „lass Nutzer dein Produkt nutzen“, sondern „verbinde dein Produkt mit dem Identity-System des Kunden“. Zwei völlig verschiedene Aufgaben.

Wir haben gesehen, wie ein Unternehmen die komplette SSO-Einrichtung von Hand machte, und nur ein einziger Engineer verstand alles. Wenn er da war, gingen Kunden live. Wenn er im Urlaub war, staute sich Onboarding und Vertrieb. Als er ging, ging das Wissen mit ihm.

Das stand nie zur Debatte, als sie sich entschieden, Auth selbst zu bauen.

Das Produkt braucht eine vereinheitlichte Identität#

Das Szenario: Deine Identitätsdaten waren anfangs zersplittert, nach Organisationen und Produkten getrennt, und mit dem Wachstum musst du sie vereinheitlichen.

Die oben beschriebene Firma stand beim Login-Redesign genau an diesem Punkt, und das trifft bei vielen Produkten zu. Wir arbeiteten mit einer Plattform, die neun Produkte hatte, alle durch Zukäufe, jedes mit eigenem Auth- und Nutzerstore.

Eine Übernahme vereinheitlicht das nicht für dich. Jedes Produkt, das du kaufst, bringt einen weiteren Auth-Stack – neun parallel zu pflegen braucht echtes Personal.

Fragen häufen sich. Ist dieselbe Person ein Nutzer in Produkt A und B – oder zwei? Wie passt dieselbe Kunden-Organisation in beide? Wie autorisiert man ein übergreifendes Feature? Wenn ein Mitarbeiter geht, wie wird Zugang zu allen neun auf einmal entzogen? Und wo werden all diese Vorgänge dokumentiert?

Keines der neun Systeme ist „kaputt“. Zusammen bilden sie eine Mauer.

„Identität vereinheitlichen“ klingt wie ein Feature. Im Code heißt es: Definiere das Fundament neu, was ein Nutzer und was eine Organisation ist. Fast jedes Feature baut auf den alten Definitionen auf – jede Änderung zieht alles darüber nach.

Im KI-Zeitalter greifen Agenten und CLIs im Namen der Nutzer zu#

Das Szenario: Es sind nicht mehr nur Menschen, die sich im Browser einloggen. Jetzt arbeiten Agenten, Command-Lines und Skripte für Nutzer – dein Auth kennt aber nur: eine Person loggt sich auf einer Seite ein.

Ein Agent muss für Nutzer interne Tools ansprechen. Ein MCP-Server exponiert geschützte Ressourcen sicher. Eine CLI braucht Zugriff auf Account-Daten ganz ohne Browser.

Alle stellen dieselben Fragen: Für welchen Nutzer gilt diese Anfrage, auf welche Ressourcen darf zugegriffen werden, an wen wird das Token ausgestellt, wie ist dessen Scope, wie wird es widerrufen, werden Nutzer oder Agent geloggt?

Das alte System hat diese Mechanismen nicht. MCP setzt auf OAuth für Autorisierung. Eine CLI geht über ein OAuth-Login – oder nutzt einen persönlichen Zugriffstoken, der jederzeit entzogen werden kann. Das alles war nie für eine Login-Seite gedacht.

Falls deine Auth für eine Person per Browser konzipiert war, musst du jetzt das Handling für Clients übernehmen, die im Namen dieser Person auftreten.

Langfristige Wartung ist der größte Kostenfaktor selbstgebauter Auth#

Keine der oben genannten Situationen ist „Auth abgestürzt“. Das System läuft weiter. Jede sieht zuerst wie eine kleine Funktion aus, aber sobald du startest, wird sie zu Produktstrategie, Datenmigration und Kundendelivery.

MFA ist das klarste Beispiel. Oberflächlich: „Können wir nach Login noch einmal verifizieren?“

Nach zwei Schritten bist du dabei: Für welche Orgs und User ist es Pflicht, können Admins es für Mitglieder erzwingen, müssen sensible Aktionen wie Zahlungsdatenänderung oder Datenexport nochmal geprüft werden, wie erzeugt und setzt man Recovery Codes zurück, kann Support das tun, und gehört die MFA eines SSO-Nutzers zu dir oder zum IdP des Kunden? MFA bedeutet, du fügst eine ganze Sicherheitsschicht hinzu.

„Ein paar Nutzer synchronisieren“? Dasselbe: Dahinter steckt eine Kette von Entscheidungen zu Onboarding, Offboarding und Cross-Org-Mitgliedschaften – alles im Glauben, dass dein User- und Org-Modell von Anfang an stimmte.

Mit jedem neuen Feature pflegst du ein Identitätsprodukt in deinem eigenen Produkt. Die erste Version ist günstig – ein paar Engineers, ein paar Wochen. Aber du fütterst es Jahr für Jahr.

Der versteckte Preis: Die Rechnung wird anders bezahlt#

Der häufigste Grund, selbst zu bauen, ist der Preis – und das ist nicht naiv.

Eine Mitgliederorganisation, die wir interviewten, hat vor fünf Jahren gerechnet. 100.000 Mitglieder, aber nur einige Tausend loggten sich regelmäßig ein. Anbieter rechneten nach Member-Zahl ab – das Angebot schoss durchs Budget, Eigenbau war günstiger. Für das Jahr war das nicht falsch.

Nach fünf Jahren hatte sich die Rechnung gewendet. Eigenes Login zu pflegen und sicher zu halten hatte bereits mehr gekostet als ein off-the-shelf Produkt.

Im ersten Jahr ist die gesparte Rechnung sichtbar, nicht aber die aufgewendete Ingenieurszeit. Nach fünf Jahren bleibt die eingesparte Rechnung gleich, aber die Entwicklungskosten wachsen zu Roadmap-Verzögerungen, Security-Schulden und ungeliebter Wartung.

Eigenbau ist also nicht „gratis“. Du bekommst nur nie eine offizielle „Authentication Subscription“-Rechnung. Du zahlst in Personenmonaten, verpassten Deadlines, Refactorings, Security-Schulden und Entwicklungszeit, die im Kernprodukt besser investiert wäre.

Einige wenige Ingenieure tragen am Ende die Last#

Der Engineer, der SSO von Hand pflegt, ist kein Einzelfall. Läuft DIY-Auth lange genug, sammelt sich das entscheidende Wissen bei ein oder zwei Leuten: welcher Kunde hat welche Konfiguration, welches Feld darf nie angetastet werden, warum wurde vergangene Migration X gemacht. Selten landet das in den Dokus. Es lebt im Kopf.

Ist die Person da, läuft die Lieferung. Ist sie weg, stockt das Enterprise-Geschäft – und du merkst, dass deine wichtigste Infrastruktur keinen offiziellen Besitzer hat, sondern nur „den, der es weiß“.

Manche Teams gehen noch weiter und bauen eine komplette Self-Service-Plattform für Kunden-SSO. Klingt professionell – bis man fragt, wie viele Kunden es nutzen. Wir sahen ein System mit 1,5 Millionen monatlichen Aktiven – für kaum ein Dutzend Kunden wurde das alles gebaut.

Du dachtest, du baust ein Feature. In Wahrheit entsteht ein internes Produkt, verteilt auf ein paar Kunden. Ist Identität dein Business, lohnt es sich. Sonst ist es die versteckte Rechnung in ihrer reinsten Form.

Wo willst du deine Engineers einsetzen?#

Nochmal zurück zum zwanzigjährigen vertical SaaS. Die Engineers sind nicht schwach. Wer zwanzig Jahre ein Branchenprodukt am Leben hält, kennt seine Kunden.

Genau da liegt das Problem: Wollen sie wirklich jeden Kunden-SSO von Hand pflegen und zwanzig Jahre Permissions durch Hunderte Module ziehen – oder an der Branchensoftware selbst tiefergehen?

Das ist kein Engineering-Perfektionismus, sondern Ressourcensteuerung. Ob du Bill Pay, vertical SaaS, ein Mitgliederportal oder Operations-Software baust: Kein Kunde zahlt auch nur einen Cent mehr, weil du einen eigenen OAuth-Server geschrieben hast.

Ein Bill-Pay-Team brachte es auf den Punkt: Ihr Eigenbau-IdP war okay, aber es ist Strategie. Möglichst wenig Auth-Code, Fokus aufs beste Bill Pay, und für den Rest die bewährteste Auth-Lösung am Markt.

Auth muss zuverlässig sein. Aber „zuverlässig“ heißt nicht „von dir selbst gebaut“. Datenbank, E-Mail-Versand und Cloud müssen auch zuverlässig sein, und reife Teams bringen nicht automatisch alles inhouse, nur weil es wichtig ist.

Für die meisten Produkte ist Auth eine Kerndependenz, kein Differenzierungsmerkmal. Solange Identität nicht das Core-Business ist, ist ein eigenes Identitätsprodukt meist kein Schutzwall – sondern ein dauerhafter Ressourcenabfluss.

Wann ist Eigenbau trotzdem okay?#

Es ist leicht, ins Extreme abzurutschen: Niemals Auth-Code schreiben. Das wäre auch falsch.

In manchen Phasen ist DIY (oder halb DIY) absolut sinnvoll: Interne Demos, frühe Prototypen, Einzelvalidierungen. Und wenn dein Geschäft spezifischste, feingranulierte Autorisierung erfordert, die die Standardplattformen wirklich nicht abbilden können, ist es sinnvoll, das inhouse zu halten – und einen externen Anbieter für Authentifizierung, Sessions, SSO, MFA und User Directory einzusetzen.

Achte nur auf die POC-Rutsche. Wir haben oft gesehen: Zwei Developer stecken 6-8 Monate in einen Prototyp zur Integration eines Fremdsystems. Die Herangehensweise ist nicht schlecht. Ihr Urteil: Die Lösung ist gut. Nur war sie nie für den Skaleneinsatz gedacht.

Und ein POC ist das Leichteste, was sich zur langfristigen Architektur verfestigt: Nach sechs Monaten ist es „die aktuelle Lösung“, nach zwei Jahren „das Legacy-System“, nach fünf Jahren „untouchable infrastructure“. Der beste Zeitpunkt, aus DIY-Auth auszusteigen, ist meist, bevor sie zur Basis wird – nicht erst danach.

Der Punkt ist: Es geht nicht darum, ob du Auth-Code geschrieben hast. Sondern ob du eine generische Identitätsinfrastruktur übernommen und langfristig im eigenen Team gehalten hast.

Baue edgefähige Aspekte selbst. Sei beim Core-Layer der Identität vorsichtig. Und baue dir nicht aus Versehen eine komplette CIAM-Plattform.

Wenn man nicht selber baut – wie wählt man eine Auth-Lösung aus?#

Wenn du dich gegen die Eigenentwicklung entscheidest, kommt als nächstes: Wessen Lösung kaufen – und nach welchen Kriterien?

Die meisten vollen Lösungen decken alle Features ab: SSO, MFA, mehrere Orgs, einheitlicher Login, Agentenzugriff. Der wesentliche Unterschied ist oft nicht die Featureliste.

Wichtiger, weil weniger offensichtlich, sind folgende Punkte. Sie laufen auf eins hinaus: Verlasse das kleine DIY-System nicht nur, um dich im nächsten nicht mehr raushacken zu können.

• Bleibe bei Standardprotokollen, nicht bei erfundenen Stacks eines Anbieters. OIDC, OAuth und RS256-signierte JWTs kennt man. Claims liest du direkt aus normalen Tokens, kein vendor-spezifisches API nötig.
• Halte dir eine echte Ausstiegstür offen. Ist die Lösung Open Source und selbst hostbar, kannst du jederzeit wechseln. (Selbst-Hosting ist natürlich ein eigener Kostenpunkt auf Dauer.)
• Verknüpfe die Rechnung nicht mit deiner User-Tabelle. Abrechnung nach registrierten Nutzern oder monatlichen Aktiven folgt einer Tabelle, die nur wächst – voll mit Abgemeldeten. Im großen Stil wird das zur „Wachstumssteuer“. Genau das verschob oben im Mitglieder-Org die Entscheidung zur Eigenentwicklung.
• Deine Daten bleiben portabel. Du kannst Nutzer-Daten jederzeit exportieren. Und das riskante Speichern sensibler Daten lagert man besser aus, als selbst Datenschutz-Risiken zu tragen, die nicht zum Kerngeschäft gehören.

Transparenz: Logto ist das Auth-Produkt, das wir genau nach diesen vier Punkten entwickelt haben. Open Source, selbst hostbar, und als managed Cloud erhältlich: Cloud nutzt du ohne Wartungsaufwand, Open Source mit voller Kontrolle, und falls du wechseln willst, bleibt die Tür offen.

Sign-in, MFA, SSO und RBAC funktionieren sofort nach OIDC-Standard, Billing geht nach Tokens – du zahlst, was du nutzt.

Es gibt weitere reife Lösungen – Auth ist kein Fall mit nur einer richtigen Antwort. Wenn du gerade auswählst: Ich habe einen eigenen Artikel über die Wahl des richtigen Identity-Providers geschrieben.

Fazit: Verwechsele eine Identitätsplattform nicht mit einem normalen Feature#

Eigenbau-Auth ist am ersten Tag oft logisch. Der Haken: Später wächst sie zur Infrastruktur.

Jeder Entwicklungsschritt im Business holt es wieder hoch: Enterprise will SSO, Security will MFA, das Produkt will vereinten Login, mehrere Produkte müssen verbunden werden, KI-Agenten benötigen Nutzerressourcen. Hinter jedem Mini-Feature steckt eine Kette von Policy-Entscheidungen – und deren Zahllast frisst mit der Zeit Engineering-Kapazitäten, die ins Core-Produkt gehören.

Die Rechnung kommt nicht am Tag eins. Sie taucht meist erst nach Jahren auf. Dann sieht man: Die damalige Login-Seite war schon Identitätsinfrastruktur, die das ganze Produktleben durchzieht.

Auth ist vermutlich nicht dein Kerngeschäft. Je eher du das erkennst, desto eher kannst du Zeit, Energie und Ressourcen aufs eigentliche Produkt lenken.

FAQ#

Sollte man niemals sein eigenes Authentifizierungssystem bauen?#

Nein. Frühe Demos, interne Tools, Einzelvalidierungen oder hochgradig feingranulierte Autorisierung, die Standardlösungen wirklich nicht abbilden können, können passen. Was zu vermeiden ist: Unbemerkt langfristige, generische Identitätsinfrastruktur zu übernehmen und im Business-Team zu verankern.

Was ist der Unterschied zwischen Authentifizierung und Autorisierung?#

Authentifizierung beantwortet „Wer bist du?“. Autorisierung sagt „Was darfst du tun?“. In einer echten SaaS sind beides eng verwoben: Nutzer, Orgs, Rollen, Rechte, Sessions, Token-Claims, Audit-Logs – alles ist verknüpft. Wer ein Auth-System ersetzt, muss weiter schauen als nur auf die Login-Seite.

Warum wird Enterprise-SSO bei eigener Auth so kompliziert?#

Weil „Plug dein Produkt ins Identitätsystem des Kunden“ bedeutet: Verschiedene Kunden nutzen unterschiedliche IdPs, Protokolle, Claims, Zertifikate und Orgmappings. Der erste funktioniert, die nächsten sind kein Copy-Paste, sondern Handarbeit, die oft nur noch einer durchblickt.

Wir betreiben unsere eigene Auth seit Jahren. Können wir überhaupt noch migrieren?#

Ja, aber meist nicht mit Big Bang. Migriere schichtweise: Neue Sign-Ups, Logins und Enterprise-SSO zuerst auf die Identitätsplattform leiten, bestehende User beim nächsten Login migrieren. Rückrolloptionen und Audit-Logs immer mitführen – damit Migration nie irreversibel ist.