Built-in invite-only authentication in NextAuth

[henrikvtcodes]

Description 📓

Currently, I am building an app which requires users to have entered a verification code in order to have full access to the app. While this isn't going to be a public facing service, Invite only services (otherwise known as FOMO services) have become somewhat common. I think that this could be a useful feature for NextAuth.

Implementation

For starters, this would require a database in order to store invites.
I think that it would be best implemented as a series of strategies, similar to the callbacks option that currently exists. The two main strategies I can think of are code-based invitations and email-based invitations. Code based invitations would basically store invite codes in a database table, and the dev would define the behavior. The other option is email based invitations; a database table would store a series of allowed emails. When a user with that email signs up for the first time, that invite becomes invalid. In both of these, the dev is responsible for implementing some amount of logic. Where does NextAuth come in? NextAuth would effectively be responsible for enforcing the policies. For example, users that sign in but are not invited would be redirected by NextAuth to either a code-entry page or some informational/error page. This would also be interesting if NextAuth ever implements a PhoneProvider in the future.

I don't plan on implementing this by myself; however, if someone else is interested, I would gladly work with them to help implement this.

How to reproduce ☕️

I guess this is a good place to put it?
But basically here's one of the checks I perform in the app that I am building:

async signIn({ user, account, profile, email, credentials }) {
      const dbUser = await prisma.user.findUnique({
        where: {
          id: user.id,
        },
      });

      if (!dbUser) {
        return false;
      }

      if (dbUser.isInvited === false) {
        return "auth/sign-up";
      }

      return true;
    },

There are also other client side checks which redirect users.
Psuedo-implementation example

...
invites: {
    async emailInvite({ user, account, email}) {
      // dev defines here how emails are added to invite list, used, and removed
    },
   async codeInvite({ user, account, email}) {
       // dev defines here how codes are created, validated, and invalidated
    },
  },
...

Contributing 🙌🏽

Yes, I am willing to help implement this feature in a PR

[jimfilippou]

I was wondering the same on this discussion #4132 maybe there is not enough people to push this

[ghost]

+1 on this, would be really useful

[jimfilippou]

Check my comment above, I have uploaded a workaround that works for me

On Wed, 14 Sep 2022 at 5:55 PM, Jesse Winton ***@***.***> wrote: +1 on this, would be really useful — Reply to this email directly, view it on GitHub <#4106 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABUO65RGCQ4UFV3PLZDQYW3V6HRNZANCNFSM55BHLNSQ> . You are receiving this because you commented.Message ID: ***@***.***>

-- Regards, Dimitrios Filippou Lead Software Engineer at Asian Logic LinkedIn <https://www.linkedin.com/in/dimitrios-filippou-98a703131/> | Website <https://jimfilippou.github.io> | GitHub <https://github.com/jimfilippou>

[thejessewinton]

Great, seems like it could be a solid solution; the only problem I might run into for my use case is that invites need to be sent out by existing users, so team admins need to be able to invite members. This might be a good starting place still, but I need to figure out how to trigger the email provider from a team account.

[henrikvtcodes]

Per my original issue/discussion, I am very willing to help implment but I need someone with more experience to lead the api design aspect. @jimfilippou thank you for mentioning the other issue with your solution though, that is very helpful.

[magicspon]

i've managed to hack something together using the 'email' provider.

https://gist.github.com/magicspon/614a780d567a08334831347338a3d262

the key is to overwrite the sendVerificationRequest function, and use an api route as the callback url.

[iamvanja]

Thanks for putting this together!
I am wondering, wouldn't the session be created even before redirecting to the /accept route? Technically /accept route doesn't even need to exist for the session creation to occur. I am guessing /accept would need to invalidate the session if it encounters an error.

Unless I missed something, perhaps middleware that runs before hitting the callback route would be a better approach?

[magicspon]

Heyo,

I've actually completely rewritten the invite code. It's much cleaner and simple now.

I have an endpoint that manually emails the user, adds an invitation record in the db, and adds an api endpoint callback.

https://gist.github.com/magicspon/6748377a945df67af34c80bbe51b97ca

[shreyashrangrej]

This would be a really great feature if invite-only authentication model was natively supported in next-auth.
However one work around solution i would suggest is to use Auth0 and disable sign ups from Auth0.

[christian-hackyourshack]

I am adding my two pence: I want to do an invite-only sign-up with OAuth/OIDC, where I do not know the id of the signup in advance, i.e. some existing user can generate a magic key/link and send it out via WhatsApp, not knowing what the invited user's OpenID would be. I think I could implement this easily, if I would have access to the request triggering the signIn request. I would simply create some URL, that contains the magic key, I could check, if it still is open in the database and everything is easy.

Does someone have a hint, where in the code I need to look to transfer the request information through to the signIn callback? Then I would try it out and prepare a PR if it works as expected.

[Wundero]

I think you probably want to make a custom page for signing in, which has part of the route or a query param containing your magic data (some kind of token).

For example, /signin/:token/ (could be a route in app/signin/[token]/page.tsx or pages/signin/[token].tsx) would work pretty well. You could then use an SSR check (gSSP or RSC) to see if that link exists and is valid, and then when the user signs in, route them using a custom callback url (e.g. /signin/:token/ again, but checking auth status in your SSR, or just using a different route) that contains your token (and other data, if you need it), and then you can persist that data and redirect them to the main part of your application.

export const getServerSideProps = async (ctx) {
  const { params } = ctx;
  if (!params) { 
    // no token, can be redirected elsewhere or something
   return { redirect: { destination: '/', permanent: true } };
  }
  const { token } = params;
  if (!token) {
    // likewise
    return { redirect: { destination: '/', permanent: true } };
  }
  // Using prisma's syntax, but you can use any DB here.
  const dbToken = await db.invites.findMany({ where: { token } });
  if (!dbToken) { // Can also check other things, like if it has already been used or has expired or other business requirements
    // invalid token, error state or just redirect
    return { redirect: { destination: '/', permanent: false } };
  }
  const session = getServerSession(ctx, nextAuthOptions);
  if (session) {
    await db.invites.update({
      where: { token },
      data: {
        user: {
          connect: { id: session.user.id }
        },
        used: new Date(), // this is example data, but showcasing updating your invites when a user is signed up
      }
    });
    return { redirect: { destination: '/', permanent: true } };
  } else {
    return { props: { token } };
  }
}

export default function SignInPage({ token }) {
  return <button onClick={() => {
    // You can also specify a provider or providers, if you'd like.
    signIn({ callbackUrl: `/signin/${token}` });
  }}>Sign In</button>
}