Auth

Comprehensive documentation for authentication in KilatKoding, including login, signup, password reset, and auth callbacks.

The auth layer is the foundation for every product area that requires user accounts. If auth is enabled, then login, signup, dashboard, settings, and several protected routes all depend on this configuration. Auth is only truly considered active when the auth toggle is on and the Supabase public env is present.

What this feature includes

Auth in KilatKoding includes:

• login with email and password,
• signup,
• Google OAuth,
• Magic Link,
• email verification,
• forgot password,
• update password,
• /auth/confirm callback,
• auth error handling.

Related routes and flows

Route or flow	Type	Purpose
/auth/login	Auth page	User login
/auth/sign-up	Auth page	Account registration
/auth/sign-up-success	Auth page	Post-signup confirmation
/auth/verify-email	Auth page	Email verification instructions
/auth/forgot-password	Auth page	Password reset request
/auth/update-password	Auth page	Set a new password
/auth/error	Auth page	Auth error handling
/auth/confirm	Callback route	OTP or OAuth callback
/dashboard	Post-login destination	The most common destination after successful auth

This auth flow depends on Supabase Auth, so the main routes here are pages and callbacks. The core login, signup, and verification mutations are handled through the Supabase integration rather than separate public API routes in this repository.

Dependencies and setup

Item	Required?	Notes
NEXT_PUBLIC_ENABLE_AUTH	Yes if auth is used	If false, auth is intentionally disabled. If it is true but the Supabase public env is empty, auth still falls back to a notice state
NEXT_PUBLIC_SUPABASE_URL	Yes	Supabase project URL
NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY	Yes	Supabase publishable key
Supabase redirect URLs	Yes	Must match local, staging, or production domains
OAuth provider config	Optional	Only needed if Google OAuth is enabled

How auth fallback works

• The server resolves auth status from the auth toggle plus the real Supabase public env values that are available.
• Auth pages then pass that resolved config down into the client forms.
• If the config is incomplete, the auth pages show a Supabase configuration notice instead of forcing a broken browser-client initialization.

What teams usually customize

• login and signup page copy,
• which auth providers are shown,
• post-login redirect behavior,
• post-signup flow,
• product terminology inside auth pages,
• public CTA paths that point to login.

When auth is disabled

Auth can appear inactive either because the toggle is intentionally off, or because the Supabase public env is incomplete. Auth is usually turned off when:

• the product is only launching as a waitlist,
• there is no gated user area yet,
• you want to validate demand before maintaining user accounts.

If auth is disabled, clean up:

• login CTA,
• dashboard CTA,
• member-area navigation,
• marketing copy that promises an account or dashboard.

Verification checklist

1. Login works.
2. Signup works.
3. Email verification behaves correctly.
4. Forgot password and update password work.
5. Supabase redirect URLs match the environment.
6. Public CTA paths do not expose auth routes when auth is disabled.
7. If the Supabase public env is incomplete, the auth pages show a clear configuration notice.

If auth stays enabled, the next feature areas to review are User dashboard and Admin dashboard.