OAuth-inloggen instellen

Maak en verifieer een echt account

Authenticatie betekent bewijzen wie de app gebruikt. Start Postgres en voer eerst de migraties uit met behulp van de databasehandleiding, en laat vervolgens de webserver draaien. Open http://localhost:3000/auth,, kies aanmelden voor e-mailadres/wachtwoord, voer uw naam, e-mailadres en wachtwoord in en verzend. Bewaar EMAIL_PROVIDER=local voor deze eerste test.

Wanneer een stroom om een e-mailcode vraagt, opent u http://localhost:3000/mail-preview in een ander browsertabblad, zoekt u het meest recente bericht voor dat adres en kopieert u de code terug naar het aanmeldingsformulier. Vraag een nieuwe code aan als deze verloopt. Deze berichten blijven in de lokale outbox; herhaaldelijk controleren van een externe inbox zal ze niet vinden. Meld u af en meld u opnieuw aan om te bevestigen dat het door de database ondersteunde account werkt.

Als bij de aanmelding een databaseverbinding of een fout in een ontbrekende tabel wordt gemeld, voltooi dan het instellen van de database in plaats van sociaal inloggen in te schakelen. Google-, GitHub-, Apple-, X- en Microsoft-knoppen hebben hun eigen providerapplicatie en terugbelinstellingen nodig; schakel er pas een in nadat de providerhandleiding compleet is. Better Auth is de meegeleverde standaardengine en heeft geen betaald authenticatieaccount nodig voor lokale e-mailaanmelding.

• Start Postgres voordat u een account aanmaakt
• E-mailinlogcodes gebruiken en problemen oplossen
• Inloggen bij Google configureren
• Google-inloggen toevoegen
• GitHub-inloggen toevoegen
• Apple-inloggen toevoegen

Kies ingeschakelde inlogmethoden

Het fundament bevat e-mail/wachtwoord, OTP en configureerbare sociale authenticatie. Better Auth bezit identiteit en sessies, terwijl de applicatie providerconfiguratie en transactionele OTP-aflevering componeert.

Schakel alleen de sociale providers in die je hebt geconfigureerd. Provider-clientsecrets en het authenticatiesecret blijven op de server.

Verbind identiteit aan een workspace

Geauthenticeerde handlers resolveeren sessiestate voordat ze workspacerecords benaderen. Workspace-provisioning moet idempotent blijven zodat het herhalen van een lifecyclehook geen dubbele eigenaarschapsrecords creëert.

Verifieer sessiegedrag

Test inloggen, ongeldige of verlopen OTP's, single-use-consumptie, uitloggen en afgewezen anonieme toegang. Memory-adaptertests dekken handlersemantiek; productiedatabasepersistentie en echte providercallbacks hebben aparte acceptatie nodig.

Setup en configuratie

1. Zet AUTH_SECRET op minstens 32 willekeurige tekens — openssl rand -hex 32 werkt.

2. Maak in de developerconsole van elke provider een OAuth-app aan en registreer de callback-URL: {APP_URL}/api/auth/callback/<provider> onder Better Auth (de default-AUTH_PROVIDER). Gebruik aparte apps voor lokaal en productie waar de provider maar één callback toestaat — docs/github-auth-setup.md doorloopt de GitHub-flow end-to-end.

3. Zet de flag van de provider aan en vul zijn clientpaar in — AUTH_GOOGLE_ENABLED plus GOOGLE_CLIENT_ID en GOOGLE_CLIENT_SECRET, en het bijpassende drietal voor Apple, GitHub, Microsoft of Twitter. Een flag aanzetten zonder credentials laat de startup falen en noemt de ontbrekende variabele.

4. Microsoft is de enige callback die per engine verschilt: /api/auth/callback/microsoft onder Better Auth, /api/auth/callback/microsoft-entra-id onder Auth.js.

AUTH_SECRET=<at-least-32-random-characters>
AUTH_PASSKEY_ENABLED=true
EARLY_ACCESS_INVITE_ONLY=false

AUTH_GOOGLE_ENABLED=true
GOOGLE_CLIENT_ID=…
GOOGLE_CLIENT_SECRET=…

AUTH_GITHUB_ENABLED=true
GITHUB_CLIENT_ID=…
GITHUB_CLIENT_SECRET=…

# AUTH_APPLE_ENABLED / AUTH_MICROSOFT_ENABLED / AUTH_TWITTER_ENABLED
# follow the same pattern:
# MICROSOFT_CLIENT_ID=…  MICROSOFT_CLIENT_SECRET=…
# TWITTER_CLIENT_ID=…    TWITTER_CLIENT_SECRET=…

# Workspace connected accounts (Settings → Connections):
# CONNECTED_X_CLIENT_ID=          CONNECTED_X_CLIENT_SECRET=
# CONNECTED_GOOGLE_CLIENT_ID=     CONNECTED_GOOGLE_CLIENT_SECRET=
# CONNECTED_MICROSOFT_CLIENT_ID=  CONNECTED_MICROSOFT_CLIENT_SECRET=

# Callbacks to register (Better Auth):
#   {APP_URL}/api/auth/callback/google
#   {APP_URL}/api/auth/callback/apple
#   {APP_URL}/api/auth/callback/github
#   {APP_URL}/api/auth/callback/twitter
#   {APP_URL}/api/auth/callback/microsoft   (Auth.js: microsoft-entra-id)

Implementatieworkflow

Workspace-externe accounts zijn een ander oppervlak: de CONNECTED_X_*-, CONNECTED_GOOGLE_*- en CONNECTED_MICROSOFT_*-paren voeden Settings → Connections, en hun callbacks leven onder {APP_URL}/api/accounts/{x|google|microsoft}/callback. Een lege client-id laat de connect-flow van die provider uitgeschakeld — hergebruik daar geen inlog-app-credentials.

Provider-clientsecrets blijven server-only, net als AUTH_SECRET — nooit in NEXT_PUBLIC_- of EXPO_PUBLIC_-variabelen.

Inloggen werkt? Ga verder naar AI instellen.

Verificatie en probleemoplossing

Test eerste login, een terugkerende sessie, een geannuleerd consentscherm en een uitgeschakelde provider. Een callback-mismatch is de gebruikelijke failure — de geregistreerde URL moet exact overeenkomen met APP_URL en de callback-id van de engine, en de app heeft een herstart nodig na env-wijzigingen.