Authentification et administration

Synchronisé avec le commit 7d452a6 du starter.

Sushi SaaS utilise Better Auth pour email/mot de passe, vérification, récupération, sessions, Google OAuth optionnel et double facteur. Chaque nouvel utilisateur reçoit une organisation personnelle ; les équipes sont déjà livrées.

Configurez BETTER_AUTH_SECRET, BETTER_AUTH_URL, NEXT_PUBLIC_AUTH_BASE_URL et l’URL web. Google est optionnel. En production, inscription et flux sensibles exigent limitation Redis et Turnstile. Resend livre les messages ; en local, les liens peuvent être journalisés sans fournisseur ou avec AUTH_DEV_EMAIL_LINKS=true, valeur refusée en production.

Identité et autorisation

• L’ID chaîne Better Auth authentifie ; user.uuid est l’identité publique du domaine.
• Email et fournisseur sont uniques, mais l’email ne sert jamais à autoriser.
• Les rôles (owner, admin, member) permettent les actions ; les entitlements contrôlent fonctions et limites.
• Toute route authentifie avant l’accès aux données ; le client traduit des codes stables, jamais un message interne.

Administration séparée

pnpm dev:admin écoute sur 3001. Déployez apps/admin séparément avec sa propre origine et URL d’auth. Promouvez via pnpm admin:promote : admin_ro lit, admin_rw modifie. MFA est obligatoire et les écritures sont auditées. Les rôles d’organisation ne sont pas des rôles plateforme.

Avant lancement, testez inscription, vérification, connexion, récupération, callback Google, révocation de session, MFA et les deux permissions admin. Suivez le guide dédié Configuration et accès à la console pour le déploiement et l’arrivée des opérateurs.