Ah yes, authentication.

The staple of all web application. It's all started because human are so mischievous towards each other that we ended up with common agreement that we should not trust anyone in the internet. Not even yourself. All because human has something that's really exclusive compared to all other living beings; ability to reason. We have evolved from simple living being that survive using rocks and bones into the only living being that can catapult a bunch of irons to a celestial body. And that is a great thing!

But obviously, I'm not here to talk about how humanity thrives and evolves. I'm talking about how human is capable of deceiving others and ended up gaining advantage over others' disadvantage. And mostly, it's our own fault. It's our own fault for not protecting what should be protected. Whether something real or immaterial. Like a web app. What a mental gymnastics. But that's the essence of web security, right? To never trust the user and to always implement some sort of authentication to prove that someone that logs in is indeed someone we know.

NextAuth

To actually address the need of authentication, we should address first what is the requirement of the said authentication. Yeah, that sounds very jumbled. But to explain simply; we need to specify what should we protect. Obviously when it's a web app, it's going to be published and accessible through the internet and there must be a portion where everyone can see. Like the front of our house! Anyone (that's passing) can see it, but obviously they cannot get inside because they don't have any key. And to implement the security system we can make one from scratch, or we can just use pre-made keylocks available in the market. And NextAuth is one of them.

NextAuth (stylized as NextAuth.js) is one of packages that handles authentication and made specifically for Next.js. Recently they're moving out from vendor lock so it's usable from anywhere, but since this blog is already made using Next.js, there is no much hassle to actually implement the authentication using this library.

// Route /api/auth/[...nextauth]/route.ts

import { UserByUsername } from "@/lib/User";
import NextAuth, { AuthOptions } from "next-auth";
import CredentialsProvider from "next-auth/providers/credentials";
import bcrypt from "bcrypt";


export const authOptions: AuthOptions = {
    providers: [
        CredentialsProvider({
            name: "credentials",
            credentials: {
                username: {
                    label: "Username",
                    type: "text",
                    placeholder: "frieren",
                },
                password: {
                    label: "Password",
                    type: "password",
                },
            },
            async authorize(credentials, req) {
                if (!credentials) return null;
                const user = await UserByUsername(credentials?.username);
                if (!user) return null;
                const match = bcrypt.compareSync(
                    credentials.password,
                    user.password
                );
                if (!match) return null;
                return user;
            },
        }),
    ],
};


const handler = NextAuth(authOptions);


export { handler as GET, handler as POST };

Integration

Probably one of the obvious step is to actually use the auth system in our application. So far, I pointed 3 main sections where we need to take caution on how to implement the auth system: Login page, Admin Dashboard, and API routes.

Login Page

The design of the login page that I desired need to fulfill these criterias :

It can do log in (duh...)
It can determine if current user already has the authorization token so it can redirect to dashboard
Point 2, but it happened instantly without any flash of login page first.

The first one was to implement the login page. For this, I used react-hook-form as my go-to library for anything that will make form request. It comes with many useful features and helper function to enhance the UX, so you better check it out.

I decided to use Material UI for building my dashboard. I wanted something fancy and I think it can already did the job with wonder. And with react-hook-form , I used the Controller component provided by the library to make my MUI input components able to be connected with react-hook-form . And for the submit handler, I used the signIn function provided by next-auth library to simplify the process for logging in. Don't worry, it's a client-side component so it won't carry any server-side information to the user.

// Login.tsx


/* eslint-disable react/no-unescaped-entities */
"use client";


import React, { useState } from "react";
import { useRouter } from "next/navigation";
import { signIn, useSession } from "next-auth/react";
import { toast } from "react-toastify";
import { useForm, Controller } from "react-hook-form";

import "./shadow.css";


export default function Login() {
    const router = useRouter();
    const { status } = useSession();
    const { handleSubmit, control } = useForm();
    const [loading, isLoading] = useState(false);
    const submit = async (data: any) => {
        isLoading(true);
        const res = await signIn("credentials", {
            username: data.username,
            password: data.password,
            redirect: false,
        });
        if (res && res.ok) router.push("/dashboard/main");
        else toast.error("Unsuccessful login");
        isLoading(false);
    };


    if (status === "authenticated") {
        router.push("/dashboard/main");
    }


    return (
        // omitted for clarity
    );
}

And by that, it should be able to fulfil what the first criteria wants. But how about the second criteria?

The demand is that it's able to detect whether our user already has the authorization token so it can automatically redirect the user to dashboard page instead. At first, this could be done by adding useEffect hook with zero dependency (basically componentDidMount part) to create API request just to check if user has logged in or not. I created a me API for checking this, but I felt that not only it's going to increase API requests, we also need to wait for the login page to fully load first. This is not only wasting so many time and bandwidth, but also giving bad UX for user. User will see the login page for a split second then it redirects to dashboard page.

How to solve this is to leverage the React Server Component (RSC), which is something that Next.js 13 is really pushing forward. One of the feature of RSC is you can check for headers or cookies, and let you decide whether to redirect user (using redirect function) or to serve user a content. Our strategy will employ these new flows enabled by RSC.

// Page /dashboard/page.tsx

import { authOptions } from "@/app/api/auth/[...nextauth]/route";
import prisma from "@/utils/prisma";
import { Metadata } from "next";
import { getServerSession } from "next-auth";
import { redirect } from "next/navigation";
import Login from "./Login";


export const metadata: Metadata = {
    title: "Login",
    description: "Login page",
};


export default async function Page() {
    const session = await getServerSession(authOptions);
    if (session) {
        redirect("/dashboard/main");
    }

    return (
        // react component that will return <Login /> component described above
    );
}

With that, the point 2 and 3 of the criteria can be marked as done.

Dashboard Section and API routes

The dashboard section is where user will do most of the management tasks, including CRUD operation to posts, doing some configuration stuff, and many others. As it relates to something that should be protected to certain users only, all request to the dashboard section need to be protected. This is also the same with API routes.

Fortunately, next-auth also provides built-in middleware that works with the new middleware system introduced in Next.js 12. We can just create middleware.ts in our project root directory (or src directory if you use that), and later add scopes so it still leave some routes public.

// middleware.ts

export { default } from "next-auth/middleware";


export const config = {
    matcher: ["/dashboard/(.*)", "/api/dashboardv2(.*)"],
};

One caveat in here is that API access to protected routes will instead redirect user to login page instead of replying with HTTP 401 responses. This is not good as it adds more unnecessary processing and bandwidth usage. This caveat will be addressed in next posts.

Closing

With that said, we have done adding authentication system to our Next.js app! What is missing currently is Role-based Access Control (RBAC) so we can have users with different permission sets. I'll try to address that later in the development process.

Still more of things to improve, but it's nice to have it incrementally, slow but surely.

Loading...

There will be awesome contents here

Log 0x18: Using NextAuth.js to Add Authentication System on Next.js 13