Need to understand what is the difference between this library approach and "normal" JWT in local storage

[zoamel]

Question 💬

Hi everyone!

I and my friend have recently started our new side project with Next.js on the frontend and Nest.js (Express) in the backend. I started with implementing REST API with JWT Auth, using a common approach with getting token via Bearer in the headers.

And this is where problems started to occur 🙂

I started reading about what is recommended approach for handling authentication in the Next.js app, and all of the documentation and articles told me to use either next-auth or iron-session or some 3rd party like firebase and auth0. I am interested in keeping everything under our control, so at this point, I was left with 2 first approaches.

As I understand having a cookie session with httpOnly is more secure than having it stored in the local storage. But apart from that, I have few questions that about things that are not clear to me.

1. Apart from security, why is this approach better than the more common one with local storage? I mean in a situation when I have multiple public pages, which don't need authentication and only a few to which you should be logged in. I assume, since the private pages can be client-side only, we could skip the additional hassle of handling cookies.
2. Another head-scratching part is how to handle "normal" HTTP requests to our REST API which will be in completely different places and URL. All of the tutorials I've found use Next.js API routes to handle authentication, which I am ok with. But how to use this approach to call external API and pass token to it? Should I proxy all the calls via Next.js API routes, in that case, extract the token from next-auth and attach it to the API request?
3. The Last thing is not that important at this point, but when I am going to use the Prisma scheme for next-auth how should the work with API work in that case? Should just check if the token is still valid via the DB call on the backend and replace this with JWT strategy?

If you could point to some example project/code, it would be awesome 🙂

[jimmiejackson414-zz]

Did you happen to ever find anything out, specifically regarding #2? I'm struggling here as well.

[svrakata]

I would like to know how people deal with the second problem aswell. We've put the external api calls at client when using credentials provider but have problem with other providers like google. Is it ok to make http requests in the callbacks and it's not clear (for me) how to handle errors from there. Thanks.

[Dragate]

We usually have the frontend (Next.js) seperate from the backend (PHP) because we do not want to expose anything about the backend to the client, so client-side external API calls would not work for us. Using Next.js API routes to handle authenticated API calls has worked like a charm for quite a few projects of ours. As suggested by the OP, we're injecting some user-identifying information to the header and proxying the request to the backend. In older projects, we used to extract and pass the JWT token, but we did not like that we also had to deal with JWT logic in the backend to get the user ID. In later projects, we're passing the user ID directly (the backend is not exposed to the outside world), so it's easier to manage auth logic in one place in the frontend.

For this example, we used an API route located in pages/api/external/[...slug].js to proxy all requests that started with external keyword. xfwd was used so the backend can keep a log of client IP.

import httpProxyMiddleware from "next-http-proxy-middleware"
import { getSession } from "next-auth/client"

export const config = {
    api: {
        bodyParser: false,
    },
}

export default async function (req, res) {
    const session = await getSession({ req })

    return session
        ? httpProxyMiddleware(req, res, {
            xfwd: true,
            target: process.env.API_URL,
            pathRewrite: {
                "^/api/external": "/api",
            },
            headers: {
                "X-Member-Id": session.id,
            },
        })
        : res.status(401).send("You are not authorized to view this content.")
}

[jacklimwenjie]

That's odd, next.js server crashes frequently on my local after doing this. I was convinced that this is a memory leak issue after seeing this issue

Do you mind to share your next and next-auth version?

[Dragate]

Do you mind to share your next and next-auth version?

We got a couple repos with this same setup, all with different versions. Two that have been working for a couple of months without our intervention are at

• [email protected] [email protected]
• [email protected] [email protected]

A recent one that we released is at

• [email protected] [email protected]

[jacklimwenjie]

Thank you so much for sharing!

Then I think it's now down to either there's an issue with my setup, or the issue only happens for certain use cases.

Do you happen to call any external APIs in the getServerSideProps?

[Dragate]

Do you happen to call any external APIs in the getServerSideProps?

Only when the external endpoint is a 3rd party service (e.g. Google APIs).

[jacklimwenjie]

I see, this could be a difference because I am calling our own backend REST API in getServerSideProps as well for SSR.

The reason why I am interested in this approach is my setup has a refresh token cycle issue that I couldn't resolve. I have tried the official guide for it but to no avail. I will try this approach again.

I really appreciate you took the time to answer all of my questions.