Stell dir vor, du hast eine Software entwickelt, die in der Cloud läuft. Alles schön zentral, alles einfach. Dann kommt ein Kunde und sagt: „Wir möchten eure Lösung bei uns im Rechenzentrum betreiben, komplett isoliert vom Internet.“ Plötzlich wird aus einem vertrauten Thema – Authentifizierung – ein komplexes Geflecht aus Identitätsprovidern, SCIM-Syncs und Session-Validierung. Und das alles unter den strengen Sicherheitsrichtlinien des Kunden.
Genau mit dieser Situation beschäftigt sich der Artikel, der auf dem Blog von PropelAuth erschienen ist. Er erklärt, wie man eine On-Premises-fähige Authentifizierung aufbaut, die vollständig im Netzwerk des Kunden lebt. Der Kern der Idee: Die Auth-Logik gehört direkt neben die Anwendung, nicht in eine entfernte Cloud.
Warum klassische Auth-as-a-Service-Modelle scheitern
Wer Software verkauft, die in der Umgebung des Kunden läuft, stößt schnell an Grenzen. Übliche Authentifizierungsdienste wie Auth0, Cognito oder auch Firebase senden Login-Anfragen, Session-Validierungen und Token-Aktualisierungen an externe Server. Das ist in der Cloud kein Problem. In einem abgeschotteten Rechenzentrum sieht das anders aus: Daten dürfen das Netzwerk nicht verlassen, externe API-Aufrufe sind blockiert oder stark eingeschränkt, und der Kunde hat oft einen eigenen Identity Provider (IdP) wie Okta, Microsoft Entra oder OneLogin.
Der Kunde möchte, dass sich seine Mitarbeiter mit den gewohnten Zugangsdaten anmelden. Er möchte, dass Benutzerkonten automatisch bereitgestellt und deaktiviert werden, wenn jemand das Unternehmen verlässt. Und er möchte, dass all das ohne den Umweg über eine externe Plattform funktioniert. Genau hier brechen herkömmliche Auth-Dienste zusammen, weil sie oft zwingend eine Verbindung nach außen benötigen.
Die Lösung: Auth als Sidecar neben der Anwendung
Die Idee ist bestechend einfach: Statt die Authentifizierung in die Cloud auszulagern, setzt man sie als eigenen Prozess direkt neben die eigentliche Anwendung. Dieses „Sidecar“ übernimmt Login, Session-Verwaltung und die Anbindung an den Identity Provider des Kunden. Es läuft komplett im Kundennetzwerk, speichert Daten in einer lokalen Datenbank und kommuniziert nie nach außen.
Das erinnert an einen Türsteher, der direkt vor der Tür steht, anstatt per Videoanruf von einem entfernten Standort zugeschaltet zu sein. Der Türsteher sieht, wer kommt, kann Ausweise prüfen und entscheiden – und das alles, ohne die Daten an eine Zentrale schicken zu müssen. Genau so funktioniert das Konzept, das PropelAuth mit seinem „BYO“-Angebot (Bring Your Own Auth) umsetzt.
PropelAuth BYO ist ein selbstgehosteter Authentifizierungs-Sidecar, der in Rust geschrieben wurde. Er ist bewusst schlank gehalten: nur eine Abhängigkeit (Postgres), detailliertes JSON-Logging für Audits und SDKs für alle gängigen Programmiersprachen. Das macht ihn für Kunden einfach zu betreiben und für Entwickler einfach zu integrieren.
Der Bootstrap: Wie richtet man SSO ein, bevor es Benutzer gibt?
Ein klassisches Henne-Ei-Problem: Um sich anzumelden, braucht man eine SSO-Konfiguration. Aber um eine SSO-Konfiguration zu erstellen, muss sich ein Administrator anmelden. Der Artikel schlägt dafür einen einfachen Weg vor: einen temporären Endpunkt, der mit einem geheimen Schlüssel geschützt ist. Der Admin setzt beim ersten Start ein Passwort als Umgebungsvariable und kann damit eine Setup-Seite aufrufen. Dort werden die Verbindungsdaten zum IdP des Kunden eingegeben – zum Beispiel die OIDC-URL, die Client-ID und das Client-Secret.
Erst wenn dieser Schritt abgeschlossen ist, wird der Zugang über den SSO-Flow freigeschaltet. Das klingt banal, ist aber ein entscheidender Baustein für eine reibungslose Inbetriebnahme. Ohne dieses Bootstrap-Verfahren müsste man entweder einen initialen Admin manuell anlegen oder auf einen externen Dienst zurückgreifen – beides ist in einer restriktiven On-Premises-Umgebung unpraktisch.
Der SSO-Login: Initiieren, weiterleiten, zurückkommen
Der eigentliche Login läuft in zwei Schritten ab. Zuerst leitet die Anwendung den Benutzer zum Identity Provider weiter. Dort gibt der Benutzer seine Zugangsdaten ein und wird anschließend mit einem Autorisierungscode zurückgeschickt. Die Anwendung tauscht diesen Code gegen eine Session aus – und zwar vollständig im lokalen Netzwerk.
Das Besondere an dieser On-Premises-Architektur: Man muss sich nicht um die Zuordnung zu einer Organisation kümmern. In einer Cloud-Multi-Tenant-Umgebung muss das System wissen, welcher Kunde zu welchem IdP gehört. Im Rechenzentrum des Kunden ist das eindeutig – es gibt nur eine Organisation, nur einen IdP. Der Code wird dadurch deutlich einfacher.
Sessions: Sicher eingeloggt bleiben, ohne den IdP zu belasten
Nach dem Login entsteht eine Session. Diese erlaubt es dem Benutzer, über einen längeren Zeitraum eingeloggt zu bleiben, ohne bei jeder Anfrage den Identity Provider kontaktieren zu müssen. Die Session wird lokal gespeichert und validiert. Die Anwendung schützt damit ihre Routen: Wer keine gültige Session hat, wird zum Login weitergeleitet. Wer sich abmeldet, dessen Session wird sofort ungültig.
Die Laufzeit und die Rotation solcher Sessions lassen sich je nach Kundenwunsch konfigurieren. Manche Kunden möchten kurze Sessions für Administratoren, längere für normale Benutzer. Andere legen Wert auf eine Begrenzung auf bestimmte IP-Bereiche. All das lässt sich in dieser Sidecar-Architektur abbilden, ohne dass ein externer Dienst angezapft werden muss.
SCIM: Automatische Benutzersynchronisierung
Ein weiteres Puzzlestück ist die Bereitstellung von Benutzerkonten. In Unternehmen wird heute erwartet, dass neue Mitarbeiter automatisch Zugang erhalten und ausscheidende Mitarbeiter sofort gesperrt werden. Dafür gibt es SCIM (System for Cross-domain Identity Management). Der Identity Provider des Kunden sendet dabei Ereignisse wie „Benutzer angelegt“, „Benutzer deaktiviert“ oder „Gruppe geändert“ an die Anwendung.
PropelAuth übernimmt das Parsen dieser SCIM-Requests. Der Integrator muss lediglich einen einzigen Wildcard-Endpunkt bereitstellen, der die eingehenden Daten an den Sidecar weiterreicht. Für jede Aktion wie Anlegen oder Deaktivieren muss die Anwendung den Erhalt bestätigen. Dadurch bleibt der Datenbestand konsistent – ganz ohne Webhook-Konfiguration und ohne Synchronisation über Netzwerkgrenzen hinweg.
Der Artikel weist darauf hin, dass diese Einrichtung in nur etwa 200 Zeilen Code resultiert. Das ist bemerkenswert wenig, wenn man bedenkt, was dahintersteckt: SSO-Flows, Session-Verwaltung, SCIM-Provisioning und die Integration in das eigene Produkt. Der Grund dafür ist, dass der Sidecar die komplexen Protokolle kapselt und nur eine schlanke API nach außen bietet.
Was diese Architektur für die Praxis bedeutet
Für Software-Anbieter, die ihren Kunden eine On-Premises-Option anbieten möchten, ist dieser Ansatz eine echte Alternative. Statt ein halbes Dutzend verschiedener Authentifizierungsmethoden zu pflegen, integriert man einmalig ein System, das mit jedem OIDC-kompatiblen Identity Provider funktioniert. Ob Okta, Microsoft Entra oder ein kleineres Produkt – die Codebasis bleibt gleich.
Auch unter Compliance-Gesichtspunkten hat das Konzept Vorteile. Sämtliche Authentifizierungsdaten liegen in der Postgres-Datenbank des Kunden. Die JSON-Logs erlauben lückenlose Audits. Keine externen Abhängigkeiten, keine Datenabflüsse, keine versteckten Cloud-Aufrufe. Das schafft Vertrauen – gerade bei Kunden aus regulierten Branchen wie Finanzen, Gesundheit oder öffentlicher Verwaltung.
Natürlich gibt es auch Grenzen. Der Betrieb eines solchen Sidecars erfordert auf Kundenseite eine gewisse Infrastruktur-Kompetenz. Die Verantwortung für Updates und Sicherheit verschiebt sich teilweise in die Verantwortung des Kunden. Doch genau das ist der Preis für die vollständige Kontrolle über die eigene Datenhoheit.
Ein pragmatischer Weg in eine dezentrale Auth-Zukunft
Die zunehmende Nachfrage nach On-Premises-Lösungen zeigt, dass nicht jedes Unternehmen seine Identitätsinfrastruktur in die Cloud verlagern möchte. Der Ansatz von PropelAuth BYO ist ein Beispiel dafür, wie man Authentifizierung für diese Welt baut: nicht als Ferndienst, sondern als lokalen Prozess. Die Integration ist dank klarer SDKs und einfacher Konzepte gut machbar – für Entwickler, die sich bereits mit Auth beschäftigt haben, ist der Umstieg vertraut.
Für alle, die vor ähnlichen Anforderungen stehen, lohnt sich ein Blick auf diese Architektur. Sie zeigt, dass On-Premises-Auth kein Hexenwerk sein muss. Man muss nur bereit sein, die Auth-Logik dorthin zu bringen, wo sie hingehört: direkt an den Ort, an dem die Daten leben.
Quelle: byo.propelauth.com
