Auth Overview

MakerKit uses Firebase Authentication to allow access to your Next.js application using oAuth providers and email/password.

MakerKit uses Firebase 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 Firebase's Authentication: we will see how.

This documentation will help you with:

  • Setup - setting up your Firebase 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:

auth: {
  enableMultiFactorAuth: true,
  providers: {
    emailPassword: true,
    phoneNumber: false,
    emailLink: false,
    oAuth: [GoogleAuthProvider],
  },
},

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 pages and the user's profile page.

Additionally, we can choose to add one or multiple oAuth providers by adding the Firebase provider to the oAuth array. For example, we could also add Facebook, Twitter and GitHub:

import { FacebookAuthProvider, TwitterAuthProvider, GitHubAuthProvider } from
'firebase/auth';

oAuth: [
  GoogleAuthProvider,
  FacebookAuthProvider,
  TwitterAuthProvider,
  GitHubAuthProvider
],

Additionally, we can add custom oAuth providers. First, we define them by extending the OAuthProvider class:

class MicrosoftAuthProvider extends OAuthProvider {
  constructor() {
    super('microsoft.com');
  }
}

class AppleAuthProvider extends OAuthProvider {
  constructor() {
    super('apple.com');
  }
}

And then, we simply add them to the oAuth array:

oAuth: [
  GoogleAuthProvider,
  MicrosoftAuthProvider,
  AppleAuthProvider
],

Remember that you will always need to enable the authentication methods you want to use from the Firebase Console once you deploy your application to production

SSR

We set up MakerKit to persist the user's session on all the website's pages using SSR.

SSR allows for seamless integration between the pages of your website. For example, your pricing page could prompt your users to upgrade to the new plan rather than what it shows to non-subscribers of your service.

Many websites use persistent sessions in different ways:

  • personalized content
  • pre-filled forms
  • and a lot more

While it sounds great, there is a downside: by server-side rendering the page (SSR), we lose the possibility to statically generate the page (SSG), which is faster.

Should you use SSR or SSG?

Ultimately, it comes down to what your needs and preferences are. We recommend:

  • using SSG for static pages, such as the home page, your blog, and the documentation pages
  • using SSR for dynamic pages, such as your application's code (the pages behind authentication)

The above is the default configuration of the Makerkit's codebase, so if you're fine with that, simply keep using the same patterns as the base application.


Stay informed with our latest resources for building a SaaS

Subscribe to our newsletter to receive updatesor