Using Next.js and Auth0 with Supabase

Overview

In this article, we are going to explore using Next.js, Auth0, and Supabase to build a classic Todo app. Each user will only be able to see their own todos, so we will need to implement authentication, authorization, and a database.

This article will cover the following:

• configuring Auth0, Next.js, and Supabase to work together seamlessly
• using the

  nextjs-auth0

  library for authentication
• implementing Row Level Security (RLS) policies for authorization
• what a JWT is and how to sign our own
• using PostgreSQL Functions to extract values from a JWT

The final version of the Todo app code can be found here.

Prerequisites

This article does not assume prior experience with any of these technologies; however, you will need Node.js installed to follow along. In addition, plan to have accounts for the managed services in the section below (Auth0 and Supabase). Both are free as of this writing and don't require a credit card.

Stack

Next.js is a React framework that makes building efficient web apps super easy. It also gives us the ability to write server-side logic — which we will need to ensure our application is secure — without needing to maintain our own server.

Auth0 is an authentication and authorization solution that makes managing users and securing applications a breeze. It is an extremely battle-tested and mature solution for auth.

Supabase is an open-source backend-as-a-service, which makes it possible to build an application in a weekend and scale to millions. It is a convenient wrapper around a collection of open-source tools that enable database storage, file storage, authentication, authorization, and real-time subscriptions. While these are all great features, this article will only use database storage and authorization.

"Wait, if Supabase handles auth, why are we using Auth0?"

One of the real strengths of Supabase is the lack of vendor lock-in. Maybe you already have users in Auth0, your company has a lot of experience with it, or you're interacting with other applications that use it. Any of the Supabase components can be swapped out for a similar service and hosted anywhere.

So let's do just that!

Auth0

The first thing we need to do is sign up for a free account with Auth0. Once at the dashboard, we need to create a new

Tenant

for our project.

A tenant is a way of isolating our users and settings from other applications we have with Auth0.

Click the name of your account in the top left, and then select

Create tenant

from the dropdown.

Give your tenant a unique

Domain

, set the

Region

closest to you, and leave the

Environment Tag

set to

Development

.

In a production application, you want your region to be as close as possible to the majority of your users.

Next, we want to create an Application. Select

Applications

>

Applications

from the sidebar menu, and click

+ Create Application

. We want to give it a name (this can be the same as the Tenant) and select

Regular Web Applications

. Click

Create

.

From the application's page you are redirected to, select the

Settings

tab and scroll down to the

Application URIs

section.

Add the following:

Allowed Callback URLs

:

http://localhost:3000/api/auth/callback

Allowed Logout URLs

:

http://localhost:3000

Go to

Advanced Settings

>

OAuth

and confirm the

JSON Web Token (JWT) Signature Algorithm

is set to

RS256

and that

OIDC Conformant

is

enabled

. Be sure to save your changes.

Awesome. We now have an Auth0 instance configured to handle authentication for our application. So let's build an app!

While we could use any web application framework for this example, I am going to use Next.js. It gives us a super-efficient React application and includes file-based routing out of the box. In addition, it allows us to run server-side logic while building our app with

getStaticProps

and (when the user requests a page) with the

getServerSideProps

function. We will need to do things like authentication server-side, but we don't want the hassle of setting up, maintaining, and paying for another server.

Next.js

The fastest way to create a Next.js application is by using the

create-next-app

package:

npx create-next-app supabase-auth0

Replace the contents of

pages/index.js

with:

// pages/index.js

import styles from "../styles/Home.module.css";

const Index = () => {
  return <div className={styles.container}>Working!</div>;
};

export default Index;

Run the project in Development mode:

npm run dev

And confirm it is working at

http://localhost:3000

.

Authentication

Let's integrate the

nextjs-auth0

package. This is a convenient wrapper around the Auth0 JS SDK but specifically built for Next.js:

npm i @auth0/nextjs-auth0

Create a new folder at

pages/api/auth/

and add a file called

[...auth0].js

with the following content:

// pages/api/auth/[...auth0].js

import { handleAuth } from "@auth0/nextjs-auth0";

export default handleAuth();

The

[...auth0].js

is a catch all route. This means that any url that starts with

/api/auth0

will load this component —

/api/auth0

,

/api/auth0/login

,

/api/auth0/some/deeply/nested/url

etc.

This is one of those awesome things

nextjs-auth0

gives us for free! Calling

handleAuth()

automatically creates a collection of convenient routes — such as

/login

and

/logout

— and all the necessary logic for handling tokens and sessions. There're no extra steps required besides calling this method.

Replace the contents of

pages/_app.js

with:

// pages/_app.js

import "@/styles/globals.css";
import { UserProvider } from "@auth0/nextjs-auth0/client";

export default function App({ Component, pageProps }) {
  return (
    <UserProvider>
      <Component {...pageProps} />
    </UserProvider>
  );
}

Create a

.env.local

file in your root project folder and add the following:

AUTH0_SECRET=generate-this-below
AUTH0_BASE_URL=http://localhost:3000
AUTH0_ISSUER_BASE_URL=https://<name-of-your-tenant>.<region-you-selected>.auth0.com
AUTH0_CLIENT_ID=get-from-auth0-dashboard
AUTH0_CLIENT_SECRET=get-from-auth0-dashboard

See the Next.js documentation for Environment variables to learn more.

Generate a secure

AUTH0_SECRET

by running:

node -e "console.log(crypto.randomBytes(32).toString('hex'))"

AUTH0_CLIENT_ID

and

AUTH0_CLIENT_SECRET

can be found at

Applications > Settings > Basic Information

in the Auth0 Dashboard.

You will need to quit the Next.js server and re-run the

npm run dev

command anytime new environment variables are added to the

.env.local

file

Let's update our

pages/index.js

file to add the ability to sign in and out:

// pages/index.js

import styles from "../styles/Home.module.css";
import { useUser } from "@auth0/nextjs-auth0/client";
import Link from "next/link";

const Index = () => {
  const { user } = useUser();

  return (
    <div className={styles.container}>
      {user ? (
        <p>
          Welcome {user.name}! <Link href="/api/auth/logout">Logout</Link>
        </p>
      ) : (
        <Link href="/api/auth/login">Login</Link>
      )}
    </div>
  );
};

export default Index;

We are using the

useUser()

hook to get the

user

object if they have signed in. If not, we are rendering a link to the Login page.

Next.js'

Link

component is being used to enable client-side routing rather than needing to reload the entire page from the server.

We can also add the ability to handle the

loading

and

error

states:

// pages/index.js

import styles from "../styles/Home.module.css";
import { useUser } from "@auth0/nextjs-auth0/client";
import Link from "next/link";

const Index = () => {
  const { user, error, isLoading } = useUser();

  if (isLoading) return <div className={styles.container}>Loading...</div>;
  if (error) return <div className={styles.container}>{error.message}</div>;

  // rest of component
};

export default Index;

We need our users to be signed in to see their

todos

or add a new

todo

. To accomplish this, we'll protect this route — requiring the user to be signed in. We'll also automatically redirect them to the

/login

route if they are not.

Thankfully, the

nextjs-auth0

library makes this super simple with the

withPageAuthRequired

function. We can tell Next.js to call this function on the server before rendering our page by setting it to the

getServerSideProps

function.

Add the following to the

pages/index.js

file:

// other imports
import { withPageAuthRequired } from "@auth0/nextjs-auth0";

// rest of component

export const getServerSideProps = withPageAuthRequired();

// other export

This function checks if we have a user signed in and handles redirecting them to the Login page if not. If we have a user, it automatically passes the

user

object to our

Index

component as a prop. Since this is happening on the server before our component is rendered, we no longer need to handle loading, error states, or whether or not the user is logged in. This means we can significantly clean up our rendering logic.

This is what our entire file should look like:

// pages/index.js

import styles from "../styles/Home.module.css";
import { withPageAuthRequired } from "@auth0/nextjs-auth0";
import Link from "next/link";

const Index = ({ user }) => {
  return (
    <div className={styles.container}>
      <p>
        Welcome {user.name}! <Link href="/api/auth/logout">Logout</Link>
      </p>
    </div>
  );
};

export const getServerSideProps = withPageAuthRequired();

export default Index;

Very clean!

We want to display a list of todos as the landing page, but first, we need somewhere to store them.

Supabase

Head over to database.new to create a free Supabase account. From the dashboard, click

New project

and choose your

Organization

.

Enter a name and password, and select a region geographically close to what you chose for your Auth0 region.

Make sure you choose a secure password, as this will be the password for your PostgreSQL Database.

It will take a few minutes for Supabase to provision all the bits in the background, but this page conveniently displays all the values we need to get our Next.js app configured.

You can also get them anytime from your project's API settings.

Add these values to the

.env.local

file:

NEXT_PUBLIC_SUPABASE_URL=your-url
NEXT_PUBLIC_SUPABASE_ANON_KEY=your-anon-public-key
SUPABASE_SIGNING_SECRET=your-jwt-secret

Prepending an environment variable with

NEXT_PUBLIC_

makes it available in the Next.js client. All other values will only be available in

getStaticProps

,

getServerSideProps

, and serverless functions in the

pages/api/

directory.

Adding new values to the

.env.local

file requires a restart of the Next.js dev server.

Hopefully, that stalled you long enough for provisioning to complete, and your Supabase project is ready to go.

Click the

Table editor

icon in the sidebar menu and select

+ Create a new table

.

Create a

todos

table and add columns for

content

,

user_id

, and

is_complete

.

• content

  will be the text displayed for our todo.

• user_id

  will be the user that owns the todo.

• is_complete

  will signify whether the todo is done yet. We are setting the default value to

  false

  , as we would assume for a new todo.

Leave

Row Level Security

disabled for now. We will worry about this later.

Click

Insert row

to create some example

todos

.

We can leave

user_id

blank and the default value of

false

for

is_complete

.

Let's head back to our Next.js application and install the

supabase-js

library:

npm i @supabase/supabase-js

Create a new folder called

utils

and add a file called

supabase.js

:

// utils/supabase.js

import { createClient } from "@supabase/supabase-js";

const getSupabase = () => {
  const supabase = createClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL,
    process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY
  );

  return supabase;
};

export { getSupabase };

We are making this a function as we will need to extend it later.

This function uses the environment variables we declared earlier to create a new Supabase client. Let's use our new client to fetch

todos

in

pages/index.js

.

We can pass a configuration object to the

withPageAuthRequired

function and declare our own

getServerSideProps

function, which will only run if the user is signed in.

// pages/index.js

export const getServerSideProps = withPageAuthRequired({
  async getServerSideProps() {
    const supabase = getSupabase();

    const { data: todos } = await supabase.from("todos").select();

    return {
      props: { todos },
    };
  },
});

We need to remember to import the

getSupabase

function:

import { getSupabase } from "../utils/supabase";

And now, we can iterate over our

todos

and display them in our component:

const Index = ({ user, todos }) => {
  return (
    <div className={styles.container}>
      <p>
        Welcome {user.name}! <Link href="/api/auth/logout">Logout</Link>
      </p>
      {todos.map((todo) => (
        <p key={todo.id}>{todo.content}</p>
      ))}
    </div>
  );
};

We can also handle the case where there are no

todos

to display:

const Index = ({ user, todos }) => {
  return (
    <div className={styles.container}>
      <p>
        Welcome {user.name}! <Link href="/api/auth/logout">Logout</Link>
      </p>
      {todos?.length > 0 ? (
        todos.map((todo) => <p key={todo.id}>{todo.content}</p>)
      ) : (
        <p>You have completed all todos!</p>
      )}
    </div>
  );
};

The

todos?.length

statement is using Optional Chaining. This is a fallback in case the

todos

prop is

undefined

or

null

.

Our whole component should look something like this:

// pages/index.js

import styles from "../styles/Home.module.css";
import { withPageAuthRequired } from "@auth0/nextjs-auth0";
import { getSupabase } from "../utils/supabase";
import Link from "next/link";

const Index = ({ user, todos }) => {
  return (
    <div className={styles.container}>
      <p>
        Welcome {user.name}! <Link href="/api/auth/logout">Logout</Link>
      </p>
      {todos?.length > 0 ? (
        todos.map((todo) => <p key={todo.id}>{todo.content}</p>)
      ) : (
        <p>You have completed all todos!</p>
      )}
    </div>
  );
};

export const getServerSideProps = withPageAuthRequired({
  async getServerSideProps() {
    const supabase = getSupabase();

    const { data: todos } = await supabase.from("todos").select();

    return {
      props: { todos },
    };
  },
});

export default Index;

Awesome! We should now be seeing our todos in our Next.js app.

But wait, we see all the todos.

We only want users to see their todos. For this, we need to implement authorization. Let's create a helper function in Postgres to extract the currently logged-in user from the request's JWT.

PostgreSQL Functions

Head back to the Supabase dashboard, click

SQL Editor

in the side panel, and select

New query

. This will create a snippet entitled

Untitled query

. Add the following SQL blob and click

RUN

.

create or replace function auth.user_id() returns text as $$
  select nullif(current_setting('request.jwt.claims', true)::json->>'userId', '')::text;
$$ language sql stable;

Okay, this one may look a little intimidating. Let's break down the bits we need to understand:

1. We are creating a new function called

   user_id

   .
2. The

   auth.

   part is just a way to namespace it as it is related to auth — also called a schema and is a convention in Postgres.
3. This function will return a

   text

   value.
4. The body of the function is fetching the value from the

   userId

   field of the

   jwt

   that came along with the

   request

   . We will talk about JWTs later in the article.
5. If there is no

   request.jwt.claim.userId

   , we are just returning an empty string —

   ''

   .

Not that scary!

Check out this video on Postgres functions to learn more.

Let's enable

Row Level Security

and use our new function to ensure only users who own the

todo

can see it.

Row Level Security

Because Supabase is just a PostgreSQL Database under the hood, we can take advantage of a killer feature — Row Level Security (RLS). RLS allows us to write authorization rules in the database itself, which can be much more efficient and much more secure!

Head back to the Supabase dashboard, and from the side panel, select

Authentication

>

Policies

and click

Enable RLS

for the

todos

table.

Now, if we refresh our application, we will see the empty state message.

Where did our

todos

go?

By default, RLS will deny access to all rows. If we want a user to see their

todos

we need to write a policy.

Back in the Supabase dashboard, click

New Policy

, then

Create a policy from scratch

and fill in the following:

This might look a little unfamiliar, so let's break it down.

1. We are giving our policy a

   name

   . This can be anything.
2. We declare which actions we would like to enable. Since we want users to be able to read their own

   todos

   , we are choosing

   SELECT

   .
3. Target roles allow us to scope down the policy even further, but we can just leave it as the default of

   public

   .
4. We need to specify a condition that can be

   true

   or

   false

   . If it evaluates to

   true

   the action will be allowed. Otherwise, it will continue to be denied.
5. We call our

   auth.user_id()

   function to get the currently logged-in user's

   id

   and compare it to the

   user_id

   column for this

   todo

   .

I recommend checking out this video to learn more about how awesome and powerful Row Level Security is in Supabase.

Click

Review

to see the SQL that is being generated for us.

Not even scary. It has just formatted the fields we entered into the correct SQL syntax.

While we're here, let's add a policy for creating new

todos

. This will be an

INSERT

action:

While we probably want to permit users to perform all CRUD actions, it is good practice to specify separate policies rather than selecting

ALL

. This makes them easier to extend and remove in the future.

Our application does not yet need to be able to update or delete

todos

; therefore, we will not create policies for these actions.

It is good security practice to enable the minimum amount of permissions for the application to function. We can easily write policies for these actions in the future if we want to enable them.

Let's see if we can view our todos yet by refreshing our Next.js app.

Still no todos 🙁 Did we mess something up?

No! We just need to add a little bit more glue to transform the JWT that Auth0 is giving our Next.js application to the format that Supabase is expecting.

What is a JWT?

To understand this problem, we must first understand what a JWT is. A JWT encodes a JSON object into a big string that we can use to send data between different services.

By default, the data in a JWT is not encrypted or private, just encoded.

Aditya Shukla wrote a great article about the differences between encoding, encryption, and hashing. Give it a read to learn more.

This is an example taken from jwt.io — a great tool for working with JWTs. On the left, we can see the JWT value. On the right, we can see what each part represents when decoded. We have some header information about how the JWT was encoded, the payload of user data, and a signature that can be used to

verify

the token.

Don't put secret things in a JWT!!

The reason we can trust JWTs for authentication is that we can

sign

it using a secret value. This value is run through an algorithm with the payload data, and a JWT string comes out the other side. We can use the signing secret to

verify

the JWT on our server. This ensures that an attacker hasn't tinkered with our token in transit. If they have, the value of the JWT will be different, and it will fail verification.

The only way it could be modified and pass the

verify

step is if someone has your signing secret. This would be bad. And this is why we can only sign JWTs with our server — or in the case of Next.js, the

getStaticProps

,

getServerSideProps

or API routes in the

pages/api

directory.

Never expose the signing secret to the client!!

Okay, so now that we understand JWTs, what is the problem?

The signing secret used by Auth0 does not match Supabase's signing secret. While we're not using Supabase for authentication, it still uses the secret to verify the JWT each time we request data. Neither of these services makes the signing secret's value configurable.

To solve this problem, we can just grab the

sub

property — the user's ID — from Auth0 and

sign

a new token using the signing secret that Supabase is expecting.

Signing a JWT

When working with JWTs, we want to use a well-trusted library from a reputable source. Auth0 has a very widely used and trusted one called

jsonwebtoken

.

Let's install it:

npm i jsonwebtoken

We can use another hook that the

@auth0/nextjs-auth0

library gives us to run some logic after the user signs in. This is called

afterCallback

and can be passed as a configuration to our

handleAuth

function. Let's replace the contents of the

pages/api/auth/[...auth0].js

file with:

// pages/api/auth/[...auth0].js

import { handleAuth, handleCallback } from "@auth0/nextjs-auth0";

const afterCallback = async (req, res, session) => {
  // do some stuff
  // modify the session

  return session;
};

export default handleAuth({
  async callback(req, res) {
    try {
      await handleCallback(req, res, { afterCallback });
    } catch (error) {
      res.status(error.status || 500).end(error.message);
    }
  },
});

In this function, we want to:

1. get the user object from Auth0's session
2. create a new payload
3. sign a new token using Supabase's signing secret

Let's extend our

afterCallback

function to perform this logic:

// pages/api/auth/[...auth0].js

// other imports
import jwt from "jsonwebtoken";

const afterCallback = async (req, res, session) => {
  const payload = {
    userId: session.user.sub,
    exp: Math.floor(Date.now() / 1000) + 60 * 60,
  };

  session.user.accessToken = jwt.sign(
    payload,
    process.env.SUPABASE_SIGNING_SECRET
  );

  return session;
};

The

sub

field represents Auth0's unique ID for this user. Since this is the only value we actually need to tell Supabase who our user is, we can create a new payload that contains only this value.

It is good security practice to only give things the minimum amount of data and permissions they need to handle the task.

Additionally, we are setting an expiry for our token — 1 hour. This means that if someone does get a hold of our token, they do not have access to our database indefinitely.

Lastly, we are signing a new token with that payload using the

SUPABASE_SIGNING_SECRET

.

Awesome! Our whole file should look something like this:

// pages/api/auth/[...auth0].js

import { handleAuth, handleCallback } from "@auth0/nextjs-auth0";
import jwt from "jsonwebtoken";

const afterCallback = async (req, res, session) => {
  const payload = {
    userId: session.user.sub,
    exp: Math.floor(Date.now() / 1000) + 60 * 60,
  };

  session.user.accessToken = jwt.sign(
    payload,
    process.env.SUPABASE_SIGNING_SECRET
  );

  return session;
};

export default handleAuth({
  async callback(req, res) {
    try {
      await handleCallback(req, res, { afterCallback });
    } catch (error) {
      res.status(error.status || 500).end(error.message);
    }
  },
});

Let's extend our

getSupabase

function in

utils/supabase.js

to accept an

accessToken

parameter.

// utils/supabase.js

import { createClient } from "@supabase/supabase-js";

const getSupabase = async (accessToken) => {
  const supabase = createClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL,
    process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY,
    {
      global: {
        headers: {
          Authorization: `Bearer ${accessToken}`,
        },
      },
    }
  );

  return supabase;
};

export { getSupabase };

Now we can attach an

accessToken

from an external source - like Auth0 - and this will be sent along with all requests to Supabase, making it available to our

select

and

insert

RLS policies.

Let's extend our

getServerSideProps

function in

pages/index.js

to get the

accessToken

from the session's user and pass it to the

getSupabase

function:

// pages/index.js

export const getServerSideProps = withPageAuthRequired({
  async getServerSideProps({ req, res }) {
    const {
      user: { accessToken },
    } = await getSession(req, res);

    const supabase = getSupabase(accessToken);

    const { data: todos } = await supabase.from("todos").select();

    return {
      props: { todos },
    };
  },
});

We also need to remember to add

getSession

to the import from

@auth0/nextjs-auth0

:

import { withPageAuthRequired, getSession } from "@auth0/nextjs-auth0";

Our whole component should look something like this:

// pages/index.js

import styles from "../styles/Home.module.css";
import { withPageAuthRequired, getSession } from "@auth0/nextjs-auth0";
import { getSupabase } from "../utils/supabase";
import Link from "next/link";

const Index = ({ user, todos }) => {
  return (
    <div className={styles.container}>
      <p>
        Welcome {user.name}! <Link href="/api/auth/logout">Logout</Link>
      </p>
      {todos?.length > 0 ? (
        todos.map((todo) => <p key={todo.id}>{todo.content}</p>)
      ) : (
        <p>You have completed all todos!</p>
      )}
    </div>
  );
};

export const getServerSideProps = withPageAuthRequired({
  async getServerSideProps({ req, res }) {
    const {
      user: { accessToken },
    } = await getSession(req, res);

    const supabase = await getSupabase(accessToken);

    const { data: todos } = await supabase.from("todos").select();

    return {
      props: { todos },
    };
  },
});

export default Index;

Since Auth0's

afterCallback

function runs after the user signs in, we need to log out of our application by clicking the

Logout

link on the landing page or manually navigating to

http://localhost:3000/api/auth/logout

.

This will sign us out and automatically redirect us to Auth0's sign in page.

Sign back in, and we should have our new JWT attached to our Auth0 session's user.

Now when we refresh our application, we should finally see todos.

Nope!

But we are very close. If we look at the

Table Editor

in the Supabase dashboard, who is the user that owns the todos?

NULL!!

So we just need to find out what our current

user_id

is and add it to those rows.

Head back to the Auth0 dashboard, click

User Management

>

Users

in the sidebar, and select your user.

The

user_id

is displayed at the top of your user's details page.

Let's copy this value and paste it as the

user_id

for the

todos

.

Refresh our Next.js application.

Voilà! Todos!!!

The last thing we need to implement is the functionality to add a

todo

.

Let's add the form logic to our

pages/index.js

component.

// pages/index.js

// other imports
const Index = ({ user, todos }) => {
  const [content, setContent] = useState("");
  const [allTodos, setAllTodos] = useState([...todos]);

  const handleSubmit = async (e) => {
    e.preventDefault();
    const supabase = await getSupabase(user.accessToken);

    const { data } = await supabase
      .from("todos")
      .insert({ content, user_id: user.sub })
      .select();

    setAllTodos([...todos, data[0]]);
    setContent("");
  };

  return (
    <div className={styles.container}>
      <p>
        Welcome {user.name}! <Link href="/api/auth/logout">Logout</Link>
      </p>
      <form onSubmit={handleSubmit}>
        <input onChange={(e) => setContent(e.target.value)} value={content} />
        <button>Add</button>
      </form>
      {allTodos?.length > 0 ? (
        allTodos.map((todo) => <p key={todo.id}>{todo.content}</p>)
      ) : (
        <p>You have completed all todos!</p>
      )}
    </div>
  );
};

// exports

Our final component should look something like this:

// pages/index.js

import styles from "../styles/Home.module.css";
import { withPageAuthRequired, getSession } from "@auth0/nextjs-auth0";
import { getSupabase } from "../utils/supabase";
import Link from "next/link";
import { useState } from "react";

const Index = ({ user, todos }) => {
  const [content, setContent] = useState("");
  const [allTodos, setAllTodos] = useState([...todos]);

  const handleSubmit = async (e) => {
    e.preventDefault();
    const supabase = await getSupabase(user.accessToken);

    const { data } = await supabase
      .from("todos")
      .insert({ content, user_id: user.sub })
      .select();

    setAllTodos([...todos, data[0]]);
    setContent("");
  };

  return (
    <div className={styles.container}>
      <p>
        Welcome {user.name}! <Link href="/api/auth/logout">Logout</Link>
      </p>
      <form onSubmit={handleSubmit}>
        <input onChange={(e) => setContent(e.target.value)} value={content} />
        <button>Add</button>
      </form>
      {allTodos?.length > 0 ? (
        allTodos.map((todo) => <p key={todo.id}>{todo.content}</p>)
      ) : (
        <p>You have completed all todos!</p>
      )}
    </div>
  );
};

export const getServerSideProps = withPageAuthRequired({
  async getServerSideProps({ req, res }) {
    const {
      user: { accessToken },
    } = await getSession(req, res);

    const supabase = await getSupabase(accessToken);

    const { data: todos } = await supabase.from("todos").select();

    return {
      props: { todos },
    };
  },
});

export default Index;

We now have an input field above our list of

todos

. When we enter the

content

for our todo and click

add

, a new

todo

will be inserted into our DB. We are also setting the

user_id

column to the value of our

user.sub

, so we know who the

todo

belongs to.

We're introducing

allTodos

so that we can call

setAllTodos

after the insertion of a new

todo

. It will trigger a partial re-render, displaying the newly inserted

todo

without a full page refresh.

Awesome! We now have a Next.js application using Auth0 for all things authentication and Supabase with RLS policies for authorization. We learned about JWTs and how to sign our own, as well as writing a Postgres function to look up values in a JWT in our database.

If you liked this article, follow me on Twitter, check out my blog, and subscribe to my newsletter for exclusive content and early access to courses.

For all things Supabase follow our Twitter, subscribe to the YouTube channel, and check out our blog.

Thanks for reading!