RDataCore als Headless-Backend: Benutzerregistrierung, Authentifizierung & mehr

Was wäre, wenn deine Master-Data-Management-Plattform gleichzeitig als Backend für dein Kundenportal, internes Tool oder deine Mobile App dienen könnte? Mit RDataCores Headless-Architektur ist das möglich.

Traditionell erfordert der Aufbau einer Webanwendung mit Benutzerkonten die Einrichtung eines separaten Authentifizierungsdienstes, einer Benutzerdatenbank, Session-Management und API-Endpunkten — oft mit mehreren Drittanbieterdiensten und erheblicher Infrastruktur. RDataCore verfolgt einen anderen Ansatz: Indem Benutzer als ein weiterer Entitätstyp behandelt werden und die Workflow-Engine für die Authentifizierung genutzt wird, erhältst du ein vollständiges Headless-Backend ohne zusätzliche Dienste.

In diesem Guide gehen wir das Gesamtbild durch: wie du Benutzer als Entitäten mit dem neuen Password-Feldtyp modellierst, wie Registrierungs- und Login-Workflows funktionieren, wie Entity JWTs deine API-Endpunkte schützen und warum RDataCores Position als Master-Data-Management-Plattform es einzigartig leistungsfähig als Headless-Backend macht. Ob du ein Kunden-Self-Service-Portal, ein internes Operations-Tool, einen E-Commerce-Storefront oder ein IoT-Dashboard baust — das Muster ist dasselbe.

Ein Headless-Backend ist ein serverseitiges System, das seine Funktionalität ausschließlich über APIs bereitstellt, ohne eine eigene Benutzeroberfläche zu bieten. Der "Head" — also das Frontend — ist vollständig vom Backend entkoppelt. Das ermöglicht es dir, beliebig viele Frontends (Webanwendungen, Mobile Apps, CLI-Tools, IoT-Dashboards) zu bauen, die alle über eine konsistente API mit demselben Backend kommunizieren.

Der Headless-Ansatz ist zum Standard für moderne Anwendungsentwicklung geworden, weil er bietet:

• Frontend-Freiheit — Verwende React, Vue, Next.js, Flutter, React Native oder jedes Framework deiner Wahl
• Mehrere Clients — Bediene ein Webportal, eine Mobile App und ein internes Tool vom selben Backend
• Unabhängiges Deployment — Aktualisiere dein Frontend ohne das Backend zu berühren und umgekehrt
• API-First-Design — Jede Fähigkeit ist programmatisch zugänglich, was Automatisierung und Integration ermöglicht

RDataCore ist von Natur aus headless. Seine Workflow-Engine, Entity-Speicherung und Public API wurden von Grund auf für den Konsum durch externe Clients konzipiert. Die Hinzufügung von Benutzerauthentifizierung zu dieser Architektur bedeutet, dass jedes Frontend Benutzer registrieren, authentifizieren und geschützte Daten bereitstellen kann — alles über RDataCores bestehende Workflow-Endpunkte.

Die Grundlage der Headless-Authentifizierung in RDataCore ist eine User-Entity-Definition. Anstelle einer fest codierten Benutzertabelle definierst du dein Benutzerschema als reguläre Entity-Definition — was dir volle Flexibilität über die Felder deiner Benutzer gibt.

Eine typische User-Entity-Definition enthält:

• first_name (String) — Der Vorname des Benutzers
• last_name (String) — Der Nachname des Benutzers
• email (String, eindeutig, erforderlich, indiziert) — Der Login-Identifikator
• opt_in (Boolean) — Marketing-Einwilligung oder AGB-Akzeptanz
• password (Password) — Das Passwort des Benutzers, automatisch gehasht

Der Password-Feldtyp ist der Schlüssel hier. Wenn du ein Password-Feld zu einer Entity-Definition hinzufügst, macht RDataCore automatisch:

1. Hashing beim Schreiben — Passwörter werden mit Argon2id (dem aktuellen Goldstandard für Passwort-Hashing) vor der Speicherung gehasht. Das Klartext-Passwort berührt nie die Datenbank.
2. Schwärzung beim Lesen — Wenn du eine User-Entität über die API abfragst, gibt das Passwortfeld immer null zurück. Der Hash wird nie offengelegt.
3. Unterstützung der Verifizierung — Der Authenticate-Workflow-Transform kann intern ein übermitteltes Passwort gegen den gespeicherten Hash verifizieren.

Das bedeutet, du konfigurierst dein Benutzerschema über dieselbe Admin-UI, die du für jede andere Entity-Definition verwendest. Möchtest du ein role-Feld hinzufügen? Eine avatar_url? Ein subscription_tier? Füge einfach Felder zu deiner Definition hinzu. Dein Benutzermodell ist genauso flexibel wie jede andere Entität in RDataCore.

Da die E-Mail als eindeutig und indiziert markiert ist, stellt RDataCore sicher, dass sich keine zwei Benutzer mit derselben E-Mail-Adresse registrieren können, und Abfragen nach E-Mail sind schnell — genau das, was ein Authentifizierungssystem braucht.

Die Benutzerregistrierung in einem Headless-RDataCore-Setup funktioniert über einen Workflow-Endpunkt. Dein Frontend sendet einen POST-Request mit den Benutzerdaten, und RDataCores Workflow-Engine kümmert sich um alles: Validierung, Entity-Erstellung, Passwort-Hashing und Antwort.

So funktioniert der Ablauf Schritt für Schritt:

Eine Registrierungs-Workflow-Definition sieht in RDataCores DSL so aus:

• FROM: api-Quelle mit JSON-Format, Mapping von email, password, first_name, last_name
• TRANSFORM: create_entity mit Entity-Typ user
• TO: api-Ausgabe mit JSON-Format, Rückgabe der Entity-UUID

Das Schöne an diesem Ansatz ist, dass deine Registrierungslogik vollständig konfigurierbar ist. Möchtest du E-Mail-Validierung hinzufügen? Füge ein Constraint zum E-Mail-Feld hinzu. Möchtest du eine Mindestlänge für Passwörter verlangen? Setze min_length: 8 auf das Password-Feld. Möchtest du automatisch eine Standardrolle zuweisen? Setze einen Standardwert auf ein role-Feld. Keine Code-Änderungen nötig.

Sobald Benutzer registriert sind, müssen sie sich anmelden. RDataCore handhabt dies durch den Authenticate-Transform — einen dedizierten Workflow-Schritt, der Anmeldedaten verifiziert und JWT-Tokens ausstellt.

Der Login-Ablauf funktioniert so:

Das Frontend speichert dann dieses Token (im Speicher, localStorage oder einem sicheren Cookie) und fügt es als Bearer-Token im Authorization-Header nachfolgender API-Anfragen ein.

Der Authenticate-Transform ist hochgradig konfigurierbar:

• entity_type — Welcher Entitätstyp deine Benutzerdatensätze enthält (z.B. "user")
• identifier_field — Welches Feld der Login-Identifikator abgeglichen wird (z.B. "email", könnte aber auch "username" sein)
• password_field — Welches Feld den Passwort-Hash enthält (z.B. "password")
• extra_claims — Zusätzliche Entitätsfelder, die im JWT enthalten sein sollen (z.B. {"role": "role"} fügt die Rolle des Benutzers als JWT-Claim hinzu)
• token_expiry_seconds — Optionaler Override für die Token-Ablaufzeit

Diese Flexibilität bedeutet, dass du verschiedene Authentifizierungsmuster unterstützen kannst: Login per E-Mail, Login per Benutzername, Login per Telefonnummer — was auch immer deine Entity-Definition unterstützt.

Das Einrichten in der Admin-UI ist unkompliziert. Der FROM-Schritt definiert deinen Workflow als API-Endpunkt mit JSON-Format — RDataCore generiert die Endpunkt-URL automatisch für dich. Dann wird der Authenticate-Transform mit einfachen Dropdowns und Textfeldern konfiguriert: Wähle deinen Entity-Typ, die Identifikator- und Passwort-Felder, mappe die Eingabefelder und lege den Namen des JWT-Ausgabefelds fest. Der gesamte Login-Workflow kann in unter einer Minute konfiguriert werden, ganz ohne Code.

Nach dem Login hält das Frontend ein Entity JWT. Jetzt kann es auf geschützte Workflow-Endpunkte zugreifen — Workflows, die eine Authentifizierung erfordern.

RDataCore unterstützt eine dedizierte EntityJwt-Authentifizierungsmethode für Workflow-Endpunkte. Wenn du einen Workflow mit EntityJwt-Authentifizierung konfigurierst, wird RDataCore:

1. Das Bearer-Token aus dem Authorization-Header extrahieren
2. Die JWT-Signatur mit dem entitätsspezifischen Secret ({jwt_secret}_entity) verifizieren
3. Den Issuer-Claim (r_data_core_entity) validieren
4. Alle konfigurierten required claims prüfen (z.B. role: "member")

Wenn alle Prüfungen bestehen, wird die Anfrage verarbeitet und der Workflow ausgeführt. Wenn eine Prüfung fehlschlägt, erhält der Client eine 401 Unauthorized-Antwort.

Das required_claims-Feature ist besonders mächtig für rollenbasierte Zugriffskontrolle. Du kannst verschiedene Workflows mit unterschiedlichen Claim-Anforderungen erstellen:

• Ein "Profil"-Workflow, der nur ein gültiges Entity JWT erfordert (jeder authentifizierte Benutzer)
• Ein "Premium-Content"-Workflow, der {"extra.tier": "premium"} erfordert
• Ein "Admin-Dashboard"-Workflow, der {"extra.role": "admin"} erfordert

JWT-Secret-Isolation ist ein kritisches Sicherheitsfeature. Entity JWTs und Admin JWTs verwenden vollständig separate Signaturschlüssel und Issuer-Claims:

• Admin JWT: signiert mit {jwt_secret}, Issuer r_data_core_admin
• Entity JWT: signiert mit {jwt_secret}_entity, Issuer r_data_core_entity

Diese dreischichtige Isolation (unterschiedlicher Schlüssel, unterschiedlicher Issuer, unterschiedliche Claims-Struktur) bedeutet, dass ein Entity JWT niemals als Admin-Benutzer authentifizieren kann und ein Admin JWT niemals die Entity-JWT-Verifizierung bestehen kann. Selbst wenn ein Angreifer ein Entity-Token erhält, kann er nicht zum Admin-Zugriff eskalieren.

Die Kombination aus dynamischen Entitäten, workflowbasierter Authentifizierung und JWT-geschützten Endpunkten eröffnet eine breite Palette von Headless-Anwendungsfällen:

Kunden-Self-Service-Portal Baue ein Portal, in dem Kunden sich anmelden, ihre Bestellungen einsehen, ihr Profil aktualisieren, Rechnungen herunterladen und Abonnements verwalten. Das Portal kommuniziert ausschließlich mit RDataCores Workflow-Endpunkten — kein eigenes Backend nötig. Benutzerdaten, Bestelldaten und Abonnementdaten leben alle als Entitäten in RDataCore.

Internes Operations-Tool Erstelle ein internes Dashboard für dein Team zur Verwaltung von Inventar, Sendungsverfolgung oder Bearbeitung von Support-Tickets. Mitarbeiter authentifizieren sich über Entity JWT, wobei rollenbasierter Zugriff sicherstellt, dass Lagermitarbeiter andere Daten sehen als die Geschäftsführung. Alle Geschäftsdaten werden zentral in RDataCores Entity-Speicher verwaltet.

E-Commerce-Storefront Betreibe ein Headless-E-Commerce-Frontend mit RDataCore als Produktkatalog und Kundendatenbank. Produkte, Kategorien und Preise sind Entitäten, die über die MDM-Admin-UI verwaltet werden, während Kundenregistrierung und Bestellaufgabe über Workflow-Endpunkte ablaufen. Kombiniere mit Stripe-Webhooks für die Zahlungsabwicklung.

IoT-Geräte-Dashboard Sensordaten fließen über Import-Workflows in RDataCore, während Gerätebetreiber sich in ein benutzerdefiniertes Dashboard einloggen, um Messwerte einzusehen, Alarme zu konfigurieren und Gerätemetadaten zu verwalten. Das Password-Feld auf einer "DeviceOperator"-Entität und Entity-JWT-Auth machen das unkompliziert.

Multi-Tenant-SaaS-Plattform Verwende Entity-Hierarchien zur Trennung von Mandantendaten (z.B. /tenants/acme-corp/users/, /tenants/acme-corp/projects/), wobei Entity-JWT-Claims den Mandanten-Identifikator tragen. Die Benutzer jedes Mandanten sehen nur ihre eigenen Daten durch entsprechend eingeschränkte Workflows.

Mobile-App-Backend React Native oder Flutter Apps können Benutzer registrieren, authentifizieren und Daten über dieselben Workflow-Endpunkte wie Webanwendungen abrufen. Das API-First-Design bedeutet, dass deine Mobile- und Web-Frontends dasselbe Backend teilen, ohne plattformspezifischen Code auf dem Server.

RDataCore als Headless-Backend zu verwenden ist nicht nur praktisch — es ist architektonisch sinnvoll. Hier ist, warum eine Master-Data-Management-Plattform eine exzellente Grundlage für Headless-Anwendungen bildet:

Single Source of Truth In einem typischen Headless-Setup hast du möglicherweise Benutzerdaten in Auth0, Produktdaten in einem CMS, Bestelldaten in einer separaten Datenbank und Konfiguration in noch einem weiteren Dienst. Mit RDataCore lebt alles an einem Ort. Benutzer, Produkte, Bestellungen, Konfiguration — sie sind alle Entitäten, verwaltet über dieselbe Oberfläche, gesichert durch denselben Speicher und zugänglich über dieselbe API.

Schema-Flexibilität ohne Migrationen Musst du ein telefonnummer-Feld zu deiner User-Entität hinzufügen? Ein rabattcode-Feld zu deiner Bestell-Entität? Aktualisiere einfach die Entity-Definition über die Admin-UI. Keine Datenbankmigrationen, keine Deployment-Zyklen, keine Ausfallzeit. RDataCores dynamisches Entity-System bedeutet, dass sich dein Datenmodell so schnell entwickelt wie deine Geschäftsanforderungen.

Eingebaute Datenqualität RDataCores Feld-Constraints (erforderlich, eindeutig, indiziert, validiert) erzwingen Datenqualität auf Plattformebene. Wenn dein Headless-Frontend Daten über einen Workflow übermittelt, durchlaufen sie dieselbe Validierungspipeline wie jeder andere Dateneingabepunkt. Fehlerhafte Daten werden abgewiesen, bevor sie den Speicher erreichen.

Workflowgesteuerte Geschäftslogik Das FROM → TRANSFORM → TO Workflow-Modell ermöglicht es dir, Geschäftslogik direkt in RDataCore zu kodieren. Registrierungs-Workflows können Deduplizierung beinhalten. Login-Workflows stellen korrekt eingeschränkte Tokens aus. Datenanbieter-Workflows können Daten vor der Auslieferung filtern und transformieren. Das bedeutet weniger benutzerdefinierten Code in deinen Frontend- und Backend-Schichten.

Einheitliche Admin-Oberfläche RDataCore wird mit einer vollständigen Admin-UI für die Verwaltung von Entity-Definitionen, das Durchsuchen von Daten, die Konfiguration von Workflows und die Überwachung des Systemzustands geliefert. Dein Operations-Team kann Benutzerkonten verwalten, Daten inspizieren und Geschäftsregeln konfigurieren, ohne Code zu berühren — während deine Headless-Frontends dieselben Daten über die API konsumieren.

Import/Export-Integration Da RDataCore im Kern eine MDM-Plattform ist, kannst du sie gleichzeitig für Massen-Datenoperationen nutzen. Importiere 100.000 Produktdatensätze aus der CSV deines Lieferanten, während dein E-Commerce-Frontend diese Produkte in Echtzeit an Kunden ausliefert. Das Headless-Frontend und die Datenmanagement-Workflows koexistieren natürlich.

Die Headless-Architektur mit RDataCore folgt einem sauberen Drei-Schichten-Muster:

Frontend-Schicht (deine Headless-Clients) Beliebig viele Frontends, gebaut mit jedem Technologie-Stack. Jedes Frontend kommuniziert mit RDataCore ausschließlich über HTTPS-API-Aufrufe. Frontends kümmern sich um UI-Rendering, Benutzerinteraktion und lokalen Zustand — nichts anderes.

RDataCore-Schicht (das Headless-Backend) Die Workflow-Engine handhabt Registrierung, Authentifizierung und Datenoperationen. Die Authentifizierungsschicht verwaltet Entity JWTs und Pre-Shared Keys. Die Entity-Speicherung bietet dynamische, schemaflexible Datenpersistenz. Die Public API stellt alle Fähigkeiten für Frontends bereit.

Externe-Systeme-Schicht (Integrationen) Zahlungsanbieter, E-Mail-Dienste, CRMs, Legacy-Systeme und alle anderen externen Dienste integrieren sich über Workflows und Webhooks. RDataCore fungiert als zentraler Hub und koordiniert den Datenfluss zwischen deinen Frontends und dem weiteren Ökosystem.

Diese Architektur bedeutet, dass deine Headless-Frontends nie direkt mit externen Diensten kommunizieren. Alles fließt durch RDataCore, das Authentifizierung, Autorisierung, Datenvalidierung und Transformation bei jedem Schritt bereitstellt.