TL;DR / Key Takeaways
Die goldenen Handschellen des verwalteten Authentifizierungsmechanismus
Verwaltete Identität klingt nach einer Abkürzung, bis die Rechnung kommt. Dienste wie Auth0 und Okta berechnen pro monatlich aktiven Nutzer, sodass ein Produkt, das von 10.000 auf 100.000 Nutzer ansteigt, seine Authentifizierungskosten von Hunderten auf Zehntausende von Dollar pro Monat steigen sehen kann. Für B2C-Apps mit schwankendem Traffic wird dieser MAU-Zähler zu einer Belastung für das Wachstum anstatt zu einer vorhersehbaren Posten.
Die Abhängigkeit von Anbietern verstärkt das Problem. Sobald Sie Ihre Anmeldeabläufe, Regeln und Benutzer-Metadaten in eine proprietäre Regel-Engine integriert haben, sieht der Wechsel äußerst schmerzhaft aus, nahezu wie eine Herzoperation. Individuelle Aktionen, proprietäre Tokens und gehostete Anmeldeseiten treiben die Teams dazu, weiter zu zahlen, anstatt die grundlegende Authentifizierungslogik zu überarbeiten.
Streng kontrollierte Ökosysteme versprechen Sicherheit, bieten jedoch oft Starrheit. Viele Anbieter zwingen Sie durch ihre gehosteten Benutzeroberflächen, ihre SDKs und ihre vorgefertigten Abläufe, wodurch selbst einfache Anpassungen – wie das Hinzufügen eines neuen Verifizierungsschrittes oder die Unterstützung eines ungewöhnlichen Legacy-SSO – wie ein Kampf gegen die Plattform wirken. Wenn Sie eine nicht standardisierte Anmeldereise benötigen, erkennen Sie, wie wenig Spielraum Sie tatsächlich haben.
Datenbesitz fügt eine weitere Ebene des Unbehagens hinzu. Benutzeridentitäten, Sitzungen und Prüfprotokolle befinden sich in der Cloud eines anderen, die von intransparenten internen Richtlinien und Ratenlimits geregelt wird. Export-APIs sind vorhanden, bieten jedoch selten eine umfassende Kontrolle über Schemata, Indizes oder wie lange Daten tatsächlich in Backups gespeichert bleiben.
Für Startups in regulierten Branchen prallen diese Einschränkungen schnell auf die Realität. Strenge Datenresidenzregeln in der EU, im Gesundheitswesen oder im Fintech-Bereich verlangen oft, dass Benutzertabellen in einer bestimmten Region oder sogar in einem bestimmten Datenbank-Cluster gespeichert werden. Wenn die Antwort Ihres Anbieters "unser Fahrplan" oder eine Region nur für Unternehmen ist, beginnt Ihr Compliance-Team sich zu fragen, warum die Authentifizierung überhaupt ausgelagert wird.
Entwickler reagieren, indem sie mehr Kontrolle, mehr Transparenz und die Fähigkeit verlangen, den gesamten Stack selbst zu verwalten. Open-Source-Systeme wie Ory Kratos kehren das Modell um: Sie betreiben den Identitätsserver selbst, definieren Ihre eigenen Schemata und behalten die Benutzerdaten in Ihrer eigenen Datenbank. Verwaltete Authentifizierung hat weiterhin ihren Platz – aber die goldenen Handschellen fühlen sich zunehmend enger an.
Lerne Kratos kennen: Dein selbstgehosteter Identitätsserver
Verwaltete Authentifizierungsplattformen wollen Ihr Alleskönner sein. Ory Kratos möchte lediglich Ihre Identitäts-Engine sein. Es wird als API-first, backend-only Identitätsserver bereitgestellt, der hinter jeglicher Benutzeroberfläche, Framework oder Gerät sitzt, das Sie verwenden – Next.js, mobile Anwendungen, SPAs, sogar legacy Monolithen – ohne Sie in ein proprietäres Widget oder Dashboard zu zwingen.
Kratos stellt jede wichtige Authentifizierungsoperation über HTTP-APIs bereit: Registrierung, Login, Profilverwaltung, Wiederherstellung und Einstellungen. Ihre Frontend-Anwendung muss niemals Passwortlogik speichern oder magische Links erstellen; sie orchestriert lediglich die Flows, die Kratos definiert und sichert. Diese Trennung lässt die Authentifizierung wie jeden anderen internen Mikrodienst wirken, nicht wie ein undurchsichtiges SaaS-Produkt.
Von Haus aus verarbeitet Kratos die grundlegenden Abläufe, die die meisten Apps schlecht neu erstellen. Sie erhalten die Benutzerregistrierung mit schema-basierter Validierung, passwortbasiertem Login und optionaler Multi-Faktor-Authentifizierung (MFA) für risikobehaftete Konten. Es verwaltet auch die E-Mail-Verifizierung, die Kontenaktivierung und eine robuste Sitzungsverwaltung, einschließlich Sitzungswiderruf und -rotation.
Flows verhalten sich wie Zustandsmaschinen, die Sie über Konfiguration steuern. Sie können festlegen, wo Benutzer nach der Registrierung landen, welche Felder sie ausfüllen müssen und wie Wiederherstellungs- oder Verifikationslinks funktionieren. Für die meisten Apps bedeutet das, dass kein benutzerdefinierter Glue-Code für „Passwort vergessen“, „E-Mail verifizieren“ oder „Profil aktualisieren“ erforderlich ist, außer um die Benutzeroberfläche zu verbinden.
Selbstgehostet durch Design läuft Kratos überall, wo Docker läuft: auf einem Laptop, einem Kubernetes-Cluster oder einem Bare-Metal-Server im Schrank. Der offizielle Schnellstart verwendet eine einzelne `docker-compose`-Datei, aber dasselbe Container-Image skaliert für Mehrknotenbereitstellungen. Kein Regionen-Lock, kein erzwungener Migrationspfad, keine undurchsichtigen Wartungsfenster.
Die Speicherung bleibt unter Ihrer Kontrolle. Kratos unterstützt Datenbanken wie SQLite für die lokale Entwicklung und PostgreSQL für die Produktion, verbunden über einen einfachen DSN in seiner YAML-Konfiguration. Sie besitzen die Benutzertabelle, das Audit-Protokoll und die Backups, was wichtig für die DSGVO, SOC 2 und Kunden ist, die fragen: „Wo genau wird meine Daten gespeichert?“
Self-Hosting beseitigt auch die Angst vor der MAU-basierten Preisgestaltung. Anstatt Auth0 oder Okta jedes Mal zu bezahlen, wenn Ihre Benutzerzahlen ansteigen, zahlen Sie für CPU, RAM und Speicherplatz. Wenn Sie später eine Social-Login-Funktion, OAuth2 oder erweiterte Berechtigungen benötigen, integriert sich Kratos nahtlos in den größeren Ory-Stack, ohne dass eine Plattform-Neuschreibung erforderlich ist.
Kratos vs. Auth0: Ein Kopf-an-Kopf-Duell
Verwaltete Identität sieht ganz anders aus, wenn man sich die Bereitstellung genauer anschaut. Ory Kratos wird als Docker-natives Service geliefert, das Sie überall dort betreiben können, wo Sie möchten – in Ihrem Kubernetes-Cluster, auf einer Bare-Metal-Maschine oder auf einem günstigen VPS. Auth0 hingegen existiert hauptsächlich als vollständig verwaltetes SaaS, bei dem Infrastruktur, Skalierung und Upgrades hinter einem Dashboard und APIs abstrahiert sind.
Dieser Split ist wichtig, wenn Sie Kontrolle benötigen. Mit Kratos sitzt Ihr Auth-Stack innerhalb Ihres Netzwerkperimeters, neben Ihrer App und Ihren Datenbanken, eingebunden in Ihre bestehende Observability und CI/CD. Auth0 bietet Ihnen eine raffinierte Cloud-Konsole und SLAs, aber Sie akzeptieren dafür deren Regionen, Rollout-Kadenz und intransparente Leistungsoptimierung.
Die Kostenmodelle divergieren ebenso stark. Auth0preise basieren auf monatlich aktiven Nutzern und schränken Funktionen sowie Mandanten hinter Abonnement-Stufen ein, die ansteigen können, wenn die Anmeldungen sprunghaft ansteigen oder inaktive Nutzer vorübergehend zurückkehren. Kratos ist Open Source: Sie zahlen für Rechenleistung, Speicher und Betriebszeit, nicht für eine Miete pro Identität.
Für Produkte mit schwankendem oder saisonalem Verkehr – denken Sie an Gaming-Starts, Ticketplattformen oder Bildungstools während der Prüfungszeit – verwandelt sich die MAU-Preisgestaltung in eine Volatilitätssteuer. Ein selbstgehosteter Kratos-Cluster kann ruhig mit minimalen Ressourcen betrieben werden und bei Bedarf horizontal skalieren, ohne eine überraschende Rechnung, die an das Nutzerverhalten geknüpft ist. Sie tauschen vorhersehbare Infrastrukturkosten gegen unvorhersehbare SaaS-Kosten.
Flexibilität ist der Bereich, in dem Kratos am stärksten auf sein API-first Design setzt. Jeder Ablauf – Registrierung, Anmeldung, Wiederherstellung, Verifizierung, MFA – bietet JSON-APIs, die von jedem Client aufgerufen werden können, sei es eine Next.js SPA, eine native Mobilanwendung oder eine CLI. Identitätsschemata leben in der Konfiguration, sodass Sie Merkmale wie Unternehmens-IDs, benutzerdefinierte Rollen oder regionale Flags definieren können, ohne auf die Genehmigung eines Anbieters für Ihren Anwendungsfall warten zu müssen.
Auth0 bietet ein enormes Katalog an vorgefertigten Integrationen und Regeln, aber diese sind mit Einschränkungen verbunden. Sie integrieren sich in ihre „universellen Anmeldeseiten“, ihre Auslöseaktionen und ihr Mandantenmodell. Tiefgreifende, nicht standardisierte Abläufe – wie progressive Profilierung, Multi-Tenant B2B mit benutzerdefinierter Weiterleitung oder komplexe Richtlinien pro Organisation – erfordern oft Umgehungslösungen oder instabilen Klebercode.
Kratos fügt sich in einen modularen Stapel ein: Kombinieren Sie es mit Hydra für OAuth2/OIDC, Keto für Berechtigungen, Oathkeeper als identitätsbewussten Proxy und Ory Elements für sofort einsatzbereite UI-Komponenten. Auth0 bündelt viele dieser Funktionen hinter einer Marke, verstärkt jedoch auch die Abhängigkeit von einem Anbieter. Für Teams, die ihre Infrastruktur selbst verwalten möchten, liest sich Ory Kratos - Dokumentation weniger wie Produktmarketing und mehr wie ein Bauplan für ein Authentifizierungssystem, das sie tatsächlich kontrollieren.
Das vollständige Ory-Ökosystem: Über die grundlegende Anmeldung hinaus
Kratos sitzt im Zentrum von etwas Größerem: einem modularen Ory-Stack, der versucht, das, was Plattformen wie Auth0 und Okta als eine undurchsichtige Box verkaufen, aufzubrechen. Anstelle eines Monolithen teilt Ory Identität in spezialisierte Dienste auf, die Sie unabhängig betreiben, skalieren und austauschen können. Kratos verwaltet Identitäten und Sitzungen, überträgt jedoch Tokens, Berechtigungen und die Durchsetzung an der Edge an seine Geschwister.
Für OAuth2 und OpenID Connect kommt Ory Hydra ins Spiel. Hydra fungiert als Ihr Autorisierungsserver und gibt OAuth2-Zugriffstoken und OIDC-ID-Tokens aus, die von standardkonformen Clients bereits verstanden werden. Sie verbinden Kratos als Anmeldedienst, und lassen Sie Hydra die Einwilligungsflüsse, Token-Lebensdauern und Client-Registrierungen über Web-, Mobile- und Maschine-zu-Maschine-Arbeitslasten verwalten.
Feinkörnige Autorisierung stammt von Ory Keto, das eine beziehungsbasierte Zugangskontrolle im Stil von Google Zanzibar implementiert. Anstatt Rollen im Anwendungslogik fest zu codieren, modellierst du Beziehungen wie "Benutzer X kann Dokument Y bearbeiten" und fragst Keto nach Entscheidungen. Dieses Muster skaliert von einfachen RBAC zu komplexen, mehrmandantenfähigen Konfigurationen, in denen sich tausende von Berechtigungen jede Minute ändern.
Am Rande sitzend, fungiert Ory Oathkeeper als identitätsbewusster Proxy vor Ihren APIs und Diensten. Oathkeeper validiert Tokens von Hydra, ruft Identitätseigenschaften von Kratos ab und setzt Zugriffsregeln durch, die an Keto delegiert werden können, um das endgültige Ja/Nein zu bestimmen. Sie definieren Regeln als Konfiguration, nicht als Code, sodass Sie Richtlinien aktualisieren können, ohne Ihre App neu bereitzustellen.
Kombinieren Sie sie und Sie erhalten eine Full-Stack-Alternative zu Unternehmenslösungen: Kratos für Identitäten, Hydra für OAuth2/OIDC, Keto für die Autorisierung und Oathkeeper als Torwächter. Jedes läuft als Container, kommuniziert über HTTP/JSON und bleibt Open Source, sodass Sie auf Bare Metal, Kubernetes oder einer einzelnen Docker Compose-Datei bereitstellen können. Anstatt pro monatlich aktiven Nutzer zu bezahlen, zahlen Sie für die Infrastruktur und behalten jedes Element Ihrer Authentifizierungspipeline unter Kontrolle.
Von Null zu Login: Ihre erste Kratos-Einrichtung
Das Starten von Ory Kratos von Grund auf erfolgt über Docker, nicht über ein Web-Dashboard. Sie erstellen einen Ordner `kratos-demo`, navigieren in ein Unterverzeichnis `docker` und konfigurieren eine `docker-compose.yml`, die das offizielle Ory Kratos-Image zieht, eine lokale `users.db` SQLite-Datei einbindet und eine `config/kratos.yml` sowie ein `identity.schema.json` bindet. Nach einem `docker compose up` startet Kratos im Entwicklungsmodus und stellt seine öffentlichen und administrativen APIs auf localhost zur Verfügung.
Die `docker-compose.yml` spiegelt weitgehend die offizielle quickstart.yml wider, ist jedoch für ein Laptop optimiert. Die Datei setzt `KRATOS_PUBLIC_URL` und `KRATOS_BROWSER_URL` auf `http://localhost:4433` und `http://localhost:4455`, bindet das Konfigurationsverzeichnis und verknüpft einen Mailserver-Container für Bestätigungs-E-Mails. Die Ports bleiben auf den Standardwerten – 4433 für öffentlich und 4434 für Admin – sodass jeder Beispiel-Client-Code aus den Dokumentationen unverändert funktioniert.
Die Konfiguration geht dann zu zwei Kern-Dateien über: `kratos.yml` und dem Identitätsschema-JSON. Das Identitätsschema, das von email-password/identity.schema.json kopiert wurde, definiert ein JSON-Schema mit Attributen wie `email`, `first_name` und `last_name`, sowie Passwortanmeldeinformationen. Sie können es mit benutzerdefinierten Feldern wie Unternehmens-IDs, Rollen oder Funktionsflaggen erweitern, ohne den Kern von Kratos zu berühren.
Die Datei `kratos.yml` verbindet alles miteinander. Sie weisen `selfservice.default_browser_return_url` und erlaubte Ursprünge auf Ihre Next.js-App unter `http://localhost:3000` zu und stellen zulässige HTTP-Methoden sowie CORS-Header auf die Whitelist. Jeder Flow – `login`, `registration`, `recovery`, `verification`, `settings` – erhält eine `ui_url`, die direkt auf eine Frontend-Route wie `/auth/login` oder `/auth/register` verweist.
Secrets und E-Mail-Einstellungen befinden sich im selben YAML. Demokonfigurationen verwenden Platzhalter für Secrets, aber Produktionskonfigurationen müssen starke Schlüssel für `secrets.cookie` und `secrets.cipher` rotieren. SMTP-Anmeldeinformationen konfigurieren den Mailserver, damit Kratos Verifizierungs- und Wiederherstellungslinks versenden kann, die die Benutzer dann zurück zu denselben `ui_url`-Routen leiten.
Im Frontend verbindet eine Next.js-App mit Kratos über `@ory/nextjs` und Ory Elements. Umgebungsvariablen wie `NEXT_PUBLIC_KRATOS_PUBLIC_URL=http://localhost:4433` und `KRATOS_BROWSER_URL=http://localhost:4455` kommen in die `.env.local`, die den Docker-URLs entsprechen. Eine kleine `ory.config.ts` verbindet das SDK mit diesen Endpunkten.
Next.js-Middleware übernimmt die schwere Arbeit zur Laufzeit. Eine `middleware.ts`-Datei interceptiert Anfragen, ruft die Sitzungs-API von Kratos auf und lässt entweder authentifizierte Benutzer passieren oder leitet anonyme Besucher in den kratos-gesteuerten Anmeldefluss weiter. Damit erhalten Sie vollständig integrierte Bildschirme für Registrierung, Anmeldung, E-Mail-Verifizierung und MFA, die auf Ihrem eigenen Stack laufen, nicht auf dem von Okta oder Auth0.
Die Benutzeroberfläche entpacken: Wie Ory Elements Ihnen Wochen spart
Verwaltete Identitätsstacks zerfallen normalerweise an der Frontend-Seite. Entweder gibt man sich mit einem gehosteten Anmeldefenster eines Anbieters zufrieden, oder man investiert Tage in die Verdrahtung von Formularzustand, Validierung und Fehlerbehandlung für jeden Authentifizierungsrandfall. Ory Elements existiert speziell, um diesen Aufwand zu beseitigen.
Statt ein einzelnes Widget zu versenden, ist Elements eine vollständige UI-Komponentenbibliothek für React, Next.js (einschließlich des App Routers) und andere moderne Frameworks. Du installierst es wie jedes andere npm-Paket, fügst seine Komponenten in deine Routen ein und verlinkst sie zu deinem Ory Kratos-Öffentlichen Endpunkt.
Der Trick: Elements kodiert nicht fest, wie ein „Anmeldeformular“ aussieht. Kratos stellt jeden Prozess—Anmeldung, Registrierung, Wiederherstellung, Einstellungen, Verifizierung—als ein JSON-Schema zur Verfügung, das Felder, Methoden, CSRF-Tokens und Nachrichten beschreibt. Elements liest dieses Schema zur Laufzeit und rendert automatisch die richtige Benutzeroberfläche.
Rufe die Anmeldestrecke in der Demo Next.js-App auf, und Elements holt den Anmeldefluss von Kratos und erstellt dann das Formular: E-Mail-Feld, Passwortfeld, Absenden-Button, Validierungsnachrichten sowie alle zusätzlichen Eigenschaften, die du in deinem Identitätsschema definiert hast. Schalte die Mehrfaktorauthentifizierung ein oder füge ein Benutzernamenfeld in Kratos hinzu, und die gerenderte Benutzeroberfläche aktualisiert sich ohne Front-End-Neuschreibungen.
Dieses dynamische Verhalten gilt für alle Ströme. Out of the box kann Elements Folgendes rendern: - Anmelden und Registrieren - Kontoeinstellungen und Profilverwaltung - Passwortwiederherstellung und E-Mail-Verifizierung - MFA-Registrierung und Herausforderungsbildschirme
Entwickler erhalten die volle Kontrolle über die Präsentation. Komponenten werden ungestylt oder leicht gestylt geliefert, sodass Sie sie in Ihr eigenes Layout einfügen, Tailwind oder CSS-Module anwenden und jeden Bildschirm branden können, ohne die Logik neu implementieren zu müssen. Sie behalten Ihr Designsystem, während Sie die komplexen Protokolldetails auslagern.
Zeitersparnisse kumulieren sich schnell. Ein typisches Team könnte 1–2 Wochen damit verbringen, Authentifizierungsformulare zu erstellen und zu optimieren, und dann noch mehr Zeit damit, sie angesichts sich ändernder Anforderungen zu pflegen. Mit Elements reduziert sich das meiste darauf, einige Routen und Umgebungsvariablen zu verbinden, wie die Better Stack-Demo zeigt.
Für tiefere Anpassungen – wie das Ändern von Identitätseigenschaften, Abläufen oder Sicherheitsrichtlinien – passen Sie Kratos selbst an. Die offiziellen Ory Kratos-Dokumente zeigen, wie diese Backend-Änderungen automatisch in Ihre von Elements unterstützte Benutzeroberfläche umgesetzt werden.
Sicherheit, die integriert und nicht aufgesetzt ist
Sicherheit steht im Mittelpunkt von Ory Kratos und ist nicht als nachträglicher Gedanke hinzugefügt. Von Haus aus überprüft Kratos jedes Passwort durch das massive Datenarchiv von Have I Been Pwned und lehnt Anmeldeinformationen ab, die bereits in echten Datenleaks aufgetaucht sind. Diese Überprüfung allein verhindert stillschweigend ganze Klassen von Account-Übernahmeversuchen, die auf der Wiederverwendung von Passwörtern basieren.
Kratos integriert zudem Ratenbegrenzung, Sitzungsabsicherung und CSRF-Schutz, sodass Sie diese nicht in Middleware neu erfinden müssen. Passwortrichtlinien, Sitzungszeiten und Multi-Faktor-Authentifizierung befinden sich in der Konfiguration und sind nicht über Controller und Plugins verstreut. Sie erhalten eine konsistente Sicherheitsstrategie für Web-, Mobile- und API-Clients, da alles durch denselben API-first-Engine fließt.
Anstelle von ad-hoc „Best Practices“ verfolgt Kratos Richtlinien von NIST, der IETF und großen Forschungsgruppen bei Microsoft und Google. Das bedeutet Unterstützung für moderne Hash-Algorithmen, Transport-Sicherheitsstandards, die TLS überall bevorzugen, und Anmeldeabläufe, die Antimuster wie willkürliche Komplexitätsregeln für Passwörter vermeiden. Die Projektverantwortlichen beziehen sich ausdrücklich auf Arbeiten von Troy Hunt und anderen zur benutzbaren Sicherheit, sodass die Standardwerte auf „sicher und menschenfreundlich“ und nicht auf „sicher und feindselig“ ausgerichtet sind.
Compliance-Teams kümmern sich weniger um Schlagwörter und mehr um Kontrolle, und das selbstgehostete Kratos bietet Ihnen das von Haus aus. Benutzeridentitäten, Sitzungen und Prüfprotokolle liegen in Ihrer eigenen Datenbank, in Ihrer eigenen Region, unter Ihren eigenen Aufbewahrungsrichtlinien. Sie wählen die Cloud, die Verschlüsselung im Ruhezustand, die Backup-Strategie und die Datenresidenzgeschichte, die zu Ihren Regulierungsanforderungen passt, nicht zu einem gemeinsamen SaaS-Cluster eines Anbieters.
Für die DSGVO bedeutet diese Kontrolle praktische Vorteile. Datenverarbeitungsverträge werden einfacher, wenn Sie der Verarbeiter sind und nicht nur ein Mieter in jemandes Auth-Silo. Das Recht auf Löschung, Datenexport und Zweckbindung werden zu Implementierungsdetails in Ihrem eigenen System, anstatt Supportanfragen bei einem Drittanbieter zu sein.
Auth0 und Okta können so konfiguriert werden, dass sie ähnliche Standards erfüllen, aber Sie arbeiten immer innerhalb ihrer Vorgaben. Mit Ory Kratos sind diese Vorgaben Ihre eigenen Richtlinien, die als Code und Konfiguration ausgedrückt und zusammen mit dem Rest Ihrer Infrastruktur geprüft werden.
Next-Level Funktionen: 2FA in wenigen Minuten
Multi-Faktor-Authentifizierung bedeutet in der Regel, mit SDKs, QR-Code-Bibliotheken und einer benutzerdefinierten Einstellungen-Oberfläche zu jonglieren. Mit Ory Kratos setzen Sie einfach ein paar Flags in einer YAML-Datei, und plötzlich spricht Ihre Anwendung TOTP wie ein erfahrenes Sicherheitsprodukt. Kratos macht den gesamten 2FA-Flow über seine API zugänglich, sodass Ihr Backend sauber bleibt und Ihr Frontend keine maßgeschneiderte Sicherheitsarchitektur benötigt.
Aktivieren Sie TOTP in der Kratos-Konfiguration, und der Server fügt sofort einen neuen Abschnitt „2FA“ zu den Identitätsflüssen hinzu. Wenn sich ein Benutzer anmeldet, generiert Kratos ein Geheimnis, kodiert es als `otpauth://` URI und gibt ein fertig gerendertes QR-Code-Payload zurück. Ihre App greift nicht direkt auf das Geheimnis zu; Kratos speichert und verschlüsselt es und zwingt dann zur Verifizierung bei jedem folgenden Login.
Die Next.js-Demo des Videos zeigt, wie Ory Elements diese Backend-Funktionalität in einen vollständig verwalteten Einstellungsbildschirm verwandelt. Platzieren Sie die Elements-Komponenten in einer `/settings`-Route, verweisen Sie auf Ihre öffentliche Kratos-URL, und Sie erhalten ein Live-Nutzer-Dashboard ohne zusätzliche React-Zustandsmaschinen. Benutzer können:
- 1Profilmerkmale aktualisieren (E-Mail, Vorname, Nachname)
- 2Ändern Sie ihr Passwort
- 3Aktivieren oder Deaktivieren der TOTP-basierten Zwei-Faktor-Authentifizierung (2FA)
All dies wird von Elements als vorgefertigte, zugängliche Komponenten versendet, die über typisierte Flows mit Kratos kommunizieren. Sie verbinden keine benutzerdefinierten Formulare mit willkürlichen Endpunkten; Sie rendern ein deklaratives Formularmodell, das Kratos zur Laufzeit definiert. Wenn Kratos ein Feld hinzufügt oder ändert, aktualisiert sich die Benutzeroberfläche automatisch.
Während der Einrichtung der Zwei-Faktor-Authentifizierung führt Kratos den Benutzer durch das Scannen des QR-Codes und die Verifizierung des ersten Codes. Der Server validiert das TOTP gegen das gespeicherte Geheimnis, berücksichtigt Zeitabweichungen und kennzeichnet den zweiten Faktor als aktiv im Identitätsdatensatz. Wenn sich Benutzer erneut anmelden, aktualisiert Kratos die Sitzung von einer Einzelfaktor- auf eine Multifaktor-Authentifizierung, jedoch erst nach einem gültigen TOTP, und Ihre App liest einfach den resultierenden Sitzungsstatus aus.
Diese Trennung der Aufgaben ist entscheidend: Kratos kümmert sich um die QR-Generierung, die sichere Speicherung von Geheimnissen und die TOTP-Überprüfung; Ory Elements verantwortet das Nutzererlebnis. Ihre App nutzt einfach eine sichere, vollständig verwaltete MFA-Pipeline, die Sie in wenigen Minuten anstelle von Wochen einrichten können.
Das Entwicklerurteil: Wer sollte Kratos nutzen?
Verwaltete Identitätsplattformen ziehen ständig Entwickler auf Hacker News an, und Ory Kratos wird in diesen Threads als die "Ich wünschte, wir hätten damit begonnen" Option erwähnt. Kommentatoren heben durchweg sein API-first Design, die klaren HTTP-Flows und die Tatsache hervor, dass man es überall dort betreiben kann, wo Docker läuft – von einem 5-Dollar-VPS bis hin zu Kubernetes. Für Startups, die sich mit Auth0 oder Okta-Angeboten auseinandersetzen, die mit MAUs skalieren, ist der Reiz offensichtlich: vorhersehbare Infrastrukturkosten, keine Nutzungskosten pro Nutzer und keine proprietäre Regeln-Engine, die später aufgelöst werden muss.
Kratos eignet sich am besten, wenn Authentifizierung ein zentraler Bestandteil des Produkts ist und nicht nur eine Checkbox. Teams, die Multi-Tenant-SaaS, datenschutzempfindliche Apps oder regulierte Workloads entwickeln, erhalten die volle Kontrolle über Identitätsdaten, Schemas und Lebenszyklen. Sie besitzen die Datenbank, definieren das JSON-Identitätsschema und entscheiden, wie Sie die Abläufe in Ihre React-, Next.js- oder nativen Clients über Ory Elements oder Ihre eigene Benutzeroberfläche integrieren.
Ideale Projekte weisen normalerweise einige Gemeinsamkeiten auf: - Bedarf an tiefgreifender Anpassung der Registrierungs-, Wiederherstellungs- und Einstellungsabläufe - Anforderungen an Datenresidenz, GDPR oder interne Prüfungsfähigkeit - Langfristiger Plan, OAuth2, SSO und fein granulare Berechtigungen mit Ory Hydra, Keto und Oathkeeper hinzuzufügen
Diese modulare Architektur ist genau das, was Entwickler überzeugt, die von „einem umfassenden Identitätsprodukt“-Plattformen enttäuscht wurden. Sie können mit E-Mail/Passwort plus TOTP beginnen und später soziale Logins oder unternehmensweites SSO hinzufügen, ohne alles neu schreiben zu müssen. Der Ory Dokumentationshub setzt auf dieses Konzept mit separaten Anleitungen für jeden Dienst anstelle eines monolithischen Einrichtungsassistenten.
Trade-offs sind realistisch, und die Threads auf Hacker News beschönigen sie nicht. Kratos zu betreiben bedeutet, Docker-Images, Konfigurationen, Migrationen, SMTP, Monitoring und Incident Response zu verwalten. Sie ersetzen eine SaaS-Rechnung durch operationale Aufwendungen: Terraform-Module, CI-Pipelines, Protokollaggregation und Bereitschaftsdienste.
Ingenieurgeführte Organisationen betrachten dies oft als fairen Austausch. Wenn Sie bereits PostgreSQL, Redis und ein Service Mesh betreiben, ist das Hinzufügen eines weiteren Go-Dienstes Lärm, aber kein Chaos. Für ein zweiköpfiges Team, das eine Marketing-Website mit Login bereitstellt, kann ein vollständig verwalteter Dienst jedoch immer noch schneller sein, selbst wenn die Auth0-Rechnung später schmerzt.
Kratos ist eine bewusste Entscheidung. Sie kaufen Freiheit von Anbieterbindung zu dem Preis, Ihre eigene Identitätsinfrastruktur zu betreiben – und für einen wachsenden Teil der Entwickler sieht dieses Angebot endlich gut aus.
Deine Auth, Deine Regeln: Die endgültige Erkenntnis
Kontrolle definiert moderne Infrastruktur, und Ory Kratos zeigt, wie Kontrolle über Identität tatsächlich aussieht. Anstatt deine Anmeldemaske von Auth0 oder Okta zu mieten und zu hoffen, dass die Preise bei deinem nächsten Traffic-Anstieg nicht steigen, betreibst du deinen eigenen Identitätsserver, versendest ihn in Docker und integrierst ihn in jeden Stack – Next.js, React, Go, wie du willst. Authenticator wird nicht mehr zu einer Black Box, sondern zu regulärem Anwendungs-Code.
Kratos ändert das Spiel im Hinblick auf die Abhängigkeit von SaaS. Sie erhalten eine API-first-Engine, die Registrierung, Anmeldung, Wiederherstellung, E-Mail-Verifizierung und MFA verwaltet und dabei unabhängig von UI- und Frontend-Frameworks bleibt. Benötigen Sie OAuth2, feingranulare Berechtigungen oder einen identitätsbewussten Proxy? Sie integrieren Hydra, Keto oder Oathkeeper, wenn Sie sie tatsächlich benötigen, anstatt eine Alles-oder-Nichts-Plattform zu kaufen.
Auch die Kostenstruktur ändert sich. Die verwalteten Auth-Kosten richten sich nach den MAUs und Funktionen; ein plötzlicher Anstieg von 10.000 auf 100.000 Nutzer kann zu einer fünfstelligen Überraschung führen. Kratos ist Open Source, daher sind Ihre Hauptkosten Rechenleistung, Speicher und Betriebszeit, und Sie können es auf allem von einem 5-Dollar-VPS bis hin zu Kubernetes in mehreren Regionen selbst hosten.
Die Entwicklererfahrung bleibt erstklassig. Ory Elements bietet Ihnen vorgefertigte React/Next.js-Komponenten, sodass Sie funktionierende Anmelde-, Registrierungs- und Einstellungsabläufe in Stunden statt in Wochen erstellen können. Die Quickstart-Docker-Compose-Datei, das Beispiel für ein Identitätsschema und die Next.js-Beispielanwendung ermöglichen es Ihnen, von null zu einem funktionierenden Stack mit E-Mail-Verifizierung und TOTP-gestützter 2FA an einem Nachmittag zu gelangen.
Es geht weniger darum, einen Auth-Anbieter gegen einen anderen auszutauschen, sondern vielmehr darum, zu entscheiden, wer deine Identitätsebene besitzt. Wenn du ein neues SaaS-Produkt startest, ein Monolith umstrukturierst oder versuchst, der Preisüberraschung von Auth0 zu entkommen, plane dir einen Tag ein und verbinde Kratos. Prüfe deine aktuelle Authentifizierung: Preisgestaltung, Abhängigkeiten, Exportmöglichkeiten und Flexibilität. Entschließe dich dann, ob dein nächstes Projekt auf dem Fahrplan eines anderen laufen soll – oder auf deinem eigenen.
Häufig gestellte Fragen
Was ist Ory Kratos?
Ory Kratos ist ein Open-Source-Server für Identitäts- und Benutzermanagement mit API-First-Ansatz. Er bewältigt die grundlegenden Authentifizierungsabläufe wie Registrierung, Anmeldung, MFA und Kontowiederherstellung, sodass Entwickler ihre Authentifizierungsinfrastruktur selbst hosten und die volle Kontrolle darüber behalten können.
Ist Ory Kratos komplett kostenlos?
Ja, die Kernsoftware Ory Kratos ist Open Source und kostenlos selbst zu hosten. Ory bietet auch eine kostenpflichtige Unternehmenslizenz und einen verwalteten Cloud-Service (Ory Network) an, die zusätzliche Funktionen wie hohe Verfügbarkeit, SLAs und dedizierten Support bieten.
Wie schneidet Ory Kratos im Vergleich zu Auth0 ab?
Kratos bietet größere Flexibilität, Kontrolle und Kosten-Effizienz durch sein selbst gehostetes, Open-Source-Modell. Auth0 ist ein vollständig verwalteter Dienst, der eine schnellere Einrichtung und umfangreiche vorgefertigte Integrationen ermöglicht, jedoch mit Anbietersperre und potenziell höheren Kosten einhergeht.
Kann ich meine bestehenden Benutzer von Auth0 zu Ory Kratos migrieren?
Ja, Ory bietet Dokumentationen und Anleitungen zur Migration einer bestehenden Benutzerbasis von Plattformen wie Auth0 zu Kratos, was einen reibungsloseren Übergang ermöglicht.