Vor drei Monaten sitze ich bei einem Maschinenbauer, 180 Mitarbeitende, Standorte in Deutschland und Polen. Ihr .NET-Entwickler — einer, singular — hatte IdentityServer aufgesetzt. Warum? Weil die Geschäftsführung irgendwo gehört hatte, dass man für "professionelle Auth" ein Identity Provider braucht. Der Entwickler hatte das umgesetzt, wie es ihm erklärt worden war. Ergebnis: Eine selbst gehostete IdentityServer-Instanz, die genau eine Web-Applikation absichert, mit genau einer Benutzergruppe, ohne API-Anbindung, ohne Mobile App, ohne Pläne für irgendwas davon. Und jetzt steht die Lizenzverlängerung an: 3.500 Euro pro Jahr für Duende IdentityServer Business Edition.
Der Entwickler weiß selbst, dass es zu viel ist. Er hat mich angerufen, weil er seinem Chef das nicht allein erklären kann.
Maarten Balliauw, Engineering bei Duende Software — also dem Unternehmen, das IdentityServer kommerziell weiterentwickelt — hat diese Woche einen handwerklich sauberen Beitrag veröffentlicht. Er beschreibt ehrlich, was IdentityServer ist (ein .NET SDK zum Bauen eines eigenen Identity Providers, kein fertiges Produkt), wann man es nicht braucht (eine App, ein Benutzerpool, Social Login reicht mit AddOpenIdConnect()), und wann es seinen Platz hat: mehrere Applikationen, mehrere Clients, Machine-to-Machine-Kommunikation, On-Premises-Zwänge, Compliance-Profile wie FAPI 2.0. Der Artikel ist fair, nicht übertrieben verkäuferisch, und der Rat an den eingangs erwähnten Interessenten — "nimm einfach ASP.NET Identity mit dem Google-Provider" — ist genau richtig. Für eine .NET-erfahrene Zielgruppe ist das ein guter Orientierungsrahmen.
Was darin fehlt, ist die Perspektive, die ich täglich sehe: Was passiert, wenn ein KMU mit eingeschränkten Entwicklerkapazitäten die Entscheidung trifft, bevor sie den Artikel gelesen haben.
Wie das bei 30 bis 300 Mitarbeitenden wirklich landet
Das Kernproblem im Mittelstand ist nicht fehlendes technisches Wissen. Es ist fehlendes Kontextwissen zum richtigen Zeitpunkt.
IdentityServer ist ein SDK zum Bauen eines Identity Providers. Das klingt mächtig — weil es mächtig ist. Aber "mächtig" bedeutet: Du baust selbst. Login-UI, Benutzer-Store-Integration, Client-Registrierungen, Key-Management-Konfiguration, Deployment, Updates, Monitoring. Das ist kein Nachmittagsprojekt. Das ist eine eigene Applikation, die du langfristig betreiben musst. Maarten sagt das explizit, aber die Konsequenz unterschätzen viele.
Ich hab das Pattern so oft gesehen, dass ich es inzwischen direkt anspreche, wenn ich höre: "Wir brauchen einen zentralen Login":
Schritt 1: Jemand googelt "central authentication .NET". IdentityServer erscheint prominent.
Schritt 2: Der Entwickler baut es auf, weil es technisch funktioniert und die Docs gut sind.
Schritt 3: Zwei Jahre später: ein Entwickler ist weg, die Instanz läuft irgendwo auf einem VM-Share, niemand weiß mehr warum bestimmte Clients so konfiguriert sind, und die Lizenzverlängerung ist fällig.
Das ist kein Versagen von IdentityServer. Das ist ein Ressourcen-Mismatch.
Wann IdentityServer im Mittelstand tatsächlich Sinn ergibt:
Du hast ein .NET-Team von mindestens zwei bis drei Entwicklern, von denen mindestens einer dauerhaft für die Identity-Infrastruktur verantwortlich ist. Du hast tatsächlich mehrere Applikationen (Web, Mobile, API, Hintergrundservices), die gemeinsam authentifizieren müssen. Du hast entweder On-Premises-Zwänge durch regulatorische Anforderungen oder Datenschutz (kein SaaS erlaubt), oder du bist ein ISV, der Identity in ein Produkt einbetten will, das du an Kunden weiter distribuierst. Dann ist IdentityServer die richtige Wahl — und Duendes Lizenzmodell ist für den Gegenwert fair.
Wann du es nicht brauchst, auch wenn dein Bauchgefühl "professionell" sagt:
Wenn du eine Handvoll Web-Apps hast, die alle in deinem Azure AD oder Entra ID hängen könnten. Wenn du Social Login willst. Wenn du Single Sign-On für deine eigenen drei Applikationen brauchst. Wenn du hauptsächlich B2B-Szenarien hast, bei denen Kunden mit ihren eigenen Corporate-Identitäten kommen.
Für genau diese Szenarien gibt es Alternativen, die ein KMU nicht selbst betreiben muss:
- Microsoft Entra ID / Azure AD B2C — wenn du eh in der Microsoft-Welt bist, ist das der reibungsloseste Weg. B2C kostet bei unter 50.000 MAU effektiv nichts. Die Konfiguration ist UI-getrieben, kein Custom-Code nötig.
- Keycloak — Open Source, selbst hostbar, aber auch hier: betreiben kostet Zeit. Für On-Premises ohne .NET-Bindung die häufigste Alternative, die ich empfehle.
- Auth0 / Okta — SaaS, teuer sobald du über Freetier-Grenzen gehst, aber für externe Kundenportale mit wenig IT-Kapazität oft der pragmatischste Weg.
Die Frage ist nicht nur "welches Tool passt technisch", sondern: "Wer pflegt das in zwei Jahren, wenn derjenige, der es gebaut hat, nicht mehr da ist?"
Was ich konkret empfehle
Bevor du auch nur anfängst, IdentityServer zu evaluieren, beantworte dir diese drei Fragen:
1. Wie viele separate Applikationen (nicht Module, nicht Seiten — eigenständige deploybare Einheiten) brauchen gemeinsame Auth, jetzt oder in den nächsten 18 Monaten?
Unter drei: Fast immer gibt es eine einfachere Lösung.
Ab vier bis fünf mit heterogenen Clients: IdentityServer wird interessant.
2. Hast du On-Premises-Zwang oder Datensouveränität als hartes Kriterium?
Nein: Erst SaaS-Optionen durchrechnen. Der Betriebsaufwand für selbst gehostete Identity ist höher als er auf den ersten Blick aussieht.
Ja: Dann IdentityServer oder Keycloak, je nach Tech-Stack und Team.
3. Wer ist in 24 Monaten für dieses System verantwortlich?
Wenn du die Frage nicht beantworten kannst, bau nichts selbst, was kritische Infrastruktur ist.
Für meinen Maschinenbauer-Kunden: Die Lösung war Entra ID B2C mit drei Wochen Migrationsarbeit und null laufenden Lizenzkosten für seine Nutzerzahlen. Der Entwickler hat jetzt Zeit für die Dinge, die wirklich Wert schaffen.
Der vollständige Original-Beitrag von Maarten Balliauw: What is IdentityServer and When Do You Need it?
Pflichtlektüre, wenn du ernsthaft evaluierst — Maarten erklärt das Protokoll-Fundament und die Architektur-Szenarien deutlich tiefer, als ich es hier getan habe.
Wenn du gerade vor der Entscheidung stehst — IdentityServer, Keycloak, Entra, oder was ganz anderes — und 30 Minuten Klartext ohne Vendor-Spin helfen würden:
— Bernhard