next-auth without next.js

[pie6k]

First, I know from the FAQ (https://next-auth.js.org/faq)

Can I use NextAuth.js with a website that does not use Next.js?

NextAuth.js is designed for use with Next.js and Serverless.

...

Knowing that I still think this is a big potential loss and actually, there is no strong reason for this

Most of the things next-auth is doing are actually independent of next.js. Also, being framework-agnostic would still keep it serverless capable.

I think it could consist of 90% core, agnostic code that can work with any framework, and then only have a bridge that links it with "next.js" + links for other solutions like raw HTTP or express servers.

Potentially it'd be up to the user to create a pages/auth/error component that can use the useAuthErrorInfo hook or simply read it from URL query. It could also be

// pages/auth/error.ts // or any custom path
import { DefaultAuthErrorPageComponent } from 'next-auth/next'

export default DefaultAuthErrorPageComponent;

I was researching existing solutions like passport.js and it feels like none of them has all of the features that next.js has at once:

• being able to handle OAuth sessions with JWT easily
• having client-side integration for fetching session and performing login with redirect
• having a sweet spot of abstraction level with DB integration callbacks, modifying JWT payload, etc

---

I know it is possible to use next-auth as a standalone, small next.js app that only has pages/api for the next auth and nothing else. Then it is relatively simple to integrate any frontend with it. But it actually sounds like another point supporting the idea that this could easily be a backend agnostic solution.

We'd have

// base.ts

// Entire next.js configuration here, nearly identical to the current one, or even 100% identical.
export const nextConfig: NextConfig = {
  jwt,
  session,
  pages,
  callbacks,
  ...etc
};

For next.js:

// pages/api/auth/[...nextAuth].ts
import { createNextJSHandler } from 'next-auth/next';
import { nextConfig } from '~app/base.ts'; // or simply inline it here so it looks nearly identical as right now

const nextHandler = createNextJSHandler(nextConfig);

export default nextHandler;

For express or raw HTTP server:

// or express/api
import { createNextHttpHandler } from 'next-auth/http';
import { nextConfig } from '~app/base.ts';

expressApp.use("/auth", createNextHttpHandler(nextConfig));

Note - I intentionally extracted config to another file to show config is actually really independent from next.js. Usually, it'd be inlined in auth handler file.

and similarly on the client-side, where session provider or use session pretty much only needs endpoint to connect with backend to get/verify/fetch session and where to go to perform login and where to return with redirects.

for NextApiRequest types - NextApiRequest is actually just a default node HTTP request type with a few extra additions, that could be easily replaced with default types of the HTTP requests.

It feels like next-auth only depends on next.js for 'last mile' stuff like automatically pointing to proper endpoints or having error pages out of the box (which could be easily solved with DefaultErrorComponent used by the user to pages/auth/error.ts folder)

What do you think? I think this would unlock next-auth to be way more widely used.

I actually wonder if this is possible with a bit of hacking to modify handler from [...nextAuth] to be 'injectable' into express.js handler

Fun fact: next-auth name would still make a lot of sense :)

[jastardev]

The Creators/maintainers can correct me if I'm wrong, but I'm pretty sure they agree with you. There's other discussions along the same lines from 6+ months ago and that's why in V4, it was switched from "next-auth/client" to "next-auth/react", because it can be used with pure react apps.

[balazsorban44]

Have you seen this? ☺

#2294