• Documentation
  • /
  • Remix Supabase
  • /
  • Auth Overview

Auth Overview

MakerKit uses Supabase Authentication to allow access to your Remix application using oAuth providers and email/password.

MakerKit uses Supabase to manage authentication within your application.

By default, every kit comes with the following built-in authentication methods:

  • Email/Password - we added, by default, the traditional way of signing in
  • Third Party Providers - we also added by default Google Auth sign-in
  • Email Links
  • Phone Number

You're free to add (or remove) any of the methods supported by Supabase's Authentication: we will see how.

This documentation will help you with the following:

  • Setup - setting up your Supabase project
  • SSR - use SSR to persist your users' authentication, adding new providers
  • Customization - an overview of how MakerKit works so that you can adapt it to your own application's needs

Configuration

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

If you open the global configuration at src/configuration.ts, you'll find the auth object:

import type { Provider } from '@supabase/gotrue-js/src/lib/types';

auth: {
  requireEmailConfirmation: false,
  providers: {
    emailPassword: true,
    phoneNumber: false,
    emailLink: false,
    oAuth: ['google'] as Provider[],
  },
}

As you can see, the providers object can be configured to only display the auth methods we want to use.

  1. For example, by setting both phoneNumber and emailLink to true, the authentication pages will display the Email Link authentication and the Phone Number authentication forms.
  2. Instead, by setting emailPassword to false, we will remove the email/password form from the authentication and user profile pages.

Remember that you will always need to enable and configure the authentication methods you want to use in your Supabase project.

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.


Stay informed with our latest resources for building a SaaS

Subscribe to our newsletter to receive updatesor