Tech-USP: Login und Berechtigungen sind nicht etwas, das Ihr baut — sie sind Framework-Default. E-Mail/Passwort, JWT, Sessions, Rollen, Feld-Berechtigungen, Datensatz-Ownership — alles eingebaut.
Highlights
- Email/Password mit Argon2 + Identity-V3-Migration (Legacy-Hash-Verifier)
- JWT mit jose,
jti-Claim für Session-Revocation - Sessions mit
sessionCreator/Revoker/Checker-Callbacks, Auto-Revoke bei Password-Change - Roles als String-Unions (typed), nicht Enums
- Field-Access read/write per Field konfigurierbar
- Row-Ownership via
from()-Helper (user:id/claim:featureQn), straddle-safe Multi-Role-Check - Auth-Claims via
r.authClaims()— Features tragen Claims in JWT ein, typed Handles, Auto-Prefix - Anonymous-Access für Public-Endpoints (
roles: ["anonymous"]) - Password-Reset + Email-Verification mit HMAC-signed Tokens, silent-success, Login-Gate via Config
- 2FA geplant (siehe
features/core-auth-2fa-sessions.md)
Architektur-Tiefendoku
permissions— Rollen + Ownershipcore-auth— Auth email-password Featurecore-auth-features— Auth-Erweiterungencore-auth-2fa-sessions— 2FA + Sessions../../uebersicht.mdSprint H — H.1 Claims, H.2 Ownership, H.3 Session-Revocation
Wo das im Pitch landet
- DACH-Sales: Implizit unter „Audit + Compliance” (ISO 27001 verlangt Session-Management)
- Indie-Hacker: Sub-Argument unter „AI baut alles” — Auth ist Teil des generierten Backends