Discuss NextAuth.js v5

[balazsorban44]

Let's discuss #7443 here.

Keep the PR comments to discuss actual issues/concerns about the ongoing implementation. You can ask for help specific to your project here, or if you are not sure why something isn't working.

[yekdagets]

@balazsorban44 I got the latest version and i want to provide multi-authentication in my app(manuel one and Google provider). In middleware i use auth() as getting session data but i got web:dev: - error ../node_modules/oidc-token-hash/lib/shake256.js (3:0) @ <unknown> web:dev: - error Cannot read properties of undefined (reading 'substring')

[balazsorban44]

"overrides": {
  "@auth/core": "0.13.0"
}

should not be needed anymore either

[mattiaz9]

I have this issue with the latest version 0.0.0-manual.ffd05533 and the overrides don't work

[psykhi]

@yekdagets did you end up fixing this? Am in the same situation now : client component that runs const session = await auth(). It works... sometimes?

[jyaru1110]

auth works server side, so if you want to use auth in client component you can declare a function on another file with 'use server' at the top something like this

'use server'
import {auth} from '@/auth';

export async function getSession() {
const session = await auth();
return session;
}

and you can import getSession in a client component, hope this help you

[GarrettBeatty]

I was looking everywhere for how to do this. thank you so much!

[samtgarson]

@balazsorban44 is OAuth va OIDC supported on the edge runtime with v5? I've only seen credential provider and email-http provider mentioned so far.

I've hit the following error when using auth as middleware with the Google provider:

web:dev: - error ../node_modules/oidc-token-hash/lib/shake256.js (3:0) @ <unknown>
web:dev: - error Cannot read properties of undefined (reading 'substring')

It looks like this has been raised before (1 2), but issues were closed without fixes.

It seems logical as oidc-token-hash accesses process.version, which isn't available in the Edge runtime which Middleware uses.

Have I misconfigured something or is this a known issue?

Versions

next@13.4.19
next-auth@0.0.0-pr.7214.998286da
@auth/core@0.12.0
@auth/prisma-adapter@1.0.1

[balazsorban44]

#8487 (reply in thread)

[yekdagets]

@samtgarson did u figure out with Google provider and middleware together?

[samtgarson]

Thanks @balazsorban44, I knew it must be something like this. I’ll give it a try this evening and let you know @yekdagets 🤞

[yekdagets]

@samtgarson if u handle it, can you share with us?

[samtgarson]

Cleaning up my versions as described in that linked reply worked (at least, I’ve moved forward to a different error…)

[JanThiel]

Just came across something - maybe - missing?!
What about the Dynamic Route Segments of the app router?

When we try to use the auth() wrapper with a route using a dynamic segment, it fails with a TS error.
The v5 docs do not mention this usecase neither. It just says auth(req). But not auth(req, params) for edge API routes. Without auth they work fine - as expected.

Example

Path: /app/api/entity/[id]/route.ts

export const GET = auth ( async ( request , { params }: { params: { id: number}}): Promise<Response> => {
    return NextResponse.json( {id} ,{
        status: 200,
    })
});

Gives me this TS error:

No overload matches this call.
Overload  1  of  4 ,
(args_0: GetServerSidePropsContext): Promise<Session>
, gave the following error.
Argument of type
(request: any, {params}: {     params: {         id: number;     }; }) => Promise<Response>
is not assignable to parameter of type  GetServerSidePropsContext 
Overload  2  of  4 ,
(args_0: (req: NextAuthRequest) => Response | Promise<Response>): AppRouteHandlerFn
, gave the following error.
Argument of type
(request: any, {params}: {     params: {         id: number;     }; }) => Promise<Response>
is not assignable to parameter of type
(req: NextAuthRequest) => Response | Promise<Response>
Target signature provides too few arguments. Expected  2  or more, but got  1

Did I miss something about this in the PR discussion?

[ctff-kongchang]

I am also getting the same issue as well, when working with my app, it does work, not sure if it's just TypeScript that is complaining.

[4krajesh]

@Dimitry-prog Can you please share a example config? I'm facing the same issue.

[gpbhupinder]

Solution -- Just end the control with a simple return.
After the update the function signature you're using for the middleware does not match what the new auth package expects... so if you don't wanna downgrade from auth beta.9 ... just return a native Response, or just do a simple return without the null.

[HasanVision]

I found out if you combine the middleware with auth.config, it will solve the overload match issue, but I had other issues with callbacks, the best solution is to return if clauses by NextResponse.next(); which works perfectly.

[shahbaz4783]

i have same issue. how can we solve that? any example code? @balazsorban44

[patrickpilch]

What's the latest story with supporting lower level HTTP client options? There was a pretty length discussion #3944 about struggles folks have been running into with corporate proxies. It seemed to boil down to people having to maintain their own fork or patch the library to pass custom HTTP agents.

Luckily my use case #8491 only requires a simple pass through of a Headers object. Unfortunately it doesn't look nearly as simple for those that need proxy support. With the migration to oauth4webapi, the underlying oauth client uses fetch - therefore no agent support.

https://authjs.dev/guides/corporate-proxies/corporate-proxy and the v5 migration guide should probably be updated at the very least.

[LoiKos]

Hi !

I face the same error as above :
Attempted import error: 'raw' is not exported from '@auth/core' (imported as 'raw')..

my package.json:

"@auth/core": "^0.13.0",
 "next-auth": "0.0.0-manual.ffd05533",

I try the override method but it doen't seem to work for me.

[JanThiel]

You do not need the @auth/core as dependency. Just as override. That is a safe fix for the "raw" issue.

How did you setup the override? And what package manager do you use?

[LoiKos]

Thank you I didn't know for @auth/core wasn't needed. I removed it.

I'm using pnpm. Setup:

 "pnpm": {
    "overrides": {
      "@auth/core": "0.13.0"
    }
  }
  

Seems to be working now. Thanks

[balazsorban44]

should not be needed anymore either.

[LoiKos]

Hi! I'm quite new to Nextjs and with next-auth.

I'm currently rewrite an app with Nextjs App router & i'm using Next-Auth v5. You always need to be authenticated to use the app.

I'm facing two main issue with Next-auth at the moment :

1. Redirect to provider login screen instead of next-auth when user is not logged in

Currently i created a /auth/signin/pages.tsx to handle this but i wonder if it's still the suggested way to implement this behaviour.

2. Logout should also log out from the provider

For signout i use server actions :

import { CSRF_experimental } from '@/auth'

export function SignOut(props: any) {
  return (
    <form action='/api/auth/signout' method='post'>
      <button {...props} />
      <CSRF_experimental />
    </form>
  )
}

I think to use the redirect callback to do this but we are not allowed to redirect outside of the app. I don't see how to achieve this with server actions :/

[juliusmarminge]

Been using NextAuth v5 for a while now and overall I'm super happy. However, I have one major issue with this new update, especially regarding the decision not to run the session callback.

What is the recommended way to retrieve more user info in v5 now that the session callback isn't invoked on the server? Before it was trivial to return extra user / session fields from the adapter and have access to that in the session callback, but now it doesn't seem like that's the case. It doesn't matter what my adapter returns, since you cut half of it away anyways... I don't understand this decision since it seems to just make it harder to modify the default behaviors...

Example usecase, I put an orgId on my sessions table that tells what org the user has selected as "active". I want that field to be returned when i call auth(). Or, maybe i have additional fields on the user table, like some defaultCurrency of what currency the user prefers to use. I want that to be returned in the session to prevent needing an additional db call.

Can you shed some light on how to achieve this with this new update? Right now I'm patching next-auth to invoke this callback with all info, as the calls are on the server I don't have to care about leaking this to the client anyways...

Auth core patch:

diff --git a/lib/routes/session.js b/lib/routes/session.js
index e496d921578b735e640d1fc766582831dcbfdb1c..3ce6dcae1c2544fa4f439b551b5cecf3f561ad17 100644
--- a/lib/routes/session.js
+++ b/lib/routes/session.js
@@ -89,9 +89,8 @@ export async function session(params) {
             // Pass Session through to the session callback
             // @ts-expect-error
             const sessionPayload = await callbacks.session({
-                // By default, only exposes a limited subset of information to the client
-                // as needed for presentation purposes (e.g. "you are logged in as...").
                 session: {
+                    ...session,
                     user: { name: user.name, email: user.email, image: user.image },
                     expires: session.expires.toISOString(),
                 },

NextAuth patch:

diff --git a/lib/index.js b/lib/index.js
index 5a75f390e1ed59db192587176cf6fabd229cdf84..d123a9aea1b4d861ae78a23951e1feecf831c57c 100644
--- a/lib/index.js
+++ b/lib/index.js
@@ -9,17 +9,7 @@ async function getSession(headers, config) {
         headers: { cookie: headers.get("cookie") ?? "" },
     });
     config.useSecureCookies ?? (config.useSecureCookies = origin.protocol === "https:");
-    return Auth(request, {
-        ...config,
-        callbacks: {
-            ...config.callbacks,
-            // Since we are server-side, we don't need to filter out the session data
-            // See https://nextjs.authjs.dev/v5#authenticating-server-side
-            session({ session, user, token }) {
-                return { ...session, user: user ?? token };
-            },
-        },
-    });
+    return Auth(request, config);
 }
 function isReqWrapper(arg) {
     return typeof arg === "function";

[JanThiel]

Or simply add your custom fields as columns to the User table if you use a DB Adapter.
You will get all the User columns on the Server without any additional calls.

[michaelhays]

As far as I know, you can't include data from other models for the session, such as a company.

(I updated my example to include a company variable to better demonstrate this)

[juliusmarminge]

A workaround is to switch the strategy from session to jwt, and add extra data to the JSON web token in the jwt callback:

Still dont understand why we cant do the same with sessions...

You will get all the User columns on the Server without any additional calls.

But maybe i dont want to expose all fields?

[michaelhays]

FWIW I totally agree -- I'd love to continue using sessions instead of JWT, but the solution I shared was the only thing that worked for me for the time being.

@balazsorban44 If you could provide any insight on the decision here, or if there is another way to achieve this with sessions, it would be much appreciated!

[KingXP-Pythoner]

This raised my eyebrow for me while reading the v5 docs. Hopefully we can get the reasoning behind this direction.

[david-sabata]

Hi, @balazsorban44, thanks for the v5!

I ran into an issue when deploying it to Cloud Run (basically behind a proxy). The request origin is resolved to localhost instead of the public-facing url. The logic doesn't use the NEXTAUTH_URL env, nor the x-forwarded-for header.

Now, I believe the issue isn't specific for v5. But it seems that there are options to bypass this in v4. Since v5 only exports the handlers and I haven't found a way to build a modified NextRequest myself, there probably isn't a workaround.

What would you suggest as a fix? Should I create an issue/PR for v4? I'm happy to contribute, but would need some hints :)

Edit: The patch below isn't needed. See the thread for a nicer fix!

Here's a hacky patch that I'm currently applying and fixes the issue

--- node_modules/@auth/core/lib/web.js	2023-09-07 12:07:58
+++ node_modules/@auth/core/lib/web.js	2023-09-07 12:07:58
@@ -32,9 +32,12 @@
 
 export async function toInternalRequest(req) {
     try {
+        const reqUrl = new URL(req.url);
+        const origin = process.env.NEXTAUTH_URL ?? reqUrl.origin
+
         // TODO: url.toString() should not include action and providerId
         // see init.ts
-        const url = new URL(req.url.replace(/\/$/, ""));
+        const url = new URL(req.url.replace(reqUrl.origin, origin).replace(/\/$/, ""));
         // FIXME: Upstream issue in Next.js, pathname segments get included as part of the query string
         url.searchParams.delete("nextauth");
         const { pathname } = url;

[juliusmarminge]

Doesn't something like this work?

// api/[...nextauth]/route.ts
import { handlers } from "~/auth"

export const GET = (req: NextRequest) => {
  // do stuff
  const url = ...
  return handlers.GET({...req, url });
}


// ...

[balazsorban44]

Julius' suggestion is the correct way/equivalent of advanced init in a Route Handler. 👍

https://next-auth.js.org/configuration/initialization

[david-sabata]

I tried that earlier, but it doesn't work. That's why I wrote that I cannot construct/modify the request by hand 😞

Maybe I'm missing something. But NextRequest is a class, not a type. The spread operator doesn't work and produces a broken object.

const test = {...req} as NextRequest

console.log({method: test.method, url: test.url})

// log output
{ method: undefined, url: undefined }

That leads to various errors in NextAuth internals, such as

• [auth][error][UnknownAction]: Only GET and POST requests are supported.
• [auth][error][TypeError]: Cannot read properties of undefined (reading 'replace'). Read more at https://errors.authjs.dev#typeerror at toInternalRequest (webpack-internal:///(rsc)/./node_modules/@auth/core/lib/web.js:36:37)

And the same is also signalled by TS

Type error: Argument of type '{ url: string; [INTERNALS]: { cookies: RequestCookies; geo: { city?: string | undefined; country?: string | undefined; region?: string | undefined; latitude?: string | undefined; longitude?: string | undefined; } | undefined; ip?: string | undefined; url: string; nextUrl: NextURL; }; ... 19 more ...; text(): Promise...' is not assignable to parameter of type 'NextRequest'.
  Type '{ url: string; [INTERNALS]: { cookies: RequestCookies; geo: { city?: string | undefined; country?: string | undefined; region?: string | undefined; latitude?: string | undefined; longitude?: string | undefined; } | undefined; ip?: string | undefined; url: string; nextUrl: NextURL; }; ... 19 more ...; text(): Promise...' is missing the following properties from type 'NextRequest': cookies, geo, ip, nextUrl, and 2 more.

[juliusmarminge]

What if you make a new object with your modified URL?

export const GET = (req: NextRequest) => {
  const url = new URL(req.url);
  url.pathname = url.pathname.replace("/api/auth", "");

  return getHandler(new NextRequest(url, req));
};

[david-sabata]

@juliusmarminge yes, that worked! Thank you 🙌

If anyone finds this thread, here's my full [...nextauth]/route.ts fixing the redirect_uri_mismatch issue when running behind a reverse proxy

import {GET as authGET, POST as authPOST} from '@/auth'
import {NextRequest} from 'next/server'

export const GET = (req: NextRequest) => {
    const patchedUrl = patchUrl(req.url)
    return authGET(new NextRequest(patchedUrl, req))
}

export const POST = (req: NextRequest) => {
    const patchedUrl = patchUrl(req.url)
    return authPOST(new NextRequest(patchedUrl, req))
}

/**
 * Next doesn't properly handle requests when behind a proxy (e.g. Cloud Run).
 * There's an existing env var, but it's not used in all places.
 *
 * Here, we patch the url to use the NEXTAUTH_URL env var and leave the rest of the request intact.
 * Hopefully it doesn't break anything, but it's only used for the auth routes.
 */
function patchUrl(url: string) {
    const urlObj = new URL(url)
    const origin = process.env.NEXTAUTH_URL ?? urlObj.origin
    return url.replace(urlObj.origin, origin)
}

[AVDAIN]

[samtgarson]

useSession seems to still work for me in Client Components when using App Router.

In Server Components use auth().

[Punie]

Did something change in the type-definition for the Email provider?

I'm looking to implement the HTTP-based Email provider following this doc but TypeScript is very unhappy that I do not provide the from, server, maxAge and options fields.

It also requires that id: "email" and name: "Email" when type: "email".

It's not a huge deal as I can always do the following:

{
  id: "email",
  type: "email",
  name: "Email",
  from: "",
  server: "",
  maxAge: 60 * 10,
  options: {},
  async sendVerificationRequest(...) { ... },
}

But it feels kinda dirty 😅

[samtgarson]

Related #8601

[robahtou]

@Punie do you happen to have a working example of the email provider that you can share? I keep getting undefined for both the handlers and auth when trying to work with the email provider: const { handlers, auth } = NextAuth(authConfig)

[lveillard]

In my case i had to do it like this

{
			id: 'email',
			type: 'email',
			from: 'auth@example.com',
			server: {},
			maxAge: 24 * 60 * 60,
			name: 'Email',
			options: {},
			sendVerificationRequest: async ({ identifier, url }) => {
				await sendVerificationRequest({ identifier, url });
			},
		},

Also there is no way to change the id to 'mailgun' or whatever, is enforced to be 'id' so you can't have 2 email providers

[samtgarson]

@balazsorban44 since solving the previous issue I've encountered another critical issue, possibly due to my set up but I cannot fathom what I'm doing wrong:

Right now, the OAuth handshake is succeeding and the session is being passed to the frontend correctly (useSession works well and I can see the user data when inspecting the SessionProvider in browser), however auth() on the backend is returning null (in server components, in middleware, etc).

The session and jwt callbacks are receiving user data, but the authorized callback is receiving user as null, even after successfully authenticating.

What's more, the authorized callback only seems to be called on /_next/ routes, not actual application routes meaning I cannot seem to get the app to redirect me to the sign in page when the user is not authenticated on a protected route.

I have done everything I can to ensure the versions of my packages are correct, including clearing my lock file. I currently only have next-auth: experimental and @auth/prisma-adapter specified in my package.json file, with the following versions installed:

next-auth@0.0.0-manual.ffd05533
@auth/core@0.13.0
@auth/prisma-adapter@1.0.2

[balazsorban44]

Likely same as #7423 (comment)

auth is roughly the same thing as getServerSession

[samtgarson]

auth is null in all requests to the application, directly from the browser. Not a specific request to a route handler.

[samtgarson]

headers() in the RSC page component are showing a Cookie header correctly (containing CSRF, callback URL and session token), but auth() in the same line returns null:

RSC:

console.log('USER', await auth(), headers())

log:

USER null bound HeadersAdapter {
  headers: {
  accept: 'text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7',
  accept-encoding: 'gzip, deflate',
  accept-language: 'en-GB,en;q=0.9',
  cache-control: 'max-age=0',
  connection: 'keep-alive',
  cookie: 'next-auth....'

[uncledent]

Any progress on that? Auth() returning null for me as well with Auth0Provider

[leohxj]

work with @auth/prisma-adapter, the auth object received in the authorized callback (or inside the middleware - req.auth) is always null

[kzlar]

Has anyone been able to successfully use v5 with a pages based nextjs project?
I keep hitting weird import errors like this one:

Error: Cannot find module 'node_modules/next/headers' imported from node_modules/next-auth/lib/index.js
Did you mean to import next/headers.js?

[benjamindell]

Did you find a solution to this? I'm also seeing this error :(

[bricesuazo]

Have you tried deleting the node_modules and then npm i again?

[kjetilhartveit]

Can't find a solution for this even though they say it is supported. I guess they've just written the docs before solving it. Kind of annoying tbh. Perhaps time to re-write to app folder..

[krusadellc]

Deleting and Re-Installing node_modules doesn't help. Any help would be appreciated.

[TechyChan]

same issue on my side

[barryengineerapart]

@balazsorban44 It seems that once cannot import anything into middleware that has server-only. This is a huge limitation, as AuthJS requires middleware to expose functionality that has sensitive client information. If we remove server-only, then that opens up a whole can of worms since we would need to remove it from many other modules.

[barryengineerapart]

Ignore ORMs, what about the auth configs... that is super sensitive stuff that you would want to put server-only on.

[juliusmarminge]

What's sensitive? Your envs wont be accesible to client with or without server-only

[barryengineerapart]

True... but that means anything you include in middleware cannot be included on your server. And there are things that are sensitive.

[adrianyg7]

// src/auth/config.ts
import type { AuthOptions } from "next-auth";

export const authConfig = {
  ...
} satisfies AuthOptions;

As soon as this file gets marked as server-only (which contains sensitive information) the middleware crashes.
Not marking this implies to also not mark other sensitive-files imported by Auth, say the DB adapter files, the provider files, etc.

This is not exclusive to Auth, really anything that you need a middleware for, can't be marked as server-only and that's the real limitation.

[osdiab]

@barryengineerapart for what it's worth, I am also concerned, not only because of this but also because the notion of importing the same auth() object with literally all of the auth config details in the client, server, and middleware also means that all the auth code, callbacks, provider hooks etc. are included in all three bundles - a security risk, but also unnecessarily increases bundle size, and is restrictive in that you can't even freely use builtin NextJS features like cookies() or headers() in the implementation of your auth config, without breaking compatibility with the middleware or browser. So it's straight up just restrictive and inefficient, besides it being potentially dangerous.

At first I wasn't sure what to think about this API, but after using it, while I get the convenience of only having one auth() function to rule them all, I'm finding that it is a problematic API choice for other reasons. I also am curious to know if it's a valid approach to make multiple NextAuth instances, some of which are only used in the server side and some of which are used client side, that lack all those implementation details.

[AVDAIN]

Code Before

export default async function handler(
    req: NextApiRequest,
    res: NextApiResponse
) {
    // Check if user is logged in
    const session = await auth(req, res);

    if (!session || !session.user) {
        return res.status(401).json("To upload, please log in.");
    }

    const user = await prisma.user.findUnique({
        where: {
            email: session.user.email!,
        },
        select: {
            credits: true,
            location: true,
        },
    });

    return res.status(200).json(
        {
            remainingGenerations: user?.credits
        });
}

Error
error No HTTP methods exported in 'D:\testProject\app\api\remaining\route.ts'. Export a named export for each HTTP method.

Code After

export async function GET(
    req: NextApiRequest,
    res: NextApiResponse
) {
    // Check if user is logged in
    const session = await auth(req, res);

    if (!session || !session.user) {
        console.log("User not logged in");
        return res.status(401).json("You must be logged in to upload.");
    }

    // Query the database by email to get the number of generations left
    const user = await prisma.user.findUnique({
        where: {
            email: session.user.email!,
        },
        select: {
            credits: true,
            location: true,
        },
    });

    return res.status(200).json(
        {
            remainingGenerations: user?.credits
        });
}

Error

- error TypeError: res.status is not a function
    at GET (webpack-internal:///(rsc)/./app/api/remaining/route.ts:26:20)
    at async eval (webpack-internal:///(rsc)/./node_modules/next/dist/server/future/route-modules/app-route/module.js:254:37)

[samtgarson]

Route handlers in the app directory have a slightly different implementation to API routes in the pages directory. Go checkout the next docs for Route Handlers, they have some clear examples.

(This isn’t anything to do with NextAuth though ☺️)

[AVDAIN]

Route handlers in the app directory have a slightly different implementation to API routes in the pages directory. Go checkout the next docs for Route Handlers, they have some clear examples.

(This isn’t anything to do with NextAuth though)

Hi, I have already tried to implement these solutions, but the error still seems to appear.

[juliusmarminge]

export async function GET(req: NextRequest) {
    // Check if user is logged in
    const session = await auth(); // shouldn't need to pass req to auth functions, headers are globally available

    if (!session || !session.user) {
        console.log("User not logged in");

        return NextResponse.json("You must be logged in to upload.", { status: 401 });
    }

    // Query the database by email to get the number of generations left
    const user = await prisma.user.findUnique({
        where: {
            email: session.user.email!,
        },
        select: {
            credits: true,
            location: true,
        },
    });

    return NextResponse.json({
      remainingGenerations: user?.credits
    });
}

[ramiel]

In order to implement a custom signin page, what is the new method to get the provider list? Before it was getProviders to be used inside getServerSideProps, but now that method doesn't see to exist anymore

[juliusmarminge]

You can fetch /api/auth/providers ?

[TSV-KG]

no, that does not work

[aymanechaaba1]

@TSV-KG It does work, but we need type definitions, I'm looking to make PR for that.

[NikolozMS]

if it does not work, check your sessionprovider implementation

[MoWael11]

how can i pass the request to the auth function in nextauth v5 when i try to use the auth() in the pages /api directory it gives me this error Error: Invariant: headers() expects to have requestAsyncStorage, none available.

[chungweileong94]

Never tested it on the page router myself, but I think we should pass in the Request, something like auth(req). If not, I will say you can consider using the route handler (/app/api/**) instead.

[janus-reith]

#10438

I'm a bit confused this apparently hasn't been discussed anywhere.
All I can find in the v5 docs is that it's deprecated — Not that it has been removed: https://authjs.dev/getting-started/migrating-to-v5#breaking-changes

The new core package however does not seem to include the v1 legacy handler previously included in the next-auth package.

[osdiab]

Is it possible to use the auth() function in NextJS Edge Middleware without requiring the providers and callbacks? As in #10501 (comment), because my logic to send verification emails is not edge-compatible, and also some callbacks on signIn set cookies using the NextJS cookies() special function, which also is not edge-compatible, I cannot use auth() to wrap my edge middleware. But that seems totally irrelevant for the purpose of making my session accessible in the middleware, I'm not going to be sending emails from there ever.

Would it make sense to make another instance of next-auth that has the same config, but lacks the providers and callbacks so as to make it compatible with edge middleware? Would that cause any potential problems? Thanks!

[da1z]

here is the guide for edge compatiblity, they recommend splitting config for middleware and for server https://authjs.dev/getting-started/migrating-to-v5#edge-compatibility

[barryengineerapart]

This has been fixed by Vercel for quite some time now.

[osdiab]

I assume you were replying to me, but what do you mean that it was fixed and how?

[theklr]

Does anyone have a client side example of the custom sign-in? We originally had our previous implementation designed with using the interception pattern in mind, and with only finding rsc as a working example makes this challenging to want to continue to support

[MarkLyck]

NextAuth.js v5 doesn't seem to work properly with keycloak. Keycloak authenticates the user, but next-auth doesn't update or set the session.

More details: #11237

[DewinU]

We really need a way to modify the token endpoint request #10728

[acuthbert]

While I understand the default position that the Credentials provider should not support server sessions, there are use cases where this limitation means the whole application can't avail of server sessions when in fact there is no reason for this constraint. For example, in development we use a mock login that allows testers to quickly switch in and out of different roles without requiring management of a dozen oAuth credentials. This massively boosts productivity.

Replicating this with Auth.js requires using the Credentials provider but I have to set session strategy to JWT.

Could this be just a default, and support a provider option to allow server sessions?

Note, while the community have some work arounds (e.g.https://nneko.branche.online/next-auth-credentials-provider-with-the-database-session-strategy/) these will no doubt break as the API changes over time so a first party solution would be best I think.

[Selva-Torus]

Please anyone help me to fix this,

providers: [
Credentials({
async authorize(credentials) {
const { username, password } = credentials;
// Return the promise from the axios.post() call
const res = await AxiosService.post(/exampleSignin, {
username,,
password
});
if (res.status == 201) {
return res.data;
} else {
return null;
}
},
}) ]

This is my credential provider and working fine on dev environment , but in deployment , this gives me timeout error

[note: during deployment if I gave local IP related to my LAN for a deployed app it's working fine , but when providing public IP address , issue comes]

please suggest me how t o fix this issue

[tntchn]

Looks like your exampleSignin was blocked by firewall. Did you deploy your service on your own server or the cloud service? The next-auth config looked right, and the problem was probably caused by the network setting. Please check if you can access the url at http://your.public.ip/exampleSignin from other devices or just use curl from the server.

[DevJaco]

I would really like to implement the following flow:

User signs in with credentialsProvider and obtains jwt token from my backend (dj-rest-auth)
User can then link their social media accounts: Facebook, Instagram, etc into this account.

Is it possible to link provider accounts to one main account with the jwt strategy?

[FernandoBDAF]

Could anyone help me with this issue: #11648

Works locally but not in production: Next-Auth ^5.0.0-beta.20 / Keycloak 18.0.2 / Next: ^14.2.2

full explanation and code in the post

[nahasco]

Using JWT strategy and credentials provider, how do I set max token age? No refresh token just the access token?

I would like the user to be logged out when the age expires.

[svarup]

As in Twitter OAuth 2.0, there is no way to get the user's email address. Twitter does not provide any Scope to get an authenticated user's email address. Even if you check "Request email from users" in the Twitter App you won't get the email address. But if you use OAuth 1.0A you can request email using "include_email=true" scope.

Currently, in v5 there is only an OAuth 2.0 way in Twitter but we can't get email address. Please add OAuth 1.0A support that we have in v4

Please add legacy Twitter OAuth 1.0A provider in V5

#11711

[pogran]

could anyone can help with this issue #11633

[ndueber]

With react 19 stable. is version 5 going to become stable anytime soon? and be compatible with react 19?