Authentifizierung & Nutzerverwaltung
fx-auth ist der Authentifizierungs-Server, den Sie einmal aufsetzen und in jeder Anwendung wiederverwenden: zehn Anmeldewege, ein signiertes Token, ein Rechtemodell — und Ihre Nutzer:innen bleiben, wo sie heute schon sind.
Ausgangslage
Und damit ihre eigene Nutzertabelle, ihre eigenen Passwortregeln — und ihre eigene Lücke.
Login, Registrierung, Passwort-Reset, E-Mail-Versand, 2FA: in jedem Projekt neu implementiert, jedes Mal ein wenig anders — und jedes Mal neu zu prüfen. Ihr Team pflegt Anmeldeformulare statt Ihres Produkts.
Beschäftigte im Active Directory, Kundschaft in der Produktdatenbank, Partnerfirmen mit Google-Konto, Maschinen mit hartcodierten Tokens. Niemand kann verlässlich sagen, wer heute auf was Zugriff hat.
Zwei-Faktor-Pflicht, Passkeys, „Anmelden mit Microsoft", ein Rechtemodell, das ein Audit akzeptiert: genau die Dinge, die am Ende verlangt werden — und die im Nachhinein teuer sind.
Die Folge: das Sicherheitsniveau ist je Anwendung unterschiedlich, es gibt keinen gemeinsamen Rechte-Überblick, und ein neues Produkt startet nicht mit Ihrer Fachlogik, sondern mit dem Login.
Die Lösung im Überblick
USP · Viele Wege, ein Ergebnis
Vom Passwort über den Fingerabdruck bis zur NFC-Karte an der Maschine. Jede Anmeldung endet im gleichen Format, das Ihre Anwendungen bereits verstehen.
| Passwort / Benutzername | pwd |
| TOTP-App als 2. Faktor | pwd + totp |
| E-Mail-Code als 2. Faktor | pwd + otp |
| Passkey als 2. Faktor | pwd + hwk |
| Passkey passwortlos | hwk |
| OpenID Connect (Fremd-IdP) | oidc |
| Zertifikat per QR-Code | securecloud |
| Einmal-Login / QR aufs Gerät | onetime |
| Login-Token (NFC-Tag) | login_token |
| Service-Token (Server zu Server) | psk |
amr). Eine kritische Aktion darf so
Passkey verlangen, während der Rest der App mit Passwort auskommt.HttpOnly-Cookies; nur native Apps bekommen das Token im Body — und
müssen das ausdrücklich anfordern. Der sichere Fall ist der Standardfall.USP · Passwortlos
Passkeys (FIDO2/WebAuthn) sind der einzige Faktor, der Phishing strukturell ausschließt: der Schlüssel verlässt das Gerät nie und ist an Ihre Domain gebunden.
Nach dem Passwort folgt die Bestätigung per Fingerabdruck, Gesicht oder Hardware-Key. Ersetzt die TOTP-App, ohne dass jemand Codes abtippt.
Mit auffindbaren Schlüsseln braucht es nicht einmal einen Benutzernamen: ein Klick, eine Biometrie-Abfrage, angemeldet. Das Konto dahinter löst der Server aus dem Schlüssel selbst auf.
Pro Deployment schaltbar: aus, nur zweiter Faktor, nur
passwortlos oder beides. Sie können also mit 2FA anfangen und später
passwortlos freischalten.
Der Teil, der sonst fehlt: in Desktop- und Mobile-Apps verweigert der Browser-Standard den Dienst. Unser Tauri-Plugin brückt auf die nativen Schnittstellen von iOS, macOS und Android.
Der Challenge-Zustand liegt nicht im Server-Speicher, sondern im Backend — der Auth-Server bleibt damit zustandslos und beliebig replizierbar. Ihre Schlüssel verwalten Nutzer:innen selbst: anlegen, auflisten, löschen.
Zwei-Faktor-Authentifizierung
Die meisten MFA-Einführungen scheitern nicht an der Technik, sondern am ersten verlorenen Telefon.
Einrichtung über QR-Code, 30-Sekunden-Codes, kompatibel mit jeder Authenticator-App. Nutzer:innen richten es selbst im Profil ein.
Sechsstelliger Code per Mail für alle, die keine App installieren wollen — oder als vollständig passwortloser Anmeldeweg.
Telefon weg? Man lässt sich aus der laufenden Anmeldung heraus einen Code per Mail schicken und kommt hinein — ohne Ticket, ohne Admin, ohne abgeschaltete Sicherheit.
TOTP-Schlüssel liegen AES-256-GCM-verschlüsselt in der Datenbank; der Schlüssel dafür wird per Argon2 aus Ihrem Deployment-Geheimnis abgeleitet. Ein Datenbank-Dump allein nützt niemandem.
Und der unangenehme Fall ist mitgedacht: Wer heute MFA aktiviert, entwertet damit automatisch alle eigenen Sitzungen, die noch ohne zweiten Faktor entstanden sind — geprüft bei jedem Refresh, nicht nur beim Login. Challenges laufen nach 90 Sekunden ab und erlauben fünf Versuche.
USP · Offene Plugin-Architektur
Ein zentrales Login heißt normalerweise: alle Konten migrieren. Bei fx-auth heißt es: ein Plugin schreiben.
Bestehende Kundendatenbank, ein gewachsenes ERP, eine interne API, ein Branchen-Dienst: alles, was „ist dieses Passwort richtig?" beantworten kann, lässt sich als Anmeldequelle einbinden — ohne den Rest der Plattform anzufassen.
Berechtigungen & Rollen
Ein einziges Modell — im Server, in den Clients, in Ihren eigenen Diensten. Kein „im Frontend ausgeblendet, im Backend erlaubt".
# Konfiguration: control | target | access_type "animals.read" | "<user>.betriebe" | x # ausführen "animals.*" | "*.clients.acme" | xg # + delegieren # Rolle bündelt Rechte, Ziel und Zugriffsart [[permission_info.permission_groups]] key = "herden-manager" target = "*.betriebe" access_type = "xg" controls = ["animals.read", "animals.write"] // Im Code — Namen aus der Config generiert checker.has_permission( permissions::animals.read, target!({user}.{betrieb}.betriebe), AccessType::Execute, &ctx, ).await?
Integration in Ihre Dienste
Ein Auth-Server, den jeder Request kontaktieren muss, ist ein Flaschenhals und ein Ausfallrisiko. Hier prüft jeder Dienst selbst.
Fertige Extraktoren: „Anmeldung erforderlich", „Anmeldung optional", ein Rechte-Prüfer, und ein Client, der im Namen der angemeldeten Person weiterfragt. Drei Zeilen bis zur geschützten Route.
Derselbe Prüfer als natives Modul, vorgebaut für Linux, macOS und Windows (x64 + arm64). Kein zweiter, abweichender Prüfpfad in JavaScript.
Die Tokens sind Standard-JWTs, der Prüfschlüssel liegt unter der Standard-URL. Python, Java, Go, PHP: jede JWT-Bibliothek genügt — es gibt kein Lock-in auf unsere Clients.
USP · Fertig statt fast fertig
Login, Registrierung, Passwort-Reset, Zwei-Faktor-Einrichtung, Profil, Nutzerverwaltung: fertig gebaut, übersetzt und getestet. Sie schreiben davon nichts.
Ein Custom Element mit Shadow DOM — funktioniert in Vue, React oder reinem HTML, ohne Ihr Styling zu berühren.
Alternativ die klassische Variante: Ihre App leitet weiter, man kommt angemeldet zurück.
npm-Paket mit generierten Typen aus den Server-Modellen. Falsche Feldnamen fallen beim Bauen auf.
Persistente Sitzungen und native Passkeys für Desktop- und Mobile-Apps aus derselben Codebasis.
<!-- Vollständiges Login in einer Zeile --> <fx-auth api-base="/api/v1" language="de"></fx-auth> // Reagieren, wenn jemand drin ist el.addEventListener('fx-login', () => router.push('/'))
Föderation
fx-auth kann fremde Konten akzeptieren — und Ihr Konto-System für Fremde öffnen. Das ist der Unterschied zwischen „wir haben ein Login" und „wir sind eine Plattform".
Google, Microsoft Entra/Azure AD, Keycloak oder jeder andere OpenID-Provider. Konfiguration ist eine Handvoll Zeilen; die Provider-Details holt der Server beim Start selbst ab. Aus den Angaben des Providers werden Ihre Profilfelder gefüllt — welches Feld woher kommt, bestimmen Sie.
Fremde Anwendungen — Partner-Portale, Kunden-Integrationen, Ihre eigenen Zusatzprodukte — holen sich Tokens bei Ihnen. Standard-Verfahren (Authorization Code mit PKCE), Verwaltung der Anwendungen in der UI, und pro Freigabe-Umfang genau die Nutzerdaten, die freigegeben wurden.
Ein Detail, das den Unterschied macht: Refresh-Tokens werden bei jeder Nutzung ersetzt. Taucht ein bereits verbrauchtes Token wieder auf, ist das ein Diebstahl-Signal — und der Server entzieht diesem Konto bei dieser Anwendung sofort alle Tokens. Geheimnisse liegen ausschließlich als Hash, das Client-Secret wird genau einmal angezeigt.
USP · Sicherheit
Die Angriffe auf ein Login sind bekannt. Jede Antwort darauf ist hier eingebaut, nicht optional.
Falsches Passwort, unbekanntes Konto, kaputtes Backend: nach außen dieselbe Antwort. „Passwort vergessen" bestätigt jede Adresse — auch die, die es nicht gibt. Aus dem Verhalten lässt sich keine Nutzerliste ableiten.
Passwörter und Einmal-Links liegen Argon2-gehasht, Refresh- und Anwendungs-Geheimnisse als Hash, TOTP-Schlüssel verschlüsselt. Was Sie in der Datenbank sehen, hilft einem Angreifer nicht weiter.
Ein Link zum Passwort-Zurücksetzen lässt sich nicht als E-Mail-Bestätigung einlösen und umgekehrt. Jeder Einmal-Link gilt für genau einen Zweck, einmal, und begrenzte Zeit.
Anmeldung, Zwei-Faktor-Codes und Registrierung sind einzeln begrenzt (Vorgabe: fünf Anmeldeversuche in 15 Minuten). Konten lassen sich sperren; gesperrte Konten kommen über keinen Weg herein.
Ohne ausdrückliche Anforderung liefert der Server nie ein Token im
Antworttext, sondern nur HttpOnly-Cookies — auch bei einem
Client, der den Header vergisst. Fehlkonfiguration führt zur sicheren Variante.
Jeder Config-Wert darf auf eine Umgebungsvariable verweisen, also aus Vault, Secrets-Manager oder systemd kommen. Signaturschlüssel werden beim ersten Start selbst erzeugt.
Betrieb im Alltag
Nicht nur Anmelden — auch alles danach: einladen, sperren, zurücksetzen, nachvollziehen.
Suchen über alle Backends, Details einsehen, Profil bearbeiten, sperren und entsperren, Passwörter zurücksetzen — jede Aktion an ein eigenes Recht gebunden, nicht an „ist Admin".
Konten vorab anlegen und per Mail einladen: die eingeladene Person bestätigt ihre Daten, setzt ihr Passwort und ist verifiziert. Für Umgebungen, in denen sich niemand selbst anmeldet.
Gruppen anlegen, Mitglieder einladen, annehmen, ablehnen, verlassen. Wer die Gruppe besitzt, verwaltet die eigenen Leute selbst — ohne Zugriff auf den Rest des Systems.
Der Support sieht die Anwendung mit den Augen der betroffenen Person — an ein eigenes Recht gebunden, und das Token trägt sichtbar mit, wer hier wen ansieht. Kein „ich habe mal eben ein Passwort geändert".
Welche Felder ein Konto hat, welche Pflicht sind, welche im Token landen: in der Konfiguration beschrieben. Ein neues Feld ist eine Zeile, kein Datenbank-Schema und kein Release.
Dienste bekommen ein Token mit fest umrissenen Rechten, definiert in der Konfiguration und in keiner Datenbank. Kein Sammel-Admin-Konto für Cronjobs.
Deployment
Kein Java-Application-Server, kein Cluster aus Hilfsdiensten, keine externe Session-Datenbank.
Datenbank-Migrationen laufen beim Start, die Signaturschlüssel werden beim ersten Start erzeugt. Der erste Admin-Zugang wird über die E-Mail-Adresse in der Konfiguration bestimmt.
Vollständige Anleitung zu jedem Anmeldeweg, jedem Backend, den Clients, den Rechten und dem Deployment — automatisch aus dem Quellcode gebaut und bei jeder Änderung neu veröffentlicht.
Substanz
Kein Prototyp, den man noch fertig bauen muss.
Dieselbe Rechte-Engine im Server, in den Clients und in Ihren eigenen Diensten. Was das Frontend ausgraut, verweigert das Backend — weil es dieselbe Regel auswertet.
Verzeichnisdienst, Altsystem, Fremd-Provider oder eigenes Plugin: die Identitätshoheit wandert nicht in ein Produkt, das Sie später nicht mehr verlassen können.
Selbst gehostet, kein Nutzerpreis, kein Anmeldungs-Kontingent, keine Daten bei Dritten. Sie bekommen den Quellcode und können ihn weiterentwickeln — mit uns oder ohne uns.
Anmeldung ist die Stelle, an der Ihre Nutzer:innen Ihnen zum ersten Mal vertrauen. Lassen Sie uns darüber sprechen, wie viele Logins Sie heute pflegen — und wie schnell daraus eines wird.