Auth Issues

Use this page when users cannot get into the app, keep landing on the wrong screen, or passkey and OAuth behavior does not match your expectations.

Problem: The User Keeps Getting Sent Back To Login

NuxtBase protects /dashboard, /admin, and /ai routes.

If there is no session, protected routes redirect to /login.

What To Check

1. confirm the request is reaching the same domain that Better Auth is configured for
2. confirm cookies are actually being set after login
3. check whether the app is switching between different hostnames such as localhost, an IP, and a tunnel URL

If your auth cookies are being created on one origin and you browse on another, login can appear to succeed and still send the user back to /login.

Problem: The User Cannot Reach The Dashboard Because Email Verification Blocks Them

This is expected behavior for verified-session routes.

In the template:

• no session returns 401 Unauthorized
• unverified session returns 403 Email verification required
• protected route navigation redirects the user to /auth/confirm?mode=verify-email

What To Check

• whether the account actually finished email verification
• whether email sending is working at all
• whether the verification link is pointing at the same public domain the user is browsing

Problem: OAuth Login Lands On /dashboard Instead Of /admin

This behavior is correct in the current template.

OAuth login does not use the same post-login role-routing path as email/password or completed 2FA flows.

That means:

• /login OAuth fallback goes to /dashboard
• /register OAuth callback is also set to /dashboard
• a platform admin is not automatically redirected to /admin after OAuth unless you explicitly pass a safe redirect

Note

If you were expecting automatic admin landing after OAuth, that expectation does not match the current implementation.

Problem: OAuth Callback Works Locally But Fails In Production

Most of the time, the callback URL registered with Google or GitHub does not match the actual deployed auth URL.

Fix Checklist

• BETTER_AUTH_URL must use the real production origin
• the OAuth provider console must use the same callback host
• if you changed domains recently, remove old localhost or preview callback entries that you are no longer testing

Problem: Passkeys Work Locally But Fail After Deploy

Passkeys are extremely sensitive to domain configuration.

The main trap is leaving:

BETTER_AUTH_PASSKEY_RP_ID=localhost

in production.

In NuxtBase, explicit BETTER_AUTH_PASSKEY_RP_ID wins over hostname fallback. So if that value is still set to localhost, passkey registration and login can stay bound to the wrong relying party.

Fix

Use one of these approaches:

• set BETTER_AUTH_PASSKEY_RP_ID to your real production hostname
• or remove it entirely and let the template derive it from the production auth URL/site URL

Problem: Admin Users Reach /dashboard Instead Of /admin

This depends on how the user signed in.

• standard auth-route handling for authenticated users can redirect verified platform admins to /admin
• OAuth default fallback still lands on /dashboard

So the same admin account can see different landing behavior depending on the entry path.

Problem: 2FA Codes Keep Failing

Common causes:

• using an expired TOTP code
• trying to disable OAuth 2FA when it is not enabled
• using a code from a different authenticator seed than the one currently saved

If the API returns Invalid verification code, treat it as a real verification failure first, not as a UI bug.

Fastest Way To Debug Auth

1. confirm the current public domain and BETTER_AUTH_URL
2. confirm the user has a real session cookie
3. confirm email verification state
4. confirm whether the user came through password, OAuth, passkey, or 2FA
5. only then debug role-based redirects