[ AUTH & IDENTITÄT ]
Auth, die du nicht bauen musst — auf einer Datenbank, die dir schon gehört.
Sessions, Passkeys, zweiter Faktor, SSO, Organisationen und rollenbasierte Rechte als ein Modul für Nuxt und Elysia. Die Nutzertabelle liegt in deinem PostgreSQL — wir halten keine Kopie.
Closed Beta bereits produktiv bei ausgewählten PartnernAuf better-auth gebaut erweitert, nicht geforktIm Scale-Plan enthalten CHF 99 im Monat
Wir setzen es ein, bevor wir es verkaufen.
Jedes Produkt, das wir betreiben, meldet seine Nutzer über dieses Modul an — unser eigenes SaaS, die Kundenplattformen, das Backoffice hinter dieser Website. Kein Proof of Concept: das Ding, das wir selbst reparieren, wenn es um zwei Uhr nachts kaputtgeht.
- Deine Datenbank, nicht unsere
- Das Modul schreibt in dein PostgreSQL. Kein JAMflow-Dienst hält eine zweite Kopie deiner Nutzer.
- Ein Modul statt fünf Integrationen
- Sessions, Provider, Organisationen, Einladungen und Rechte kommen zusammen und kennen einander bereits.
- Wer es gebaut hat, beantwortet das Ticket
- Du triffst auf einen Randfall und sprichst mit dem Team, das das Modul geschrieben hat, nicht mit einem Integrator, der die README liest.
Was ankommt, Zeile für Zeile.
Das Modul ist better-auth, schon verdrahtet: Was better-auth kann, kann es auch — mit unserer Rechteebene und den operativen Teilen obendrauf. Alles Folgende kommt fertig konfiguriert, ausser wo die Zeile auf Anfrage sagt.
Wege hinein
- E-Mail und Passwort, mit einem Reset, der alle offenen Sessions beendet
- Magic Links — einmalig, kurzlebig, nur als Hash gespeichert
- Passkeys über WebAuthn
- Zweiter Faktor per Einmalcode
- Social- und Unternehmens-Login über OIDC und OAuth2
Teams, Rollen und Protokoll
- Organisationen, Mitglieder und Einladungen mit Ablauf
- Rollen pro Organisation, deklariert je Ressource und Aktion
- Plattformrollen, die über jedem Tenant aufgelöst werden
- Impersonation für den Support, aus der Plattformebene
- Ein Append-only-Protokoll, per Hash verkettet und prüfbar
Isolation und Limits
- Ein Schema, Scoping vom Framework erzwungen
- Ein PostgreSQL-Schema pro Tenantauf Anfrage
- Eine eigene Datenbankauf Anfrage
- Rate Limiting auf den Auth-Routen, auf Redis, über alle Replicas geteilt
Autorisierung
Rollen, die zu deinem Produkt passen — nicht zur Vorstellung einer Library.
Deine Rollen gehören nicht in eine Tabellenkalkulation. Ein echtes Produkt hat Inhaber, Rechnungsverantwortliche, Support-Leute und Gäste mit Leserecht — und dieselbe Person ist in einer Organisation Inhaberin und in der nächsten nur Zuschauerin. Du deklarierst das einmal; die Prüfung ist ein Aufruf.
bis zu 50%
weniger Datenbank-Roundtrips pro geschützter Anfrage
Eine Rechteprüfung kostet normalerweise eine Query: die Regel lesen, dann die Arbeit tun. Hier kommt es aus der Session, die die Anfrage schon mitbringt: aus zwei Roundtrips wird einer. Arithmetik, kein Benchmark — was es spart, hängt davon ab, was die Anfrage sonst liest.
- Plattformrollen werden zuerst aufgelöst
- Support und Betrieb bekommen eine eigene Ebene über den Tenants, damit niemand zum Organisations-Admin gemacht wird, nur um ein Ticket zu beantworten.
- Ein Vokabular, Server und Oberfläche
- Dieselbe Datei importieren der Guard und die Oberfläche, ein Button und die Route dahinter können sich also nicht darüber uneinig sein, wer ihn drücken darf.
shared/permissions.ts
// One vocabulary, imported by the server and by the UIexport const org = createAccessControl({ ...defaultStatements, projects: ['read', 'update'], billing: ['read', 'update'], domains: ['read', 'create', 'update', 'delete'],}) export const member = org.newRole({ projects: ['read'], billing: ['read'],}) // A handler states both vocabularies; the platform one is tried firstawait requireResolvedPermission(event, { globalPermissions: { projects: ['update'] }, organizationPermissions: { projects: ['update'] },})Eine Person, viele Organisationen, kein Übersprechen.
Die aktive Organisation kommt aus der Session, bevor die Logik deines Handlers läuft, und ein Mitglied, das in der URL eine andere nennt, bekommt eine Absage, nicht still etwas anderes. Diese Grenze hält das Framework im Anwendungscode — eine echte, keine unüberwindbare.
- Organisationen, die die Leute selbst verwalten
- Anlegen, beitreten, wechseln. Niemand öffnet ein Ticket, um eine Person zwischen zwei Teams zu verschieben.
- Einladungen, die ablaufen
- Signiert, befristet, per E-Mail verschickt, mit der Rolle, die im Moment der Annahme vergeben wird.
- Eine Session, die es schon weiss
- Wer angemeldet ist, für welche Organisation und was er darf — beim ersten Render, ohne Ladezustand.
- Eine Backoffice-Ebene
- Plattform-Betreiber bekommen Nutzerverwaltung und Zugriff über alle Organisationen hinweg, getrennt von den Rollen des einzelnen Tenants.
Ein Modul, eine Migration — und das Schema gehört dir.
Das Modul registriert seine eigenen Composables, Server-Utilities, Middleware und Routen und bringt sein eigenes Drizzle-Migrationsset mit. Zeig ihm einen PostgreSQL-Connection-String, führe die Migration einmal aus, und die Identitätstabellen liegen in deiner Datenbank, unter deinen Migrationen.
bun i @jamflow/authprivates Registry — der Zugang kommt mit dem Plan
Der Rest des Werkzeugkastens ist JAMlabs → Läuft auf JAMflow Postgres, Neon oder deiner eigenen Instanz →
Daten und Zugriff
Die Nutzertabelle gehört dir.
Das Schema liegt unter Drizzle-Migrationen, in deinem Repository, und du kannst es lesen. Es gibt nichts zu exportieren, weil nichts von dir bei uns liegt — und die Aufzeichnung dessen, was Leute darin getan haben, ist append-only und per Hash verkettet.
Geht das an eine Sicherheitsabteilung? Datenresidenz, Zertifizierung und Deployment-Modell stehen auf der Enterprise-Seite, und was dort nicht steht, beantworten wir persönlich. Wenn euer Einkauf heute ein Zertifikat auf unseren Namen braucht, lies die erste Zeile dieser Seite noch einmal. Wie wir ein Security Review beantworten →
Fragen, bevor du dich festlegst.
Die, die uns wirklich gestellt werden. Alles andere frag uns direkt — es antwortet ein Mensch.
Frag uns etwas anderes →Ist das nur better-auth mit einer Rechnung dran?
Nein. better-auth ist das Fundament der Authentifizierung; alles darüber — die Rechteebene, die Plattformstufe, eine Prüfung ohne Query, die Runtime-Integration — ist von uns. Wenn nichts davon den Preis wert ist, nimm better-auth direkt: es stellt dir nichts in Rechnung.
Was kostet es?
Es kommt mit dem Scale-Plan zu CHF 99 im Monat, der ausserdem CHF 150 an enthaltener Nutzung, die übrigen Module dieser Stufe und den Support des Plans mitbringt. Keine separate Lizenz für das Auth-Modul, kein Preis pro Nutzer obendrauf.
Welche Datenbank braucht es?
PostgreSQL. JAMflow Postgres, Neon oder eine Instanz, die du selbst betreibst — das Schema verwalten in jedem Fall Drizzle-Migrationen, und es bleibt in deiner Datenbank statt in unserer.
JAMflow Postgres ansehen →Ich betreibe bereits better-auth. Übernehmt ihr das?
Ja. Entweder übernehmen wir die Wartung deines Setups, oder wir erarbeiten einen Migrationspfad auf das Modul — samt der Fälle, die in ein Rollensystem von der Stange nie passen, was der Hauptgrund für unsere eigene Rechteebene ist.
Funktioniert es ausserhalb von Nuxt?
Ein Nuxt-Modul und ein Elysia-Plugin, und das sind vorerst die beiden — gleicher Entwurf, gleiche Rechteebene, nur der Guard hängt sich anders ein.
Und wenn ich auf einem anderen Stack bin?
Darunter setzt es ausserdem PostgreSQL voraus. Bei Django, Laravel oder einer Next.js-App, die du nicht bewegen wirst, gibt es hier nichts zu installieren: Sinnvoll bleibt höchstens, uns deine Auth anzusehen und zu sagen, was wir ändern würden.
Muss ich auf der JAMflow-Plattform sein?
Nein. Das Modul läuft für sich, auf deiner Infrastruktur, gegen deine Datenbank. Manches greift enger, wenn der Rest des Stacks von uns ist — der Postgres-Cluster, der Ingress, aus dem wir ausliefern — aber nichts davon ist Bedingung.
Sag uns, wie eure Rollen aussehen.
Beschreib, wie dein Produkt entscheidet, wer was darf. Deckt das Modul es schon ab, bekommst du es. Deckt es das nicht ab, bekommst du eine klare Antwort darauf, was es bräuchte — von den Leuten, die es dann machen müssten.
