OAuth

NuxtBase supports Google and GitHub sign-in through Better Auth social providers.

Both providers are wired into the same register and login surfaces:

/register
/login

Provider Enable Rules

OAuth providers are enabled only when both values in a provider pair are present:

GOOGLE_CLIENT_ID and GOOGLE_CLIENT_SECRET
GITHUB_CLIENT_ID and GITHUB_CLIENT_SECRET

If you configure only one half of the pair, startup validation fails.

Where OAuth Appears in the Product

The shipped UI exposes OAuth buttons in two places:

Register

On /register, the user can choose:

On /login, the user can choose:

This means OAuth is not a hidden enterprise add-on. It is part of the default buyer-facing auth surface.

Redirect Behavior After OAuth

The login page sends OAuth users back to the current safe redirect target if one exists. Otherwise, the current implementation falls back to /dashboard.

More specifically:

/login OAuth uses the safe redirect target, with /dashboard as the default fallback
/register OAuth uses /dashboard as the callback target directly

Unlike the email/password, passkey, and post-2FA flows, OAuth does not currently apply the getPostLoginPath() role-based /admin split after callback. So a platform admin using OAuth without an explicit redirect still lands on /dashboard.

Callback URLs

Provider callback configuration belongs in setup/authentication-setup, but the practical URLs are:

/api/auth/callback/google
/api/auth/callback/github

OAuth and Verification Expectations

OAuth removes the need for password entry, but it does not remove all downstream auth concerns.

You still need to verify:

post-login redirect behavior
admin vs non-admin routing
settings and security screens
2FA behavior for OAuth-only users

That last point matters because NuxtBase includes a separate OAuth-only path for enabling and disabling two-factor auth.

OAuth-Only Users and 2FA

Credential users can use the standard Better Auth 2FA setup flow.

OAuth-only users take a different path:

enable 2FA through a dedicated internal route
receive a generated TOTP secret and backup codes
disable 2FA using a verification code instead of password confirmation

This is a real product distinction in the template, not just a documentation detail.

Recommended Verification Checklist

enable one provider first, not both at once
complete a fresh sign-in with that provider
confirm the user lands in the expected area
open dashboard settings and confirm the security section still works
if the account has no password, test the OAuth-specific 2FA flow