use next-auth on a subdomain as a separated authentication service

[gex]

hello,

i found something similar in the faq but in my case the other website would use nextjs as well. when i add next-auth without creating the api route i get some warnings/error messages. so i'm wondering if it's doable at all.

there would be 3 applications in play:

• mydomain.com: nextjs app
• auth.mydomain.com: next-auth app
• api.mydomain.com: graphql server

the user would use the nextjs app with a jwt from the auth app and data from the api.

in theory i need the following steps:

• redirect on login: the auth app has the api route so it's easy to redirect to its url
• store or retrieve user data from the api: with a custom adapter(?) and a machine to machine token (or a generated jwt?) the auth app could communicate with the api to save the signed up users and get the data of logged in users
• add id, roles and permissions to jwt: with a custom encode function(?) i can add data to jwt
• redirect back to the website
• communicate with the api: the logged in user can call the api with the jwt they got from the auth app. it's not clear how should i customize the cookies yet

i have not investigated all these steps deeply yet because i got that error message about the missing api route but is it possible to make something like this work with next-auth? can two applications share next-auth? in this case the majority of the backend code would be in the auth app and the majority of frontend code would be in the nextjs app.

thanks!

[iaincollins]

Hi @gex,

The good news is that this is possible!

The bad news is it's more work that it ideally should be.

To share a Session Token / JSON Web Token across multiple sites with NextAuth.js you currently need to:

1. Set a custom domain option on the sessionToken cookie
2. Use a custom redirect() callback which allows redirects to any URL on that domain.

The difficulty with the current approach is that you need to specify the entire set of options for the sessionToken cookie and use different logic locally vs in production, because the name and secure options typically need to be different (unless you are running SSL locally!).

To give you an idea, the cookie option should look something like this:

cookies: {
  sessionToken: {
    name: process.env.NODE_ENV === 'production'
       ? `__Secure-next-auth.session-token`
       : `next-auth.session-token`,
    options: {
      httpOnly: true,
      sameSite: 'lax',
      path: '/',
      secure: process.env.NODE_ENV === 'production' ? true : false
    }
  },
 }

As long as all the sign up pages are hosted on the same subdomain as the API (e.g. auth.mydomain.com) then you shouldn't need to change any of the other cookies.

---

I would like to make this easier, and then ultimately going further and support multi-domain sign in, as goals for the project.

I would like to simplify this to top level option that is just domain and that applies these behaviours automatically if a value for domain is specified. As it leverages cookie behaviour, is not actually too complex a change. I would welcome any PR that introduced this and would be very happy to participate in testing.

Ultimately, I would also like to see us also support cross-domain sign in, and at that point we might replace domain with something like domains and take multiple domains and/or support wildcards. That will require additional complexity as is more work achieve; it is usually implemented with window.postMessage and will require exposing an API endpoint with a suitable CORS headers.

[gex]

hi @iaincollins,

thanks for the detailed answer! i had to read a bit about some of the things you mentioned because i've used oauth/jwt a lot but never had the time (or patience) to build a custom solution. anyway i've started to work on this and now i'm stuck the client side.

i've managed to redirect the user to auth.mydomain and after the successful login back to mydomain. on mydomain i'd like to use the useSession hook to add a login or logout button to the page and i can't make it call the auth app. so instead of calling auth.mydomain/api/auth/session it always calls mydomain/api/auth/session. i get a CLIENT_FETCH_ERROR but the explanation is a bit misleading: i'm not getting it because i haven't set the NEXTAUTH_URL, i get it because the request fails.

after digging the code and trying to understand what is happening in the background i think i found the problem but i'm afraid it's not a bug. so the useSession hook uses the getSession function where the url is generated by the _apiBaseUrl function. and there is that "return relative path when called client side" comment. i checked the history but i don't see why it is relative. can you help me to understand why is it treated differently on the server and client side?

[iaincollins]

can you help me to understand why is it treated differently on the server and client side?

Great question!

Client Side

Client side it calls whatever the relative path is defined as in NEXTAUTH_URL (ignoring the hostname) and assume /api/auth/session as the default value for the path.

In a browser it's safe to use a relative path. In fact, this is handy to leverage as relative paths are are that is allowed in the browser, without also implementing CORS headers.

Implementing CORS headers on a site isn't too tricky, but implementing them well in library is much more challenging.

Server Side

So on the server side, the server needs to know where to call to check the session.

It can't assume a relative path like /api/auth/session as it might be not be running on http://localhost at all (and, if it's serverless, it probably isnt'!). Even if it is running on localhost (e.g. inside a Docker container) we wouldn't know what port it is on (3000, 80, 8080...).

So server side we take advantage of the fact that, unlike with JavaScript in the browser, there are no security restrictions on what URLs we can call server side, so we use the full absolute path from NEXTAUTH_URL and again assume /api/auth/session as the default value for the path (but if there is a path explicitly specified, we use it too).

Server side it passes through the cookie from the req object just as if it's a client side request to the /api/auth/session end point, so the endpoint is able to read the session cookie and tell us if the user has a session or not.

Cross-Origin Resource Sharing (CORS)

This is the "gotcha".

One option:

For multi-site sign in would need to add Cross-Origin Resource Sharing (CORS) to the /api/auth/session endpoint.

There is an example of how to add these to an API route here:
https://github.com/vercel/next.js/tree/canary/examples/api-routes-cors

If you were to allow GET requests to /api/auth/session from any subdomain (or from anywhere) that would be enough.

I don't have an example of the best syntax to use for this, but I think you should be able to use a library like this in conjunction with NextAuth.js route handler in [...nextauth].js. The https://www.npmjs.com/package/cors should have more info. As it's only a single header you could also just add it to the req object yourself.

HOWEVER I don't think that useSession() / getSession() can be used with an absolute path on the client side so you would have to write your own getSession method:

// Isomorphic `getSession` request - to call sever side pass the `context` or `request` object
function getSession ({ ctx, req = ctx?.req } = {}) {
  const url = `https://auth.mydomain.com/api/auth/session`
  const fetchOptions = req ? { headers: { cookie: req.headers.cookie } } : {}
  const session = await _fetchData(url, fetchOptions)
  return session
}

If you want something that works like the useSession option in NextAuth.js then useSWR is great and works in a very similar way and you can use it to call https://auth.mydomain.com/api/auth/session and shouldn't have any problems with it client side, as long as you have a CORS header on the endpoint!

Another option:

Alternatively you could use a JWT token across domains and read the token directly to check the session.

You could use the getToken() helper server side on other sites to read the session:

import jwt from 'next-auth/jwt'

const secret = process.env.JWT_SECRET

export default async (req, res) => {
  const token = await jwt.getToken({ req, secret })
  console.log('JSON Web Token', token)
  res.end()
}

With the JWT approach you don't have to worry about CORS headers, but you would still have to handle client side session checking yourself (e.g. you could even your own /api/auth/session endpoint on each site if you wanted).

In both cases, not being able to use absolute URLs server side (because the NextAuth.js client doesn't support that) is a hurdle that means you can use useSession or getSession in the client - and instead would need to use useSWR or your own method to make a fetch request. So, this is kind possible but really awkward and messy right now as you can see.

A improvement we could probably make safely would be to allow you to force calling an absolute URL on the client side. I may keep that - and the CORS header - in mind when I come to look at simplifying the cookie domain configuration, as it would make sense to do them all at once and would make this all MUCH easier to use (as simple as specifying a domain!).

[datteroandrea]

hi @iaincollins,

thanks for the detailed answer! i had to read a bit about some of the things you mentioned because i've used oauth/jwt a lot but never had the time (or patience) to build a custom solution. anyway i've started to work on this and now i'm stuck the client side.

i've managed to redirect the user to auth.mydomain and after the successful login back to mydomain. on mydomain i'd like to use the useSession hook to add a login or logout button to the page and i can't make it call the auth app. so instead of calling auth.mydomain/api/auth/session it always calls mydomain/api/auth/session. i get a CLIENT_FETCH_ERROR but the explanation is a bit misleading: i'm not getting it because i haven't set the NEXTAUTH_URL, i get it because the request fails.

after digging the code and trying to understand what is happening in the background i think i found the problem but i'm afraid it's not a bug. so the useSession hook uses the getSession function where the url is generated by the _apiBaseUrl function. and there is that "return relative path when called client side" comment. i checked the history but i don't see why it is relative. can you help me to understand why is it treated differently on the server and client side?

Hello there, do you have a github repo to show how you handled the authentication between the different subdomains?

[internationalhouseofdonald]

I'm not actually 100% sure how I got this to work, but I did what you said here.

I added the domain option the the cookies.sessionToken property in my NextAuth() configuration on both my "marketing" website (let's call it mydomain.com) and then I just redirected everything back to the root of my app (admin.mydomain.com), setting the callbackUrl in my call to signIn to https://admin.mydomain.com/api/auth/callback/[provider], and I got all the way until I found this error:

JWEDecryptionFailed

After setting the NEXTAUTH_SECRET in my .env file on both mydomain.com and admin.mydomain.com (as well as setting the secret in my NextAuth config), a sign in (or sign up) attempt on my root domain logged the user into the app. 🎉

I wish I knew what the "one thing" was that I did to get it to work. Every now and, then I solve something and I don't know how I did it. 🙈

Thank you so much!

[amanrathore48]

Can you please show me your nextauth config for both the subdomains?

[mikestopcontinues]

@iaincollins Hey, I'm in the process of stitching this together now. I just want to confirm that it takes:

1. All cookies get the options.domain property added, but are otherwise unchanged.
2. Support useSession by installing /api/auth/[...nextauth].ts on every app.
3. Override the redirect() callback like so:

async redirect({url, baseUrl}) {
  const parsed = new URL(url, baseUrl);

  if (parsed.hostname.endsWith(domain)) {
    return parsed.toString();
  }

  return baseUrl;
},

And lastly, to limit the api endpoints to one app, is the best bet would be to create a custom useSession with useSWR(key, {refreshOnInterval, refreshOnFocus})?

Is this all correct?

[TomFreudenberg]

Hey guys,

coming up to this discussion I wonder about the "correct" or "aesthetic" way to manage that.

If using a site for authentication my domains it is possible by a:

1. domain global session cookie

a. auth.domain.com
b. site.domain.com
c. app.domain.com

just set cookie.options.domain = "domain.com"

or

2. use JWT token

a. generate JWT on auth.domain.com

Solution for 1. is easy and like just configuration, number 2. needs more work.

But which one is the right to choose from a "correct" or "aesthetic" point of view?

[TomFreudenberg]

Well, I continued my working on that - "try" do write a NextAuth based AuthManager as separated nextjs app.

Motivation for me is to split my application code in a monorepo and having there a standard authentication service as separate app.

For the test I made following settings:

1. /etc/hosts

127.0.0.1 auth.acme.local
127.0.0.1 app.acme.local

2. PORTS

a. Application is running on http://app.acme.local:3000
b. Authentication is running on http://auth.acme.local:4000

3. allow CORS

To allow CORS the cookies have to be secured by https.
For that I use the local-ssl-proxy npm and proxy-run:

a. Application is running on https://app.acme.local:3001
b. Authentication is running on https://auth.acme.local:4001

4. CORS headers

To allow cross-site cookie usage you need to set the CORS headers.
Easy to do in next.config.js

const headers = [
  "Accept", "Accept-Version", "Content-Length",
  "Content-MD5", "Content-Type", "Date", "X-Api-Version",
  "X-CSRF-Token", "X-Requested-With",
];

module.exports = {
  reactStrictMode: true,
  async headers() {
    return [
      {
	      source: "/api/(.*)",
        headers: [
	        { key: "Access-Control-Allow-Credentials", value: "true" },
          { key: "Access-Control-Allow-Origin", value: "https://app.acme.local:3001" },
          { key: "Access-Control-Allow-Methods", value: "GET,POST" },
          { key: "Access-Control-Allow-Headers", value: headers.join(", ") }
	      ]
      }
    ];
  }
};

You need to set the credentials and cookies in `[...nextauth].ts

Be aware of SameSite: "none" value (only allowed on https and secure cookies)

import NextAuth, { NextAuthOptions } from "next-auth"
import CredentialsProvider from "next-auth/providers/credentials";

export const authOptions: NextAuthOptions = {
  session: {
    strategy: "jwt",
    // Seconds - How long until an idle session expires and is no longer valid.
    maxAge: 10,
  },

  providers: [
    CredentialsProvider({
      name: "Credentials",
      credentials: {
        username: { label: "Username", type: "text", placeholder: "jsmith" },
        password: {  label: "Password", type: "password" }
      },
      // any values will sign-in as jsmith
      async authorize(credentials, req) {

        const user = { id: 1, name: "J Smith", email: "jsmith@example.com" }
        return user
      }
    })
  ],
  theme: {
    colorScheme: "dark",
  },
  cookies: {
    sessionToken: {
      name: `__Secure-next-auth.session-token`,
      options: {
        httpOnly: true,
        sameSite: 'none',
        path: '/',
        secure: true,
      }
    },

    callbackUrl: {
      name: `__Secure-next-auth.callback-url`,
      options: {
        sameSite: "none",
        path: "/",
        secure: true,
      },
    },
    csrfToken: {
      name: `__Host-next-auth.csrf-token`,
      options: {
        httpOnly: true,
        sameSite: "none",
        path: "/",
        secure: true,
      },
    },
    pkceCodeVerifier: {
      name: `__Secure-next-auth.pkce.code_verifier`,
      options: {
        httpOnly: true,
        sameSite: "none",
        path: "/",
        secure: true,
      },
    },
    state: {
      name: `__Secure-next-auth.state`,
      options: {
        httpOnly: true,
        sameSite: "none",
        path: "/",
        secure: true,
      },
    },

  },
}

export default NextAuth(authOptions)

---

Now you can login at auth.acme.local:4001 and use the token at app.acme.local:3001

Even that at app.acme.local is no useSession you may use fetch to get protected content like:

Example from protected Page in the app.acme.local:

export default function ProtectedPage() {
  const [content, setContent] = useState()

  // Fetch content from protected route
  useEffect(() => {
    const fetchData = async () => {
      const res = await fetch("https://auth.acme.local:4001/api/examples/protected", {mode: 'cors', credentials: 'include'})
      const json = await res.json()
      if (json.content) {
        setContent(json.content)
      } else if (json.error) {
        setContent(json.error);
      }
    }
    fetchData()
  }, [])

  return (
    <Layout>
      <h1>Protected Page</h1>
      <p>
        <strong>{content ?? "\u00a0"}</strong>
      </p>
    </Layout>
  )
}

---

Check out the video:

NextAuthCorsDemo.mp4

---

Now that the techniques are working - what would be the best workflow?

1. User starts on app.acme.local
2. Try to get access from/to auth via fetch will check if already signed in or not
3. get a token from auth.acme.local api like /api/auth/token
4. put that token if valid in a session from app.acme.local
5. with that (local) duplicated session app.acme.local may use simple useSession and fetch against own api.
6. on refresh session / token on app.acme.local check that the token is still valid on auth.acme.local and renew

If user is not already logged in:

7. call signin on auth.acme.local with own callback url where entering steps at 3.

---

Is this a good way?

Some better or more suggested ideas or proposals?

Thanks for continuing the discussion

@iaincollins @balazsorban44 : I can imagine that in conjunction with a monorepo this might be suitable for more developer?

Cheers
Tom

[SSardorf]

@TomFreudenberg - Unfortunately not. I ended up using a managed solution (Clerk). Was hoping it was achievable with Nextauth, but for my use case it just became too complex

[mjhoracek]

@TomFreudenberg @SSardorf, did you guys ever find a solution to this challenge?

[maxeth]

@mjhoracek which challenge are you guys facing specifically? Not being able to access the session via the hook? I can't really tell based on the answers above.

I found an example repo related to subdomain auth with next-auth and it successfully uses useSession on the client.

[TomFreudenberg]

@maxeth your linked repo is a simple example of a subdomain authentication solved by the upper domain cookie:

configured by domain property.

That is easy and does work on any sub-domain path.

The requested feature is to have a site xyz and a standard auth site abc not directly sub-domain related. This is what I have shown with the above code for auth.acme.local and app.acme.local. For that you also need to set all the CORS headers etc.

What we are looking for is a suitable easy solution to create an auth site with next-auth and mostly with self storing passwords and without other login provider.

But that is not their target and not yet supported by them.

[TomFreudenberg]

@mjhoracek still not. Actually I am working with my above code and the CORS headers setup. Any other self-hosted auth provider was to oversized for me. But if any of you found a solution, please leave a note.

[gablabelle]

Finally got this working. So if you have the following

• app.company.com (login here)
• subdomain.company.com
• company.com

You need to set the cookie with the domain set to company.com.

Then the next challenge will be to make this work during local development.

For example if you have the following:

• app.localhost (login here)
• subdomain.localhost
• localhost

Trying to set the cookie with the domain set to localhost will not work.

But his worked for me:

• app.company.localhost (login here)
• subdomain.company.localhost
• company.localhost

I have set the cookie with the domain set to either company.com or company.localhost depending on where the app is running (deployed vs locally). Please note that I'm always using https even locally or else Azure doesn't allow me to redirect to a non https redirect URI if not precisely localhost (localhost OK but not app.company.localhost).

NEXT_PUBLIC_APP_URL=https://app.company.localhost (env.local)
OR
NEXT_PUBLIC_APP_URL=https://app.company.com (when deployed)
...

function getCookieHostname() {
  const hostname = new URL(env.NEXT_PUBLIC_APP_URL).hostname;
  const [subDomain] = hostname.split(".");

  const cookieDomain = hostname.replace(`${subDomain}.`, "");
  return cookieDomain;
}

...

const domain = getCookieHostname();

...
pages: {
    signIn: `${env.NEXT_PUBLIC_APP_URL}/login`,
},
cookies: {
    sessionToken: {
      name: `__Secure-next-auth.session-token`,
      options: {
        sameSite: "none",
        secure: true,
        httpOnly: true,
        path: "/",
        domain,
      },
    },
    callbackUrl: {
      name: `__Secure-next-auth.callback-url`,
      options: {
        sameSite: "none",
        secure: true,
        httpOnly: true,
        path: "/",
        domain,
      },
    },
    csrfToken: {
      name: `next-auth.csrf-token`,
      options: {
        sameSite: "none",
        secure: true,
        httpOnly: true,
        path: "/",
        domain,
      },
    },
  },

[lveillard]

In my case I had to just create 2 different instances of nextjs, one per domain. Which is not exactly what I wanted. So adding a little comment here to thank you for your contribution and to come back to it and try it once we refacto the auth system!

[mjhoracek]

<!-- /* Font Definitions */ @font-face {font-family:Wingdings; panose-1:5 0 0 0 0 0 0 0 0 0;} @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; font-size:11.0pt; font-family:"Calibri",sans-serif;} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} code {mso-style-priority:99; font-family:"Courier New";} pre {mso-style-priority:99; mso-style-link:"HTML Preformatted Char"; margin:0in; font-size:10.0pt; font-family:"Courier New";} span.HTMLPreformattedChar {mso-style-name:"HTML Preformatted Char"; mso-style-priority:99; mso-style-link:"HTML Preformatted"; font-family:"Courier New";} .MsoChpDefault {mso-style-type:export-only;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} /* List Definitions */ @list l0 {mso-list-id:316570696; mso-list-template-ids:-1;} @list l0:level1 {mso-level-number-format:bullet; mso-level-text:\F0B7; mso-level-tab-stop:.5in; mso-level-number-position:left; text-indent:-.25in; mso-ansi-font-size:10.0pt; font-family:Symbol;} @list l0:level2 {mso-level-number-format:bullet; mso-level-text:o; mso-level-tab-stop:1.0in; mso-level-number-position:left; text-indent:-.25in; mso-ansi-font-size:10.0pt; font-family:"Courier New"; mso-bidi-font-family:"Times New Roman";} @list l0:level3 {mso-level-number-format:bullet; mso-level-text:\F0A7; mso-level-tab-stop:1.5in; mso-level-number-position:left; text-indent:-.25in; mso-ansi-font-size:10.0pt; font-family:Wingdings;} @list l0:level4 {mso-level-number-format:bullet; mso-level-text:\F0A7; mso-level-tab-stop:2.0in; mso-level-number-position:left; text-indent:-.25in; mso-ansi-font-size:10.0pt; font-family:Wingdings;} @list l0:level5 {mso-level-number-format:bullet; mso-level-text:\F0A7; mso-level-tab-stop:2.5in; mso-level-number-position:left; text-indent:-.25in; mso-ansi-font-size:10.0pt; font-family:Wingdings;} @list l0:level6 {mso-level-number-format:bullet; mso-level-text:\F0A7; mso-level-tab-stop:3.0in; mso-level-number-position:left; text-indent:-.25in; mso-ansi-font-size:10.0pt; font-family:Wingdings;} @list l0:level7 {mso-level-number-format:bullet; mso-level-text:\F0A7; mso-level-tab-stop:3.5in; mso-level-number-position:left; text-indent:-.25in; mso-ansi-font-size:10.0pt; font-family:Wingdings;} @list l0:level8 {mso-level-number-format:bullet; mso-level-text:\F0A7; mso-level-tab-stop:4.0in; mso-level-number-position:left; text-indent:-.25in; mso-ansi-font-size:10.0pt; font-family:Wingdings;} @list l0:level9 {mso-level-number-format:bullet; mso-level-text:\F0A7; mso-level-tab-stop:4.5in; mso-level-number-position:left; text-indent:-.25in; mso-ansi-font-size:10.0pt; font-family:Wingdings;} @list l1 {mso-list-id:385104921; mso-list-template-ids:-1;} @list l1:level1 {mso-level-number-format:bullet; mso-level-text:\F0B7; mso-level-tab-stop:.5in; mso-level-number-position:left; text-indent:-.25in; mso-ansi-font-size:10.0pt; font-family:Symbol;} @list l1:level2 {mso-level-number-format:bullet; mso-level-text:o; mso-level-tab-stop:1.0in; mso-level-number-position:left; text-indent:-.25in; mso-ansi-font-size:10.0pt; font-family:"Courier New"; mso-bidi-font-family:"Times New Roman";} @list l1:level3 {mso-level-number-format:bullet; mso-level-text:\F0A7; mso-level-tab-stop:1.5in; mso-level-number-position:left; text-indent:-.25in; mso-ansi-font-size:10.0pt; font-family:Wingdings;} @list l1:level4 {mso-level-number-format:bullet; mso-level-text:\F0A7; mso-level-tab-stop:2.0in; mso-level-number-position:left; text-indent:-.25in; mso-ansi-font-size:10.0pt; font-family:Wingdings;} @list l1:level5 {mso-level-number-format:bullet; mso-level-text:\F0A7; mso-level-tab-stop:2.5in; mso-level-number-position:left; text-indent:-.25in; mso-ansi-font-size:10.0pt; font-family:Wingdings;} @list l1:level6 {mso-level-number-format:bullet; mso-level-text:\F0A7; mso-level-tab-stop:3.0in; mso-level-number-position:left; text-indent:-.25in; mso-ansi-font-size:10.0pt; font-family:Wingdings;} @list l1:level7 {mso-level-number-format:bullet; mso-level-text:\F0A7; mso-level-tab-stop:3.5in; mso-level-number-position:left; text-indent:-.25in; mso-ansi-font-size:10.0pt; font-family:Wingdings;} @list l1:level8 {mso-level-number-format:bullet; mso-level-text:\F0A7; mso-level-tab-stop:4.0in; mso-level-number-position:left; text-indent:-.25in; mso-ansi-font-size:10.0pt; font-family:Wingdings;} @list l1:level9 {mso-level-number-format:bullet; mso-level-text:\F0A7; mso-level-tab-stop:4.5in; mso-level-number-position:left; text-indent:-.25in; mso-ansi-font-size:10.0pt; font-family:Wingdings;} @list l2 {mso-list-id:1117411000; mso-list-template-ids:-1;} @list l2:level1 {mso-level-number-format:bullet; mso-level-text:\F0B7; mso-level-tab-stop:.5in; mso-level-number-position:left; text-indent:-.25in; mso-ansi-font-size:10.0pt; font-family:Symbol;} @list l2:level2 {mso-level-number-format:bullet; mso-level-text:o; mso-level-tab-stop:1.0in; mso-level-number-position:left; text-indent:-.25in; mso-ansi-font-size:10.0pt; font-family:"Courier New"; mso-bidi-font-family:"Times New Roman";} @list l2:level3 {mso-level-number-format:bullet; mso-level-text:\F0A7; mso-level-tab-stop:1.5in; mso-level-number-position:left; text-indent:-.25in; mso-ansi-font-size:10.0pt; font-family:Wingdings;} @list l2:level4 {mso-level-number-format:bullet; mso-level-text:\F0A7; mso-level-tab-stop:2.0in; mso-level-number-position:left; text-indent:-.25in; mso-ansi-font-size:10.0pt; font-family:Wingdings;} @list l2:level5 {mso-level-number-format:bullet; mso-level-text:\F0A7; mso-level-tab-stop:2.5in; mso-level-number-position:left; text-indent:-.25in; mso-ansi-font-size:10.0pt; font-family:Wingdings;} @list l2:level6 {mso-level-number-format:bullet; mso-level-text:\F0A7; mso-level-tab-stop:3.0in; mso-level-number-position:left; text-indent:-.25in; mso-ansi-font-size:10.0pt; font-family:Wingdings;} @list l2:level7 {mso-level-number-format:bullet; mso-level-text:\F0A7; mso-level-tab-stop:3.5in; mso-level-number-position:left; text-indent:-.25in; mso-ansi-font-size:10.0pt; font-family:Wingdings;} @list l2:level8 {mso-level-number-format:bullet; mso-level-text:\F0A7; mso-level-tab-stop:4.0in; mso-level-number-position:left; text-indent:-.25in; mso-ansi-font-size:10.0pt; font-family:Wingdings;} @list l2:level9 {mso-level-number-format:bullet; mso-level-text:\F0A7; mso-level-tab-stop:4.5in; mso-level-number-position:left; text-indent:-.25in; mso-ansi-font-size:10.0pt; font-family:Wingdings;} ol {margin-bottom:0in;} ul {margin-bottom:0in;} -->Hey Gab, do you have this working in a public repo? I’d love to check it out if you do!   -Mitch From: Gab LabelleSent: Monday, February 26, 2024 3:03 PMTo: nextauthjs/next-authCc: Mitch Horacek; MentionSubject: Re: [nextauthjs/next-auth] use next-auth on a subdomain as a separated authentication service (Discussion #1299) Finally got this working. So if you have the followingapp.company.com (login here)subdomain.company.comcompany.comYou need to set the cookie with the domain set to company.com.Then the next challenge will be to make this work during local development.For example if you have the following:app.localhost (login here)subdomain.localhostlocalhostTrying to set the cookie with the domain set to localhost will not work.But his worked for me:app.company.localhost (login here)subdomain.company.localhostcompany.localhostI have set the cookie with the domain set to either company.com or company.localhost depending on where the app is running (deployed vs locally). Please note that I'm always using https even locally or else Azure doesn't allow me to redirect to a non https redirect URI if not precisely localhost (localhost OK but not app.company.localhost).NEXT_PUBLIC_APP_URL=https://app.company.localhost (env.local)ORNEXT_PUBLIC_APP_URL=https://app.company.com (when deployed)... function getCookieHostname() {  const hostname = new URL(env.NEXT_PUBLIC_APP_URL).hostname;  const [subDomain] = hostname.split(".");   const cookieDomain = hostname.replace(`${subDomain}.`, "");  return cookieDomain;} ... const domain = getCookieHostname(); ...pages: {    signIn: `${env.NEXT_PUBLIC_APP_URL}/login`,},cookies: {    sessionToken: {      name: `__Secure-next-auth.session-token`,      options: {        sameSite: "none",        secure: true,        httpOnly: true,        path: "/",        domain,      },    },    callbackUrl: {      name: `__Secure-next-auth.callback-url`,      options: {        sameSite: "none",        secure: true,        httpOnly: true,        path: "/",        domain,      },    },    csrfToken: {      name: `next-auth.csrf-token`,      options: {        sameSite: "none",        secure: true,        httpOnly: true,        path: "/",        domain,      },    },  },—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***> 

[gablabelle]

Hey Gab, do you have this working in a public repo? I’d love to check it out if you do! -Mitch

The repo is not public, I'm sorry.

[mjhoracek]

<!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; font-size:11.0pt; font-family:"Calibri",sans-serif;} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} .MsoChpDefault {mso-style-type:export-only;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} -->No problem! Thanks for your detailed post nonetheless – it was very helpful!  -Mitch From: Gab LabelleSent: Wednesday, February 28, 2024 4:28 PMTo: nextauthjs/next-authCc: Mitch Horacek; MentionSubject: Re: [nextauthjs/next-auth] use next-auth on a subdomain as a separated authentication service (Discussion #1299) Hey Gab, do you have this working in a public repo? I’d love to check it out if you do! -MitchThe repo is not public, I'm sorry.—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>