> ## Documentation Index
> Fetch the complete documentation index at: https://belajarkoding.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Auth

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

<Info>
  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.
</Info>

## 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 |

<Note>
  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.
</Note>

## 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.

<Tip>
  If auth stays enabled, the next feature areas to review are [User dashboard](/en/kilatkoding/features/user-dashboard) and [Admin dashboard](/en/kilatkoding/features/admin-dashboard).
</Tip>