Laat één systeem identiteit bezitten
Het loginformulier verzamelt een verzoek. Het authenticatiesysteem beslist of dat verzoek een identiteit vestigt en geeft de sessie uit die de rest van de applicatie vertrouwt. Die verantwoordelijkheid op één plek houden voorkomt dat elke route zijn eigen interpretatie van een ingelogde gebruiker verzint.
supastack gebruikt Better Auth voor identiteit en sessieafhandeling. Applicatiecode resolveert de sessie op beschermde grenzen en verbindt die aan een workspace. De interface kan nuttige toegangsstates tonen, maar clientstate mag geen bewijs worden dat een operatie geautoriseerd is.
De regel moet gelden op elk oppervlak dat het product shipt. Web-, mobiele en desktopclients moeten dezelfde identiteitsbeslissing consumeren in plaats van hem drie keer te implementeren — drie interpretaties van “ingelogd” is waar accountbugs vandaan komen.
Kies inlogmethoden bewust
Elke methode ruilt frictie tegen aanvalsoppervlak en een externe dependency. Wachtwoorden hebben resetflows en rate limiting nodig. Magic links en eenmalige codes hangen af van e-mailaflevering. OAuth delegeert identiteit aan providers als Google, GitHub of Apple — en erft hun outages, consentschermen en callbackregels.
supastack composeert ze via Better Auth — e-mail-OTP, wachtwoord, magic link, OAuth, met tweefactor en passkeys beschikbaar — achter één identiteitsbeslissing. Ship de kleinste set die je publiek echt nodig heeft; elke extra methode is weer een callbackpad, weer een failure mode en weer een flow om vóór de launch te verifiëren. De authenticatiegids dekt de bedrading.
Wanneer iemand op meer dan één manier kan inloggen, bepaal dan hoe de methodes samenkomen. Een Google-account en een magic link per e-mail die naar hetzelfde adres resolve horen op één identiteit te landen, niet op twee. Accountkoppelingsregels zijn deel van de identiteitsbeslissing, en ze verkeerd krijgen creëert dubbele gebruikers die maanden later opduiken als mysterieus verdwenen data.
Sessies zijn de credential die ertoe doet
Na het inloggen is de sessie — niet het wachtwoord — wat elke request draagt. Zijn verval-, opslag- en invalidatieregels bepalen de echte securityposture. Een sessie die uitloggen overleeft, of eentje die een verwijderd workspacelid kan blijven gebruiken, is een authenticatiefout die geen gepolijst inlogscherm kan fixen.
Bepaal de lifecycle vooraf: hoe lang sessies leven, of gebruikers hun actieve sessies kunnen zien en intrekken, en wat een wachtwoordwijziging, e-mailwijziging of workspaceverwijdering ermee doet. Sessiebeheer bestaat juist als module in de kit omdat deze beslissingen makkelijk uit te stellen en duur om achteraf in te bouwen zijn.
Verbind de sessie aan het gevraagde record
Ingelogd zijn geeft geen toegang tot elk record. Resolveer de workspace van de gebruiker op de server en neem die scope mee in reads en mutaties. Een taakidentificatie of recoverylink is een verwijzing naar werk, geen toestemming om het op te halen — de workspacegrenzen-post dekt die kant van de grens in detail.
Resolveer de scope in een vaste volgorde: authenticeer de sessie, laad het lidmaatschap en lees of schrijf daarna met die workspacecontext — nooit andersom. Middleware kan een anonieme bezoeker redirecten, maar kan de operatie niet autoriseren; de check hoort in de serveractie of routehandler waar het record wordt aangeraakt.
Accounts hebben een lifecycle, niet alleen een begin
Provisioning is de eerste test van die grens. Wanneer een gebruiker zich aanmeldt, moeten de workspace- en ownership-records die volgen veilig meer dan eens aan te maken zijn — lifecyclehooks kunnen door providers, retries of supporttools opnieuw worden afgespeeld. Een dubbel event moet een no-op zijn, geen dubbele organisatie.
Het einde van de lifecycle verdient dezelfde zorg. E-mailwijzigingen, wachtwoordresets, ledenverwijdering, accountverwijdering en data-export zijn elk kleine flows met eigen misbruikgevallen — een resetlink die twee keer werkt, een export die de records van een teamgenoot lekt. supastack levert GDPR-export en sessiebeheer om deze reden; waar je ook op bouwt, begroot de saaie flows mee.
Test de lifecycle, inclusief het einde
Een succesvolle logintest is nuttig maar incompleet. Oefen ongeldige credentials, verlopen of hergebruikte verificatiecodes, anonieme requests en cross-workspace-toegang. Verifieer dat uitloggen de sessie invalideert en dat een terugkerende client een eerder geautoriseerd scherm niet kan blijven gebruiken voor beschermd werk.
Onderscheid handlertests van deploymentacceptatie. Een memory-adapter kan de semantiek van een echte authenticatiehandler vaststellen zonder Postgres-persistentie of een providercallback te bewijzen. Verifieer de geconfigureerde origin, het callbackpad, sessieherstel en uitloggen met de gedeployde dependencies voordat je claimt dat het complete inlogtraject werkt.
- Ongeldige credentials en verlopen of hergebruikte verificatiecodes worden afgewezen.
- Anonieme en cross-workspace-requests krijgen geen owned data.
- Uitloggen invalideert de sessie — een verlopen client kan niet blijven handelen.
- Geprovisioneerde records blijven idempotent wanneer lifecyclehooks opnieuw afspelen.
- Echte-providercallbacks werken op de geconfigureerde origin — geverifieerd, niet aangenomen.
Veelgestelde authenticatievragen
De onderstaande vragen komen op zodra het loginformulier af is en het systeem moet blijven werken.
- Is middleware genoeg om routes te beschermen? — Middleware is een handige redirect, geen autorisatielaag. Elke serveractie en route resolveert zelf de sessie en workspace; page-level guards verbergen schermen zonder operaties te autoriseren.
- Zelf auth bouwen of een library gebruiken? — Sessiesemantiek is zelden waar een SaaS differentieert. Een onderhouden library als Better Auth achter duidelijke modulegrenzen geeft je geteste primitieven terwijl de beslissingen die ertoe doen — scoping, lifecycle — in je code blijven.
- Hoe verhouden sessies zich tot workspaces? — De sessie identificeert de persoon; de workspace identificeert de records die die persoon mag aanraken. Resolveer lidmaatschap op de server voor elke request en vertrouw nooit een workspace-ID die de client stuurt.
- Wat verwachten B2B-klanten van authenticatie? — Teamworkspaces met rollen, OAuth-sign-in, sessie-inzage en -intrekking en een audittrail. Tweefactor en passkeys worden voor admin-rollen steeds vaker verwacht.
- Wat breekt authenticatie in productie? — Meestal de randen: een callback-URL die alleen lokaal bestaat, een hook die twee keer provisioneert, een sessie die een lidmaatschap overleeft. Test de uiteinden van flows, niet alleen de beginselen.