#Using next-auth in a multi-tenant application.

39 messages · Page 1 of 1 (latest)

crisp karma
#

Hello! Im wondering if its possible to use next-auth to provide auth for the multi tenant sites?

cerulean quailBOT
#
Post created!

🔎 This post has been indexed in our web forum and will be seen by search engines so other users can find it outside Discord

🕵️ Your user profile is private by default and won't be visible to users outside Discord, if you want to be visible in the web forum you can add the "Public Profile" role in id:customize

✅ You can mark a message as the answer for your post with Right click -> Apps -> Mark Solution
(if you don't see the option, try refreshing Discord with Ctrl + R)

mint sluice
#

The short answer is yes. Its is very possible to use next-auth to provide auth for muiltiple sites.

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

If you use something like turborepo for instance and create a package to handle authentication that could potentially be a good option for you but perhaps if you give a bit more specifics we can come up with a more niche answer

Options | NextAuth.js

Environment Variables

crisp karma
#

but i dont see an easy way of doing it as the sites could be under a subdomain like site1.mydomain.com or their custom domain sitedomain.com

mint sluice
#

So to be clear you want them to share the same DB/session for auth? Or is it that you want to use nextauth for two applications ?

#

Because realistically it should be as easy as changing the NEXTAUTH_URL in theory in the env

crisp karma
mint sluice
#

May I ask whats your full tech stack?

#

Are you using a monolith structure?

crisp karma
#

Yeah just nextjs

#

Been using that as an example / base

mint sluice
#

In this case I would just implement next-auth separately for both apps.

Or if you're going off of that example where tehy have the [domain] you can dynamically set the next auth url in the environment or programatically to redirect to auth but it really boils down to the functionality of the application itself in terms of the "best" way to go about it

crisp karma
#

As people can create many sites under different subdomains in this app

mint sluice
#

Ok yeah thats what I figured when you linked that above as a template

#

Frankly, I haven't really played around with next-auth in this context but the way I would do it off the cuff is utalize the next-auth endpoints to verify their sessions and allow them to sign in from the main authentication point which would be for example app.mydomain.com and then redirect them to the other "domain"

crisp karma
#

hmm but I dont see how the sessions will share across?

mint sluice
#

Well the session would be saved in the db. Or you can set it up that way

# 
session: {
  // Choose how you want to save the user session.
  // The default is `"jwt"`, an encrypted JWT (JWE) stored in the session cookie.
  // If you use an `adapter` however, we default it to `"database"` instead.
  // You can still force a JWT session by explicitly defining `"jwt"`.
  // When using `"database"`, the session cookie will only contain a `sessionToken` value,
  // which is used to look up the session in the database.
  strategy: "database",

  // Seconds - How long until an idle session expires and is no longer valid.
  maxAge: 30 * 24 * 60 * 60, // 30 days

  // Seconds - Throttle how frequently to write to database to extend a session.
  // Use it to limit write operations. Set to 0 to always update the database.
  // Note: This option is ignored if using JSON Web Tokens
  updateAge: 24 * 60 * 60, // 24 hours
  
  // The session token is usually either a random UUID or string, however if you
  // need a more customized session token string, you can define your own generate function.
  generateSessionToken: () => {
    return randomUUID?.() ?? randomBytes(32).toString("hex")
  }
}```

Specifically
crisp karma
#

But how would the session token cookie be set the same between each subdomain?

#

just came across this, will try see what this does

mint sluice
#

There are docs on this with next-auth one moment with how to set it to be cross-domain cookies just finding it quickly haha

crisp karma
#

Will take a look, thanks

mint sluice
# 
      httpOnly: true,
      sameSite: 'Lax',
      path: '/',
      secure: true, // depending on if your prod or not 
      domain: '.mydomain.com', // Allows the cookie to be shared across subdomains
    },
#

That should allow for shared sessions between subdomains

crisp karma
#

Right

#

When logging in on the root domain, it doesnt seem to share between subdomains but I shall try a different way

crisp karma
#

I guess this would also have an issue if people use a custom domain

crisp karma
#

I had a scuffed solution that almost worked with discord oauth, but ran into an issue that doesn’t seem fixable.

But basically called the “signIn” method as default but didn’t redirect to the link, instead replace the redirect uri to “auth.mydomain.com/redirect?siteId=abc” which set a cookie to redirect the auth.mydomain.com discord callback, back to the right domain to next-auths callback

#

But it seems the redirect uri is also sent in the token grant request so it just gets “invalid redirect uri”

crisp karma
#

Unless I’m able to modify the package to change the redirect url based on the domain the request is to in the callback