Share Auth Session between NextJs Multi-zones apps using NextAuth.js

Badjessa Roméo Bahoumda
4 min readMar 21, 2022

--

Imagine you have a store web application. As your store grows, maintaining the customer experience and the administrative work done in the same application can get challenging (especially if that’s done by different teams). How do we go about solving this issue?

One way of designing this system would be to split the project into two applications; A customer facing app which takes care of the user experience and an internal facing app which allows your employees to manage things such as vendors, products etc…

NextJs Multi-zone allows you to split a big project into small pieces and even run them separately while they appear as a unified application to your user base (customers and internal employees).

Now that we resolved this issue, how do we share the authentication session of a user (an admin for example) between the two applications given that they aren’t in the same deployment container anymore? Let’s find out below!

Authentication Problem

NextAuth.js is a wonderful library that provides you with out of the box resources to handle the authentication process in your NextJs app. While this works great for just a single application, sharing a user session between apps gets a little gnarly and in this article we aim to make this process a bit clearer.

Requirements

For this article I am making a couple of assumptions:

  • Familiarity with NextJs
  • Familiarity with NextAuth.js
  • A custom credential provider is used in your NextAuth.js configuration
  • Either one or both app are in a subdomain of your application

Set Up Authentication for the first Application

We need to setup the authentication process in our initial application.

Setting up authentication using NextAuth.js is pretty straightforward, you first need to create a […nextauth].js in yourapi/auth folder

Since we know that our apps will either be the main domain or a subdomain. we make sure to store the session cookie under the domain .ourdomain.com by extracting the domain from our NEXTAUTHURL in getDomainWithoutSubDomain . This way, we make the cookie accessible to all subdomains including our second application.

We’ll see how that works later (:

This is a typical set up to allow NextAuth.js to authenticate our users. To log our users in, we can simply call the signin method in our log in form. This will call our custom backend and use our defined callbacks jwt and session to massage the data into an appropriate format before storing it in a browser cookie.

We are done for the first application, we should now be able to login in our initial App. You can get more information on how all this works here https://next-auth.js.org/getting-started/example

Sharing the authentication token

NextAuth.js stores the authentication cookies inside of our browser. Below is an example of what it looks like for beta.udeesa.org

Cookies in the browser

After logging in, a couple of values are stored in our cookies. In our case, we care about our session token (…next.auth.session-token) because it allows us to verify that our user has successfully been authenticated and we can fetch user data.

Setting up App #2

In our second app, we need to setup NextAuth but this time we do it a bit differently. As we did previously, we create a [...nextauth].js file to handle the authentication process in this app.

You’ll notice that the authorize function is empty here, the goal of this file is to describe how to grab the session. Authorizing our users should only be done by our main application.

Note: The secret used here should be the same as the one in the initial application.

Create a HOC component to check that the user is authenticated

Since we want the pages in app #2 to be accessed when the user is authenticated. We can create a Higher Order Component and either wrap our entire app or the appropriate component around it. We can now check that our user is logged in or redirect him to our login page if need be.

useSession will check the cookies for any session token in the domain example.com . Our user already logged in app #1 so the session will exists and app #2 can then fetch the user information and manipulate said data as it sees fit.

And that’s it, the session token can now be shared between both our application and there is a single entry point for logging in.

Don’t forget to like if you enjoyed the blog!

--

--

Badjessa Roméo Bahoumda

Software Engineer, CTO of Udeesa Systemic & Technology. My interest lies in Software Engineering, XR technologies and applications and Game Development