Is there any way to access original request in signin callback?

[eak12913]

Your question
Is there any way to get access to the request object from the signin callback?

What are you trying to do
I am trying to handle a situation where a new user is invited to my application. The new user is emailed a link that contains some kind of unique id. When the user clicks a link they are taken through an "initial" authentication flow where they see a page that allows them to either create a user/pass OR authenticate via social provider. If they choose to authenticate via social provider - I essentially want to not lose track of the user's unique id so that I could refer to that value in the signin callback. This way, I'd be able to have a code-path that can look up the "pending" user and associate the authenticated social id with this user. Is there any way to either:

• pass through information through the OAuth flow?
• get access to the request object so that I could set some kind of cookie before OAuth flow with my unique key and be able to reference that value when I get redirected back from OAuth flow?

If I'm approaching this the wrong way - I'd be grateful for pointers!
Thank you

Edit: Technically, what I'm looking for is an equivalent concept of Passport.js' passReqToCallback parameter. This would be an option that I could set that would pass the req to the signin (or signIn if using V3) callback.

Documentation feedback
Documentation refers to searching through online documentation, code comments and issue history. The example project refers to next-auth-example.

• Found the documentation helpful
• Found documentation but was incomplete
• Could not find relevant documentation
• Found the example project helpful
• Did not find the example project helpful

[eak12913]

Hmm - is this not a common enough use case?

FWIW, the way that I am currently working around this issue is by creating my own middleware that runs after next-auth. I no longer use the signin callback to control authorization to my application. Instead I am relying on my own middleware to do this.

My middleware will look for the presence of the session-token cookie and then will decrypt that in order to get access to the session. As I have access to the req object in my middleware, I can now access other cookies which have additional information about the user/tell my application that it's a new user and that we have to do something a little bit differently than just normal authZ.

It doesn't feel very hacky - but it's definitely bypassing the intended mechanism for gating access to the application. The other draw back of my current solution is that I'm technically allowing any users to authenticate and thus create next-sessions. My middleware has to be separately aware of what is supposed to be publicly accessible and what is to be protected.

[dan-kwiat]

My solution to a similar use case is to set a cookie inside the getServerSideProps method of the initial invite page. Then read the cookie from the callback (or the createUser event):

// [...nextauth].js
const getOptions = (req) => ({
  // providers: [...],
  // database: {...},
  callbacks: {
    signIn: async (user, account, profile) => {
      const { invite_id } = req.cookies
      // do something with invite_id
      return true
    },
  },
})

export default (req, res) => NextAuth(req, res, getOptions(req))

[dan-kwiat]

Note from the docs:

When using the Email Provider the signIn() callback is triggered both when the user makes a Verification Request (before they are sent email with a link that will allow them to sign in) and again after they activate the link in the sign in email.

Also note that with email auth, cookies you set before sign in won't be accessible on any req after activating the link if the user opens the email verification link from a different device. I have an open pull request which works around this issue using query params in the email verification link #2542

[davevilela]

saved my life 👍 thanks!

My solution to a similar use case is to set a cookie inside the getServerSideProps method of the initial invite page. Then read the cookie from the callback (or the createUser event):

// [...nextauth].js
const getOptions = (req) => ({
  // providers: [...],
  // database: {...},
  callbacks: {
    signIn: async (user, account, profile) => {
      const { invite_id } = req.cookies
      // do something with invite_id
      return true
    },
  },
})

export default (req, res) => NextAuth(req, res, getOptions(req))

I literally spent so many days trying to figure out how to set a custom cookie, but never did it cross my mind that I can refactor the code like this to pass the request and response objects to a function that returns the Next-Auth options object. Thank you.

how do you get rid of the cookie after signing in ?

[FahimFaisalKhan]

How do I make this work in app directory ?
I amimplementing it like :
const handler = (req, res) => NextAuth(req, res, getOptions(req));
export { handler as GET, handler as POST };
But getting
"id_token detected in the response, you must use client.callback() instead of client.oauthCallback()"
this error message only in production though.

[goerlitz]

This is what works for me with Route Handler (/app directory):

// api/auth/[...nextauth]/route.ts
import NextAuth from 'next-auth';
import { NextRequest } from 'next/server';
import { getOptions } from './authOptions';

type RouteHandlerContext = { params: { nextauth: string[] } };

const handler = async (req: NextRequest, context: RouteHandlerContext) => {
  return await NextAuth(req, context, getOptions(req.clone()));
};

export { handler as GET, handler as POST };

// authOptions.ts
export const authOptions = (req?: Request): AuthOptions => ({
  ...
})

see also #8243

[drattansingh]

const { invite_id } = req.cookies

This is working in page router. However with app router I had to use this to get the cookie req.cookies.get('invite_id').value

[ramene]

Here's one approach that worked for me, taken from the more opinionated create-t3-app

// [...nextauth].ts
import NextAuth from "next-auth";
import { authOptions } from "./auth";

const handler = NextAuth(authOptions);
export { handler as GET, handler as POST };

// auth.ts
...
export const authOptions: NextAuthOptions = {
  callbacks: {
    session: ({ session, user }) => ({
      ...session,
      user: {
        ...session.user,
        id: user.id,
      },
    }),
  },
};
...

[djaffer]

This basic feature of passing a parameter from signIn to signIn in backend has been such a challenge.

[drattansingh]

Passing a cookie has been working for me with both page and app router