Du kannst deine eigene Auth an einem Tag bauen. Das ist die Falle.
Dutzende B2B-Teams erzählten uns die gleiche Geschichte. Es beginnt als einfaches Login-Formular. Dann läuft echter Traffic darüber – und es wird langsam zur Identitäts-Infrastruktur: das Fundament, auf dem dein ganzes Produkt steht.
Es sah nach einem Feature aus. Übrig bliebt ein komplettes Identitätsmodell.
Jede selbstgebaute Auth beginnt als ein paar Zeilen Code. Die Probleme zeigen sich nach dem Launch – wenn jede kleine Entscheidung stillschweigend zum Modell wird, auf das dein gesamtes Produkt baut.
Tag eins: Vierzig Zeilen Code
E-Mail, Passwort, hashen, speichern, beim Login vergleichen. Einfach und fertig.
Tag zweihundert: Ein stummes Identitätsmodell
Wer gilt als User. Zu welcher Organisation gehört er. Welche Session ist noch vertrauenswürdig. Wie wird Zugriff wieder entzogen.
Jahr fünf: Ein Fundament, das du nicht mehr anfassen kannst
Das Login-Formular auf dem Papier zu tauschen bedeutete, die Identitätsbasis im Code neu zu schreiben.
Selbstgebaute Auth läuft prima — bis das Business sich bewegt
Jahrelang werden Leute problemlos eingeloggt. Dann ändert sich einmal das Business – und aus “ausreichend” wird über Nacht “im Weg”. Diese drei Themen trifft fast jedes skalierende Produkt.
Enterprise-Kunden wollen plötzlich SSO
Der erste große Deal steht an und der Einkauf will SSO über sein eigenes Entra oder Google Workspace. Dann SAML und OIDC, weil der nächste Kunde wieder etwas anderes nutzt. Jede Kundenidentität ist anders, und fast nichts davon kann wiederverwendet werden.
- Unterschiedliche Protokolle, Feldzuordnungen und Zertifikatrotation pro Kunde
- SSO wird nicht einmal gebaut. Für jedes neue Enterprise baust du es neu.
- Es wird langsam zu Handarbeit, die nur noch ein Engineer komplett versteht
Identität war verteilt, jetzt muss sie vereinheitlicht werden
Getrennt nach Organisation, getrennt nach Produkt – oft geerbt durch Übernahmen. „Identität vereinheitlichen“ klingt wie ein Feature – im Code heißt das: Definiere neu, was ein User und eine Organisation eigentlich sind.
- Kann eine E-Mail mehreren Organisationen gehören? Wie migrierst du alte Nutzernamen?
- Neun übernommene Produkte bedeuten neun parallel laufende Auth-Stacks
- Entferne einen Mitarbeiter aus allen Systemen auf einmal und prüfe es an einer Stelle nach
KI-Agenten und CLIs handeln im Namen eines Users
Nicht nur Menschen im Browser. Agenten, MCP-Server und Kommandozeilen handeln für irgendwelche User. Und deine Auth kann nur Leute auf Seiten einloggen.
- Für wen wird das Token ausgestellt, mit welchem Scope und für welches Publikum?
- Gewähre nur einem Tool oder für einen bestimmten Datenbereich Zugriff – und entziehe ihn später wieder
- MCP- und CLI-Zugriffe laufen über OAuth, nicht über ein Login-Formular
Die echten Kosten entstehen nicht beim Bau. Sondern beim jahrelangen Mitziehen.
Die erste Version ist günstig: Ein paar Entwickler, ein paar Wochen, und fertig. Danach fütterst du sie jedes Jahr mit Entwicklerstunden, die eigentlich ins Kernprodukt gehörten.
Die Rechnung hat sich geändert, wie du bezahlst
Du bekommst nie eine Rechnung mit dem Betreff „Authentifizierung“.
Das Wissen ruht still bei ein, zwei Leuten
Der kritische Kontext steht im Kopf von jemandem, nicht in den Dokumenten.
Wo willst du deine Engineers haben?
Kein Kunde zahlt dir einen Cent mehr, weil du deinen eigenen OAuth-Server gebaut hast.
Wenn du es nicht baust – wie wählst du dann sinnvoll aus?
Die ausgereiften Auth-Systeme bieten die Features längst: SSO, MFA, Organisationen, einheitlicher Login, Agentenzugriff. Der wirkliche Unterschied ist: Kannst du später problemlos wechseln? Baue nicht ein paar tausend Zeilen nur, um dann bei einem fremden System festzuhängen.
Standardprotokolle statt selbstgebastelter Stack
Eine Tür, durch die du wirklich gehen kannst
Abrechnung unabhängig von deiner User-Table
Deine Daten sind niemals fest eingeschlossen
Auth ist wahrscheinlich nicht dein Kerngeschäft. Behandle es auch so.
Logto ist Open Source, selbst-hostbar und als Managed Cloud nutzbar. Sign-In, MFA, SSO und RBAC funktionieren sofort mit Standard-OIDC. Die Abrechnung folgt den Tokens – und wenn du wechseln willst, steht die Tür offen.