A practical guide to auditing authentication in a Next.js SaaS starter before it breaks across preview URLs, production domains, and protected routes.
Authentication is one of the easiest features to demo and one of the easiest features to break.
A sign-in button proves almost nothing by itself. Real SaaS auth has to survive production domains, preview deployments, OAuth callbacks, magic links, session refresh, protected routes, billing states, role checks, account deletion, and sometimes organisations or custom domains.
When evaluating a Next.js SaaS starter, treat auth as a system, not a screen.
The happy-path demo hides the hard parts
The usual demo flow is simple:
- Click sign in.
- Use a test account.
- Land on the dashboard.
That does not prove much.
Real users create edge cases immediately:
- they click a magic link on another device;
- they use Google OAuth on a preview deployment;
- their session expires while a form is open;
- they try to access
/dashboardwhile logged out; - they cancel checkout and return later;
- they use a workspace invite link;
- they sign in with a different provider using the same email;
- they delete their account;
- they are removed from a team.
A production-ready starter should explain these paths or at least provide clean extension points.
Redirect loops usually mean route boundaries are unclear
Redirect loops happen when the application cannot clearly decide whether a route is public, auth-only, protected, or already authenticated.
Common causes include:
- middleware running on routes it should ignore;
- auth pages redirecting to dashboard while dashboard redirects back to auth;
- callback routes being protected by mistake;
- missing environment variables for the canonical app URL;
- inconsistent trailing slash or base-path behaviour;
- session checks that disagree between middleware and server components.
The fix is usually architectural rather than cosmetic. A good starter should have an explicit route map:
- public marketing routes;
- auth routes;
- callback routes;
- protected app routes;
- admin routes;
- API routes;
- webhook routes.
If everything is protected by one broad matcher and exceptions are scattered around the codebase, expect pain.
OAuth callbacks need environment discipline
OAuth providers are strict about callback URLs. That is good security, but it creates setup friction.
A starter should document the callback URLs needed for:
- local development;
- preview deployments;
- production;
- custom domains;
- subdomains if relevant.
It should also explain which environment variable represents the public application URL and how that value changes by environment.
Red flags:
- callback URLs only shown for
localhost; - no mention of preview URLs;
- auth provider setup hidden behind “configure your provider”;
- hard-coded base URLs;
- no troubleshooting section for OAuth redirects.
If your buyer cannot configure OAuth without guessing, the starter is not handoff-ready.
Magic links need a clear product flow
Magic links are convenient, but they create state questions:
- How long does the link last?
- What happens if it is opened on another device?
- Where does the user land after verification?
- Does the app preserve the intended destination?
- What happens if the user purchased before creating an account?
- Are used or expired links handled clearly?
A starter that supports magic links should include the UX around them: email copy, expired-link screen, resend path, and redirect destination handling.
Auth is not only cryptography. It is also user experience.
Session drift creates confusing bugs
Session drift happens when different parts of the app disagree about who the user is or what they can access.
For example:
- middleware sees a stale token;
- a server component fetches a fresh user;
- a client component still has old state;
- billing status changed by webhook but the dashboard still shows old access;
- a role changed but cached data still shows admin controls.
A robust SaaS starter defines where the source of truth lives.
For sensitive checks, prefer server-side decisions. Client state can improve interactivity, but it should not be the final authority for access.
Auth and billing should be connected carefully
Many SaaS starters treat auth and billing as separate modules. In the product, they interact constantly.
Questions to ask:
- Can someone buy before creating an account?
- If so, how is payment linked to the eventual user?
- Can users sign up with OAuth after paying with an email link?
- What happens if the billing email differs from the login email?
- Can an unpaid user access account settings?
- Can a cancelled user still log in but not use paid features?
A good starter does not need to force one answer. It should make the chosen answer explicit.
Roles should not be only visual
Hiding a button is not access control. If the server still accepts the action, the permission model is broken.
A SaaS starter should enforce permissions at the boundary where data changes or sensitive data is read.
Look for:
- typed roles;
- central permission helpers;
- server-side checks;
- protected admin routes;
- audit logs for sensitive actions;
- clear separation between billing entitlements and user roles.
Billing answers “has this account paid?” Roles answer “what can this user do?” They are related, but they are not the same.
Account lifecycle matters
Auth does not end at sign-in.
A production-ready starter should consider:
- profile editing;
- email changes;
- password reset or provider-managed equivalent;
- account deletion;
- session invalidation;
- data export;
- team removal;
- admin suspension;
- audit logging.
Even if the template ships a lean version, the data model should not make these impossible later.
Auth audit checklist
Before trusting a Next.js SaaS starter’s auth layer, check:
- [ ] Public, auth, callback, protected, admin, and webhook routes are separated.
- [ ] Middleware or proxy matchers are documented.
- [ ] The authoritative access check runs in a server component, route handler, or the data layer, not in middleware alone.
- [ ] OAuth callback URLs are shown for local and production.
- [ ] Preview URL behaviour is explained.
- [ ] Magic link expiry and redirect behaviour is clear.
- [ ] Sessions are checked server-side for sensitive routes.
- [ ] Roles and permissions are typed or centralised.
- [ ] Billing entitlements are not confused with user roles.
- [ ] Account deletion and export are considered.
- [ ] Auth errors have user-facing states.
- [ ] The docs include common redirect and callback troubleshooting.
Template Empire angle
Template Empire treats auth as part of the foundation: route protection, user management, compliance scaffolding, billing interaction, and auditability all matter. The goal is not simply to make sign-in work in a demo. The goal is to make auth understandable enough that a buyer can safely build on it.
