Identität und Zugriff nah an Ihren Nutzern überall auf der Welt.
Eine quelloffene, OpenID Certified™ Plattform für Identität und Zugriff auf Cloudflare Workers. Authentifizierung, Autorisierung und Föderation auf einer für den Edge entwickelten Architektur.
Vor Version 1.0. Die Kernprotokolle sind implementiert. Absicherung und Validierung für den Produktivbetrieb laufen weiter.
01
Anmeldung ohne Passwort
Anmeldung mit WebAuthn-Passkeys oder einem sechsstelligen E-Mail-Code. So können sich auch Nutzer ohne Passkey ohne Passwort anmelden.
02
SSO und Identitätsföderation
Verbinden Sie Anwendungen und vorhandene Identitätsanbieter über OpenID Connect und SAML 2.0. Konten entstehen bei der ersten Anmeldung; externe Identitäten lassen sich verknüpfen.
03
Zugriffskontrolle
Steuern Sie Zugriffe über Rollen (RBAC), Attribute (ABAC) und Beziehungen (ReBAC). Prüfen Sie Berechtigungen per API, mit eigenen Regeln für jeden Mandanten.
04
Automatische Skalierung
Erweitern Sie die Kapazität von Cloudflare D1 automatisch mit Ihrer Nutzerzahl. Authrim prognostiziert den Bedarf und ergänzt Datenbank-Shards, ohne dass Sie die Plattform wechseln müssen.
Am Anfang stand ein unangenehmer Moment im Alltag: Eine fehlgeschlagene Anmeldung untersuchen und dabei persönliche Informationen sehen, die man dafür gar nicht braucht.
Wenn die Fehlersuche persönliche Daten sichtbar macht
Wer eine Identitätsplattform betreibt, kennt diese Meldung: „Ein Nutzer kann sich nicht anmelden.“ Zur Fehlersuche öffnen Sie die Kundenumgebung und suchen das Konto.
Sie brauchen nur bestimmte Angaben: Ist das Konto gesperrt? Wann und an welcher Stelle ist der letzte Versuch gescheitert? Welcher Anmeldeweg wurde genutzt? Ist der Passkey noch gültig registriert?
Dafür müssen Sie nicht wissen, wer die Person ist. Trotzdem sehen Sie beim Öffnen des Kontos Namen, E-Mail-Adresse, Telefonnummer und verknüpfte Konten auf demselben Bildschirm. Sie suchten einen technischen Zustand. Sie bekamen persönliche Informationen dazu.
„Bitte nicht hinsehen“ schützt nicht, solange die Daten auf dem Bildschirm stehen.
Dabei hat niemand einen Fehler gemacht. Der Kunde hat die Untersuchung angefordert, Sie haben das Verfahren eingehalten und die Aufgabe erledigt. Gesehen haben Sie die Daten trotzdem. Der Aufbau des Systems hat sie Ihnen gezeigt.
Mit Richtlinien und Schulungen allein hängt der Schutz vom Gedächtnis und der Aufmerksamkeit der zuständigen Person ab. Auf Dauer kann daraus ein Vorfall werden. Die Trennung personenbezogener Daten in eine eigene Datenbank begann mit dem Versuch, dieses Problem im Aufbau des Systems zu lösen.
Zwei Datenbanken von Anfang an
Direkt identifizierende Daten liegen in einer physisch getrennten Datenbank. Die Trennung wurde nicht nachträglich aufgesetzt, sondern beginnt bereits in der Datenzugriffsschicht.
Beachten Sie die letzten beiden Einträge rechts: Löschvermerke und Protokolle über PII-Lesezugriffe liegen getrennt auf der PII-Seite. Zugriffe auf personenbezogene Daten werden unabhängig vom allgemeinen Audit-Protokoll erfasst.
Mit dieser Trennung lässt sich das Ausgangsproblem lösen. Sperrstatus, fehlgeschlagene Anmeldungen und Geräteinformationen liegen links. Der für eine Untersuchung nötige Zugriff kann freigegeben werden, ohne die rechte Seite zu öffnen. Niemand muss daran denken, wegzusehen.
Dieselbe Struktur beantwortet nebenbei Audit-Fragen. Wo Namen und E-Mail-Adressen liegen und welche Daten eine Löschung umfasst, lässt sich klar zeigen. Die Lösung des Betriebsproblems macht auch die Architektur leichter erklärbar.
Auch außerhalb der PII DB gibt es personenbezogene Daten
Das muss ausdrücklich gesagt werden: Diese Trennung ist keine rechtliche Grenze zwischen personenbezogenen und nicht personenbezogenen Daten.
In der Core DB liegen IP-Adressen, Geräteinformationen, Sitzungsverläufe, Authentifizierungsereignisse, Metadaten zu Anmeldemitteln und stabile interne Nutzer-IDs. Auch das können personenbezogene Daten sein. Allein identifizieren sie möglicherweise niemanden, zusammen mit anderen Informationen aber schon.
Authrim trennt direkt identifizierende Daten von Identitätsdaten für den Betrieb. Eine Untersuchung soll mit der zweiten Gruppe auskommen, ohne auf die erste zuzugreifen. Auch die zweite Gruppe muss geschützt werden.
Die Aussage „Personenbezogene Daten gibt es nur in der PII DB“ wäre falsch. Treffend ist: Namen, E-Mail-Adressen und andere direkt identifizierende Daten sind in der PII DB isoliert. Rechte zur Fehlersuche können vergeben werden, ohne diesen Speicher zugänglich zu machen.
Mit dem Löschen ist es nicht getan
Ein Konto auf Wunsch zu löschen ist einfach. Schwieriger sind die beiden Anforderungen, die danach kommen können.
Die erste ist der Nachweis der Löschung: wann, durch wen und warum. Die zweite ist das Verhindern einer erneuten Registrierung für einen bestimmten Zeitraum, wie es Geschäftsregeln häufig vorsehen.
Beides verlangt, eine Person wiederzuerkennen, deren Daten gelöscht wurden. Direkt identifizierende Angaben dafür aufzubewahren, widerspricht jedoch dem Zweck der Löschung.
Ein Blindindex mit HMAC-SHA256 erlaubt den Abgleich, ohne den ursprünglichen Wert zu speichern. Ob eine Adresse gelöscht wurde, lässt sich prüfen. Aus der Tabelle allein lässt sich die ursprüngliche Adresse nicht ablesen.
Das Prinzip lautet: Nur den für die Wiedererkennung erforderlichen Prüfwert aufbewahren und nach Ablauf der Frist löschen. Dazu werden Zeitpunkt, verantwortliche Person und Grund der Löschung erfasst.
Wovon „nicht rekonstruierbar“ abhängt
Ein technisches Detail ist wichtig: E-Mail-Adressen haben wenig Entropie. Bei einem einfachen Hash kann ein Wörterbuchangriff die Adresse ermitteln. „Nicht rekonstruierbar“ gilt daher nicht ohne Bedingungen.
Authrim verwendet einen HMAC-SHA256-Blindindex mit einem geheimen Schlüssel. Eine Schlüsselgeneration wird mitgespeichert, damit Schlüssel gewechselt werden können. Ohne den Schlüssel lassen sich mögliche Adressen nicht durch Berechnen ihrer Prüfwerte abgleichen.
Die Trennung des Schlüssels ist Voraussetzung für diesen Schutz. Liegt er neben den Prüfwerten, geht diese Eigenschaft verloren. Diese Bedingung gehört auch in jede öffentliche Beschreibung.
Nur die Daten öffnen, die die Untersuchung braucht
Zurück zur fehlgeschlagenen Anmeldung: Gesucht wird die Stelle, an der die Authentifizierung abbrach. Ein Name oder eine Telefonnummer muss dafür normalerweise nicht geöffnet werden.
Authrim trennt direkt identifizierende Informationen, damit Rechte zur Fehlersuche ohne Zugriff auf diesen Speicher vergeben werden können. Werden tatsächlich personenbezogene Daten benötigt, übernimmt jemand mit den passenden zusätzlichen Berechtigungen.
Verschlüsselung und Zugriffskontrolle schützen die Daten, Audit-Logs zeichnen ihre Nutzung auf. Darüber hinaus sollte die zuständige Person gewöhnliche Untersuchungen abschließen können, ohne unnötige persönliche Informationen zu öffnen. Getrennter Speicher macht das zum Ausgangspunkt des täglichen Betriebs.
Umsetzung: Speichertrennung und Zugriffsgrenze sind implementiert.
Validierung: Durch automatisierte Tests im Repository abgedeckt.
Betriebsreife: Die Absicherung läuft weiter. Authrim ist noch vor Version 1.0.
Diese Architektur erleichtert Löschprozesse. Sie allein garantiert keine rechtliche Konformität; dafür sind auch die Verfahren und Verträge der Organisation entscheidend.
Eine Person meldet sich einmal an. Im Hintergrund entstehen aber mehrere Sitzungen. Beim Abmelden kommt es darauf an, welche davon beendet werden und wie die Nachricht alle beteiligten Systeme erreicht.
Eine Anmeldung, drei Schlüssel
Sie ergänzen Ihren Dienst um „Mit Google anmelden“. Für den Nutzer ist das ein einziger Klick.
Im Hintergrund erstellt und verwaltet jedes beteiligte System eine eigene Sitzung. Google hat eine, Authrim eine und Ihre Anwendung eine. Insgesamt drei.
Eine verbleibende Sitzung kann die weitere Nutzung oder eine erneute Anmeldung ohne Passworteingabe ermöglichen.
Abmelden bedeutet mehr als „Sie wurden abgemeldet“ anzuzeigen. Es bedeutet, den Geltungsbereich festzulegen und die Sitzungen darin zu beenden.
Token-Widerruf ist ein eigener Vorgang
Die „Schlüssel“ stehen hier für Sitzungen. Access- und Refresh-Tokens funktionieren anders. Das Beenden einer Sitzung macht bereits ausgestellte Tokens nicht unbedingt ungültig. Dafür ist ein gesonderter Widerruf erforderlich.
In OIDC sind Sitzungsabmeldung, Token-Widerruf und die Deaktivierung eines vorgelagerten Kontos drei verschiedene Vorgänge. Dieser Artikel behandelt Sitzungen. Wann ein Token nicht mehr akzeptiert wird, beschreibt die Dokumentation zu Token-Introspektion und -Widerruf.
Authrim steht dazwischen
Der vorgelagerte Anbieter stellt die Anmeldung bereit, Ihre Anwendung fordert sie an. Authrims Rolle hängt davon ab, mit welcher Seite es kommuniziert.
Wie ein Reisebüro: Für Sie organisiert es die Reise, für die Fluggesellschaft ist es ein Kunde, der einen Sitzplatz kauft. Authrim erfüllt beide Rollen gleichzeitig.
Die Abmeldung bleibt oft unterwegs stecken
Die Anmeldung führt durch die Kette. Die Abmeldung muss dagegen ausdrücklich weitergereicht werden.
Das Beenden der vorgelagerten Sitzung entfernt nicht automatisch die Sitzungen in Authrim und Ihrer Anwendung. Die Nachricht muss weitergegeben werden, und jeder Empfänger muss die passende Sitzung beenden. Die folgende Grafik zeigt die Kette bei passenden Benachrichtigungsverfahren und Einstellungen.
Entscheidend ist der mittlere Pfeil: Kann Authrim die Nachricht empfangen und weiterleiten? Auch der vorgelagerte Anbieter und jede Anwendung müssen die erforderlichen Verfahren unterstützen und entsprechend konfiguriert sein.
Wie sich das im Alltag auswirkt
Situation
Folge einer unterbrochenen Kette
Austritt aus dem Unternehmen
Der Zugang wird entzogen. Auf dem Laptop bleibt die Anwendung jedoch geöffnet, und interne Daten sind noch bis zum nächsten Morgen sichtbar.
Gemeinsam genutzte Geräte
Im Geschäft, Krankenhaus oder Callcenter meldet sich jemand ab. Ein zweiter Tab zeigt trotzdem noch dessen Dashboard.
Verlorenes Gerät
„Überall abmelden“ wurde gewählt. Tatsächlich endete nur die gerade verwendete Sitzung.
Reaktion auf einen Vorfall
Das kompromittierte Konto wird gesperrt. Die Sitzung des Angreifers bleibt bis zum Ablauf gültig.
Audit
„Zeigen Sie, dass die Abmeldung alle Systeme erreicht.“ Ein Nachweis fehlt.
Der Abmeldeknopf fehlt in keinem dieser Fälle. Die Seite ändert sich auch. Aber die Wirkung reicht weniger weit als angenommen. Gerade deshalb fällt das Problem so schwer auf.
Der Weg über den Browser wird unzuverlässig
Es gibt zwei Wege, die Anwendungen zu benachrichtigen. Einer davon stößt zunehmend an Grenzen.
Oben werden Anwendungen über unsichtbare Frames benachrichtigt. Safari, Firefox und Chrome schränken solche Frames zunehmend ein. Beim Back-Channel sprechen die Server direkt miteinander; die Zustellung hängt daher nicht vom Browserzustand ab. Garantiert ist sie trotzdem nicht: Netzwerkfehler, ausgefallene Empfänger, Zeitüberschreitungen und 5xx-Antworten können sie verhindern. Wiederholungen, Warteschlangen und Fehlerprotokolle sind Aufgabe der Implementierung.
Authrims Zertifizierung umfasst den Empfang über den Back-Channel. Empfang und Weiterleitung einer Nachricht müssen jeweils geprüft werden.
Empfänger und Absender getrennt prüfen
Gegenüber dem vorgelagerten Anbieter ist Authrim eine Relying Party (RP), gegenüber den Anwendungen ein OpenID Provider (OP). Um die Abmeldung weiterzugeben, muss es in beiden Rollen die Spezifikationen erfüllen.
Als RP: Die vorgelagerte Abmeldenachricht prüfen und die passende Authrim-Sitzung beenden.
Als OP: Abmeldenachrichten senden, damit angebundene Anwendungen die passenden Sitzungen beenden können.
Die Zertifizierungen für OP- und RP-Logout-Profile liefern Nachweise für diese beiden Rollen. Authrim hat auf beiden Seiten zertifizierte Logout-Profile im Selbstzertifizierungsverfahren der OpenID Foundation, das deren offizielle Konformitätstests verwendet.
Eine Zertifizierung bedeutet, dass die eingereichte Implementierungsversion die Konformitätstests der eingereichten Profile bestanden hat. Sie garantiert nicht, dass jede Sitzung in den Anwendungen und im Netzwerk eines Kunden sofort endet.
Der vorgelagerte Anbieter und jede Anwendung müssen die nötigen Verfahren unterstützen. Benachrichtigungsendpunkte und Sitzungszuordnung müssen eingerichtet sein. Die Deaktivierung eines vorgelagerten Kontos löst nicht zwingend eine Abmeldenachricht aus. Auch Zustellfehler, Wiederholungen und die Sichtbarkeit von Fehlern sind in der konkreten Umgebung zu prüfen.
Wo bleibt nach dem Abmelden noch eine Sitzung aktiv?
Diese Frage zählt, wenn ein gemeinsam genutztes Gerät weitergegeben oder der Zugang ehemaliger Mitarbeitender beendet wird. Authrim empfängt und sendet Nachrichten, um die Sitzungsbeendigung vom vorgelagerten Anbieter bis zu den Anwendungen zu verbinden. Die Zertifizierung belegt Eigenschaften der Implementierung. Ob die Abmeldung im gewünschten Umfang ankommt, zeigen Tests der tatsächlich verbundenen Systeme.
Die Passwörter liegen bereits in Active Directory. Wie ergänzen Sie moderne Anmeldung, ohne Passwort-Hashes zu kopieren oder einen neuen Konnektor-Endpunkt von außen erreichbar zu machen?
Mit dem beginnen, was bleiben muss
Die Mitarbeiterkonten liegen in Active Directory. Dort werden auch Passwortregeln, Ablaufzeiten und Kontosperren beim Austritt verwaltet. Dieses System läuft seit Jahren.
Sie möchten Passkeys ergänzen, MFA vereinheitlichen und mehr SaaS-Anwendungen per SSO anbinden. Das Ziel ist klar. Die erste Frage bleibt: Wo wird das Passwort geprüft?
Manche Architekturen synchronisieren Passwort-Hashes in die Cloud, andere lassen das interne Verzeichnis die Zugangsdaten prüfen. Entscheidend ist, wo diese Daten liegen, welche Seite die Verbindung aufbaut und wer den Verbindungsweg betreibt.
WordWarden überlässt die Prüfung weiterhin LDAP/AD und lässt Ihnen die Wahl des Verbindungswegs. Authrim Relay bietet eine ausgehende Verbindung für Organisationen, die keinen neuen öffentlich erreichbaren Endpunkt einrichten möchten.
Was WordWarden übernimmt
Authrim WordWarden ist ein Verzeichniskonnektor: ein kleiner Dienst in der Nähe Ihres LDAP/AD. Seine Aufgabe ist klar begrenzt: Nutzernamen und Passwort entgegennehmen, beim Verzeichnis prüfen lassen und das Ergebnis zurückgeben.
Anmeldeoberfläche, Sitzungen, Passkeys, E-Mail-Codes, Föderation, Audit-Verknüpfung und Identitätszuordnung bleiben bei Authrim. WordWarden übernimmt nur die Prüfung beim Verzeichnis.
Die Verbindungsrichtung bestimmt mit, wie Sie das Netzwerk konfigurieren und welche Komponenten Sie betreiben.
Wer verbindet sich mit wem?
WordWarden unterstützt drei Verbindungswege. Der Unterschied: Muss Ihr Netzwerk einen von außen erreichbaren Endpunkt bereitstellen?
Die Pfeile zeigen, welche Seite die Verbindung aufbaut. Bei Direct HTTPS verbindet sich Authrim mit einem veröffentlichten Endpunkt. Tunnel und Relay beginnen dagegen in Ihrem Netzwerk: Tunnel verwendet den separaten Prozess cloudflared, während WordWarden die Relay-Verbindung selbst aufrechterhält.
Was passt zu Ihrer Umgebung?
Wenn Sie eine neue Anbindung ohne zusätzlichen eingehenden Zugang planen, prüfen Sie zuerst Relay. Eine vorhandene Plattform zur Veröffentlichung von Diensten oder ein bestehender Tunnel kann ebenfalls sinnvoll sein. Die folgenden Beispiele sind Einsatzszenarien, keine Berichte über Kundeninstallationen.
Authrim Relay: AD intern halten, ohne neuen eingehenden Zugang
Ein Unternehmen betreibt AD in der Zentrale und prüft jeden neuen öffentlichen Server gesondert. Oder eine Universität erlaubt keine eingehenden Verbindungen zu ihrem LDAP-Netz. WordWarden baut die Verbindung zu Authrim auf. Im internen Netzwerk muss dafür kein neuer Port für eingehende Verbindungen veröffentlicht werden.
Ein neuer öffentlicher Endpunkt oder ein separater Tunnelprozess ist nicht nötig. Ausgehender WebSocket-Verkehr muss erlaubt sein. Dienstzustand und Verbindung von WordWarden müssen weiter überwacht werden. Für ein Netzwerk, das jede externe Kommunikation untersagt, ist Relay nicht geeignet.
Eine Organisation veröffentlicht interne Werkzeuge bereits über Cloudflare Tunnel. Ein Team kümmert sich um cloudflared-Updates und Routing. WordWarden kann diese Abläufe nutzen, ohne einen neuen eingehenden Port zu öffnen.
Sie konfigurieren Hostnamen und Route, über die Authrim den Konnektor erreicht, und betreiben den Tunnel. Der interne Host braucht keinen direkten eingehenden Zugang; die Anfragen kommen aber über eine Cloudflare-Route an.
Direct HTTPS: eine vorhandene API-Plattform nutzen
Ein Unternehmen, eine Universität oder eine Forschungseinrichtung betreibt vielleicht bereits eine DMZ und einen Reverse Proxy für externe Anbindungen. Ein für Authrim erreichbarer HTTPS-Endpunkt kann die vorhandenen Verfahren für Zertifikate, Zugriffsprotokolle und Monitoring nutzen.
Eine zusätzliche Tunnel- oder Relay-Verbindung entfällt. Dafür erlaubt die Organisation den eingehenden Verbindungsweg und übernimmt Schutz und Wartung des öffentlichen Endpunkts. Veröffentlicht wird die HTTPS-Schnittstelle des Konnektors, nicht der LDAP/AD-Port direkt im Internet.
In allen Varianten muss WordWarden LDAP/AD erreichen können. Dass eine Organisation eine Hochschule ist, legt die Methode nicht fest. Maßgeblich sind vorhandene Infrastruktur und Netzwerkrichtlinien.
Authrim Relay: die Verbindung beginnt im eigenen Netz
Im Relay-Modus verbindet sich WordWarden per WebSocket mit Authrim, aus Ihrem Netzwerk heraus. WebSocket hält eine Verbindung offen, über die beide Seiten Nachrichten senden können.
WordWarden hält diese Verbindung offen und wartet. Meldet sich jemand an, bittet Authrim über dieselbe Verbindung um Prüfung. WordWarden fragt das interne Verzeichnis und sendet das Ergebnis zurück.
Stellen Sie sich vor, Sie rufen aus der Organisation heraus an und bleiben in der Leitung. Auch die Gegenseite kann sprechen. Es ist nicht für jede Anfrage eine neue eingehende Verbindung nötig.
Praktisch heißt das: Auf der Verzeichnisseite muss keine öffentliche URL bereitgestellt werden. Hostname, Zertifikat und WAF für einen neuen öffentlichen Endpunkt entfallen. Die ausgehende Verbindung muss erlaubt sein; WordWarden und seine Verbindung müssen weiterhin betreut werden.
Technischer Hintergrund: WebSocket und eingehende Ports
Der Unterschied liegt darin, welche Seite die Verbindung startet. Bei Direct HTTPS stellt die Organisation einen Endpunkt bereit, den Authrim erreichen kann. Bei Relay öffnet WordWarden intern eine verschlüsselte WebSocket-Verbindung (wss) zu Authrims Relay.
Eine zustandsbehaftete Firewall oder NAT verfolgt üblicherweise intern gestartete Verbindungen und erlaubt deren Rückverkehr. So empfängt WordWarden Prüfanfragen, ohne einen eingehenden Port zu veröffentlichen oder Portweiterleitungen für neue externe Verbindungen einzurichten.
Das bedeutet nicht, dass keine Ports verwendet werden. Eine typische wss-Verbindung nutzt am Ziel TCP-Port 443. Firewall oder Proxy müssen ausgehenden Zugriff auf Relay und dauerhafte WebSocket-Verbindungen erlauben. Bei unterbrochener Verbindung können über diesen Weg keine Anfragen ankommen. Deshalb bleibt Monitoring nötig.
Weniger Endpunkte für neue externe Verbindungen bedeuten nicht, dass keine Prüfanfragen mehr eintreffen. Sie kommen über die bestehende Verbindung. Die Gegenstelle muss authentifiziert, die Anfrage weiterhin validiert werden.
Auch eine ausgehende Verbindung braucht Authentifizierung. Relay verbindet die Authentifizierung des Konnektors mit Prüfungen des konfigurierten Ziels.
Technischer Hintergrund: Authentifizierung mit HMAC
WordWarden beantwortet eine kurzlebige Challenge mit einem HMAC und signiert dabei eine Zeichenfolge aus Challenge-ID und Nonce. Außerdem prüft es, ob Mandanten- und Konnektor-ID in der Ziel-URL mit seiner Konfiguration übereinstimmen.
HMAC ist bei allen drei Verbindungswegen erforderlich. Relay reduziert die Angriffsfläche für eingehende Verbindungen, ersetzt aber weder die Konnektorauthentifizierung noch die Verwaltung geheimer Schlüssel.
Welche Daten die Grenze passieren
Hier kommt es auf eine präzise Formulierung an. Die Aussage, das Passwort verlasse Ihr Netzwerk nie, wäre falsch.
Die Person gibt ihr Passwort auf einer Anmeldeseite ein. Es läuft deshalb durch Authrim. Die korrekte Aussage lautet: „Authrim und WordWarden speichern das Passwort nicht.“
Die Dokumentation formuliert das ausdrücklich: Authrim darf Passwörter weder importieren, hashen, erneut hashen noch dauerhaft speichern. Das gilt auch für Passwort-Hashes aus Altsystemen.
Auch die Antwort ist begrenzt
Bei erfolgreicher Prüfung erhält Authrim das Ergebnis und die angefragten Attribute, beschränkt auf die lokale Freigabeliste des Konnektors. Nicht die anfragende Seite entscheidet, welche Daten sie abrufen darf. Die Verzeichnisseite entscheidet, was sie herausgibt.
Das ist entscheidend: Eine Änderung allein auf der Authrim-Seite kann den Umfang der herausgegebenen Daten nicht erweitern.
Das Passwort als Übergang
Diese Anbindung soll vor allem einen Übergang ermöglichen.
LDAP/AD bleibt für Passwörter zuständig. Die Menschen melden sich weiter mit ihrem vorhandenen Konto an. Passkeys werden schrittweise ergänzt. E-Mail-Codes bleiben ein Weg zur Wiederherstellung des Zugangs. Die Anmeldung funktioniert weiter, während sich die Methode dahinter verändert.
Die Dokumentation ist auch hier eindeutig: Keine LDAP/AD-Passwort-Hashes nach Authrim exportieren. Sonst wird aus der Übergangslösung eine Kopie der Zugangsdaten.
Die öffentliche Beta wird vorbereitet. Als erste Version ist v0.1.0-beta.1 vorgesehen.
Für Pilotprojekte gedacht: Organisationen müssen einen kleinen Dienst nahe LDAP/AD betreiben können und die Zuständigkeiten für Verzeichnis, Netzwerk, TLS und Verwaltung geheimer Schlüssel und Zugangsdaten kennen. Dies ist kein verwalteter Verzeichnisdienst.
Erfordert Authrim ab 0.3.2 mit aktivierter Directory Authentication und Relay. In der aktuellen Beta muss der Prozess nach Konfigurationsänderungen neu gestartet werden.
„Zugangsdaten nach außen oder Verbindungen nach innen“ sind nicht die einzigen Möglichkeiten.
Prüfen Sie beim Verzeichnis und starten Sie die Verbindung von innen. Damit wird moderne Anmeldung möglich, ohne Passwort-Hashes zu kopieren oder einen eingehenden Endpunkt im internen Netz zu veröffentlichen.
Am Ende steht der Wechsel zu Passkeys. Die Verzeichnisanbindung schafft die Grundlage, damit dieser Übergang gelingt, ohne die Anmeldung zu unterbrechen.
Mehr Nutzer kommen. Das ist erfreulich, wirft aber eine Frage auf: Wie lange reicht die bisherige Datenbank? Authrim bereitet neuen Kontospeicher vor, bevor er gebraucht wird. So muss Wachstum nicht mit einem Migrationsprojekt beginnen.
Mehr Speicher, bevor Daten umziehen müssen
Cloudflare D1, die von Authrim verwendete Datenbank, hat eine Größenbegrenzung pro Datenbank: 500 MB im Free-Tarif und 10 GB im Paid-Tarif. Wachsen Nutzerzahl und Datenbestand, wird irgendwann weiterer Speicher nötig.
Authrim verteilt Konten von Anfang an auf mehrere Datenbanken. Wenn mehr Kapazität gebraucht wird, müssen deshalb nicht alle vorhandenen Konten umziehen. Jede dieser Speichereinheiten nennen wir einen Shard.
Vorhandene Konten bleiben, wo sie sind. Für neue Konten kommen weitere Speicherorte hinzu. Das ist der Grundgedanke hinter der Erweiterung des Kontospeichers.
Daten wachsen unterschiedlich schnell
Authrim speichert Mandanteneinstellungen wie OAuth-Clients und Regeln, Konten und personenbezogene Daten sowie die Suchindizes zum Auffinden eines Kontos über seine E-Mail-Adresse getrennt.
Mehr Nutzer bedeuten nicht, dass alle Datenbanken zugleich wachsen müssen. Kontospeicher und Suchindizes haben unterschiedliche Datensatzmengen und Wachstumsraten. Kapazität kommt dort hinzu, wo sie gebraucht wird.
Konten und personenbezogene Informationen liegen in getrennten Datenbanken. Warum, erklärt der Artikel Wo persönliche Daten liegen.
Wie viele Konten passen noch hinein?
Ein neues Konto wird einem Shard zugewiesen, der für seinen Mandanten verfügbar ist. Bevorzugt werden funktionsfähige Shards, deren Kontozahl im Verhältnis zum Zielwert niedriger ist.
Entscheidend ist nicht die belegte Festplattenkapazität, sondern wie viele Konten bis zum eingestellten Zielwert noch aufgenommen werden können. Bei einem Ziel von 100.000 Konten hilft ein Rest von etwa 20.000 dabei zu entscheiden, wann der nächste Speicherort vorbereitet werden sollte.
Wenn die verfügbaren Shards nur noch wenig Spielraum bieten, wird eine vorbereitete Reserve zugeteilt. Das gilt sowohl für gemeinsam genutzte Shards mehrerer Mandanten als auch für exklusive Shards eines einzelnen Mandanten.
Gemeinsam genutzter Speicher
Exklusiver Speicher
Gemeinsamer und exklusiver Speicher
Bei gemeinsamem, exklusivem und gemischtem Betrieb schaffen neue Shards Speicherorte für neue Konten. Der Wasserstand zeigt die Zahl zugewiesener Konten, nicht die Plattenbelegung oder den genauen Bereitstellungszeitpunkt. Die Unterteilungen stehen für die logische Trennung der Mandanten.
Was im Alltag entfällt
Ist die automatische Bereitstellung eingerichtet, muss der Betreiber nicht bei jedem Wachstum eine Datenbank anlegen, Tabellen vorbereiten und einen neuen Speicherort für Registrierungen anbinden. Auch ein neuer Migrationsplan für bestehende Konten ist nicht jedes Mal nötig.
Der Betreiber prüft, ob die Bereitstellung vorankommt, Fehler sichtbar sind und Nutzung sowie Kosten im erwarteten Rahmen bleiben. Berechtigungsprobleme und Dienstlimits erfordern weiterhin Aufmerksamkeit. Die Vorbereitung des nächsten Speicherorts übernimmt Authrim.
Der freie Platz von heute reicht als Maßstab nicht
Bei 20.000 freien Kontoplätzen hat ein Dienst mit 100 neuen Konten pro Tag viel mehr Vorlauf als einer mit 10.000 pro Stunde.
Authrim schätzt den künftigen Bedarf deshalb aus aktuellen Belegungen und jüngsten Registrierungsraten. Die Prognose umfasst Kontospeicher und Suchindizes. Eine zeitgesteuerte Aufgabe läuft jede Minute; die Kontoprognose wird zusätzlich nach Zuweisungen aktualisiert.
Shards, die gerade angelegt werden, fließen bereits in die Schätzung ein. Wenn mehrere Prozesse denselben Engpass erkennen, soll nicht jeder eine zusätzliche unnötige Datenbank erstellen.
Von der Anlage bis zur Nutzung
Reicht die Reserve nicht aus, erstellt Authrim D1-Datenbanken über die Cloudflare-Verwaltungs-API. Es legt Tabellen an, richtet Worker-Zugriffe ein und verteilt die neuen Speicherorte. Erst nach erfolgreichen Lese- und Schreibprüfungen erhält eine Datenbank neue Konten.
Die automatische Bereitstellung muss aktiviert sein. Für D1 und Workers sind getrennte API-Tokens einzurichten. Ist die automatische Ausführung nicht verfügbar, führt ein Betreiber die Arbeit mit dem Setup-Werkzeug weiter.
Der Fortschritt wird während der Anlage gespeichert. Nach einem vorübergehenden Verbindungsfehler kann der Vorgang von dort aus wiederholt werden. Fehlende Berechtigungen oder Ressourcenlimits muss ein Betreiber beheben, bevor es weitergeht.
Wenn die Vorbereitung zu langsam ist und keine Kontoplätze mehr frei sind, müssen neue Registrierungen gegebenenfalls wiederholt werden. Vorausschauende Bereitstellung soll diese Wartezeit verringern.
Über Datenumzüge entscheidet der Betreiber
Kapazität ergänzen und vorhandene Daten verschieben sind getrennte Vorgänge. Soll ein Mandant etwa von einem gemeinsamen in einen exklusiven Shard wechseln, müssen auch die bestehenden Daten kopiert werden.
Der Betreiber entscheidet, ob die Migration beginnt. Nach der Freigabe übernimmt Authrim Synchronisierung, Prüfung und Umschaltung.
Nach der Freigabe werden die Daten synchronisiert und geprüft, dann wird auf den exklusiven Speicher umgeschaltet. In einer Phase pausieren Schreibvorgänge kurzzeitig.
Unterstützt wird derzeit der Wechsel von gemeinsamem zu exklusivem Speicher. Der Rückweg und eine automatische gleichmäßige Neuverteilung bestehender Konten sind nicht implementiert.
Auch das Löschen eines ausgemusterten Shards erfordert eine Freigabe. Wachstum allein löst weder das Verschieben noch das Löschen vorhandener Daten aus.
Was gemessen wurde
In einem Test im Juli 2026 mit 200.000 Konten belegten Core etwa 208 MB, PII etwa 238 MB und Lookup etwa 426 MB. Jeder Bereich lag unter 5 % des Limits von 10 GB pro Datenbank im Paid-Tarif. Der tatsächliche Bedarf hängt von Attributen und Indizes ab.
Der voreingestellte Zielwert liegt bei 100.000 Konten pro Shard. So bleibt Zeit für die nächste Bereitstellung, statt die Datenbank bis an ihre physische Grenze zu füllen.
Authrim ist noch vor Version 1.0. Langjährige Betriebserfahrung in großem Maßstab muss erst entstehen. Eine Speichermessung mit 200.000 Testkonten ist etwas anderes als der tägliche Betrieb eines Dienstes für Millionen Menschen.
Wachsen mit weniger Migrationsplanung
Ein kleiner Dienst braucht nicht vom ersten Tag an eine große Infrastruktur. Er kann mit wenigen Shards beginnen und bei steigenden Registrierungen Speicherorte ergänzen. Authrim bringt die Vorbereitung und die dafür nötigen Abläufe mit.
Wenn mehr Nutzer kommen, soll ein Datenbankumzug nicht die erste Aufgabe auf der Liste werden. Weniger Arbeit daran bedeutet mehr Zeit für den Dienst selbst.
Speichermessung vom 30. Juli 2026 mit 200.000 Testkonten. MB bezeichnet dezimale Einheiten. Die D1-Kapazitätsgrenzen stehen in der Cloudflare-Dokumentation.
K6-Cloud-Tests decken typische OIDC-Lasten ab. Die Kapazität hängt von der Art der Anfragen, den Cloudflare-Tariflimits, dem Speicher und der Shard-Verteilung ab.
Authrim erhebt keine Gebühr pro Nutzer. Die Infrastrukturkosten hängen von Anfragen, CPU-Zeit, Speicher und Protokollierung ab. Diese Cloudflare-Schätzung dient zur Orientierung und ist kein verbindliches Angebot.
Monatlich aktive Nutzer50.000
Art des Dienstes
AnnahmenWöchentliche Anmeldung, 10 % täglich aktiv, Sitzung: 7 Tage
Kostenlos/ Monat
Anfragen~1M
Pro NutzerKostenlos
Workers: kostenloser Tarif (100.000/Tag)(USD)
Grundlage sind die Preise für Cloudflare Workers mit einem Faktor für KV, Durable Objects und D1 aus beobachteten Authrim-Nutzungsmustern.
Hinweis — Nur Infrastruktur. Nicht enthalten: Compliance, Monitoring, Support, Betrieb, Sicherheitsprüfungen, externe Datenbanken und umfangreiche R2- oder Archivnutzung. Die tatsächlichen Kosten hängen vom Einsatz ab.
TypeScript-orientierte APIs, JavaScript-SDKs und ein Setup-Ablauf, um Identitätsdienste am Edge zu erproben und zu entwickeln.
TypeScriptSDKsSchnelles Setup
B
Unternehmen
Behalten Sie im eigenen Betrieb die Kontrolle: mit SAML, SCIM, Audit-Logs, Mandantentrennung sowie Regeln für Speicherung und Protokollierung. Die Absicherung für den Produktivbetrieb wird weiter ausgebaut.
SSOSCIMCompliance
C
Start-ups
Starten Sie auf Cloudflare ohne Authrim-Gebühr pro Nutzer. Skalieren Sie anhand des gemessenen Bedarfs an Anfragen, CPU, Speicher und Protokollierung.
Kostenloser TarifKosten nach NutzungMesswerte als Grundlage
OpenID-Zertifizierung
Zertifizierte Profile.
Authrim v0.4.0
28 Profile in 7 Kategorien
Die Kategorien verlinken auf die offiziellen Verzeichnisse.
Erproben Sie eine quelloffene Identitätsplattform für Cloudflare Workers. Die Kernprotokolle sind implementiert; die Absicherung für den Produktivbetrieb läuft weiter.
