Configuration

Learn how authentication works in MakerKit and how to configure it.

The way you want your users to authenticate can be driven via configuration.

If you open the auth configuration at apps/web/config/auth.config.ts, you'll find the auth settings:

const authConfig = {
  // Captcha site key (optional)
  captchaTokenSiteKey: process.env.NEXT_PUBLIC_CAPTCHA_SITE_KEY,

  // Display terms checkbox during sign-up
  displayTermsCheckbox: process.env.NEXT_PUBLIC_DISPLAY_TERMS_AND_CONDITIONS_CHECKBOX === 'true',

  // Allow linking/unlinking of auth identities (OAuth, email, password)
  enableIdentityLinking: process.env.NEXT_PUBLIC_AUTH_IDENTITY_LINKING === 'true',

  providers: {
    password: process.env.NEXT_PUBLIC_AUTH_PASSWORD === 'true',
    magicLink: process.env.NEXT_PUBLIC_AUTH_MAGIC_LINK === 'true',
    otp: process.env.NEXT_PUBLIC_AUTH_OTP === 'true',
    oAuth: ['google'], // Add more: 'github', 'discord', 'linkedin_oidc', etc.
  },
};

Provider Configuration

The providers object controls which authentication methods are displayed:

ProviderEnvironment VariableDescription
passwordNEXT_PUBLIC_AUTH_PASSWORDEmail/password authentication
magicLinkNEXT_PUBLIC_AUTH_MAGIC_LINKPasswordless email link
otpNEXT_PUBLIC_AUTH_OTPEmail-based one-time password
oAuthArray in configOAuth providers (google, github, etc.)

Enabling Identity Linking

To allow users to link multiple authentication methods to their account:

  1. Set the environment variable:

    NEXT_PUBLIC_AUTH_IDENTITY_LINKING=true
    
  2. Enable identity linking in Supabase Dashboard:

    • Go to Authentication → Settings
    • Enable "Enable identity linking"
  3. Add more OAuth providers to the config:

    oAuth: ['google', 'github', 'discord', 'linkedin_oidc'],
    

Adding OAuth Providers

  1. Add the provider to auth.config.ts:

    oAuth: ['google', 'github', 'discord'],
    
  2. Configure the provider in Supabase Dashboard:

    • Go to Authentication → Providers
    • Enable the provider
    • Add your OAuth app credentials (Client ID, Client Secret)
  3. Create an OAuth application on the provider's developer portal:

    • Set the redirect URL (provided by Supabase)
    • Copy credentials to Supabase

Original (Legacy) Configuration

The documentation previously referenced this structure which is now outdated:

// LEGACY - Do not use
auth: {
  requireEmailConfirmation: false,
  providers: {
    emailPassword: true,
    phoneNumber: false,  // Not implemented
    emailLink: false,
    oAuth: ['google'] as Provider[],
  },
}

Note: phoneNumber is not currently implemented. The current config uses password, magicLink, otp, and oAuth instead of emailPassword, phoneNumber, and emailLink.

Requiring Email Verification

This setting needs to match what you have set up in Supabase. If you require email confirmation before your users can sign in, you will have to flip the following flag in your configuration:

auth: {
  requireEmailConfirmation: false,
}

When the flag is set to true, the user will not be redirected to the onboarding flow, but will instead see a successful alert asking them to confirm their email. After confirmation, they will be able to sign in.

When the flag is set to false, the application will redirect them directly to the onboarding flow.

Emails sent by Supabase

Supabase spins up an InBucket instance where all the emails are sent: this is where you can find emails related to password reset, sign-in links, and email verifications.

To access the InBucket instance, you can go to the following URL: http://localhost:54324/. Save this URL, you will use it very often.