Hi,
I’ve got a use case where users will navigate to a root domain /, but it doesn’t serve anything - it’s a small NextJS API proxy service. The service checks whether the user is authenticated (using the auth0-nextjs SDK), and has an Auth0 application configured. If the user is unauthenticated they are prompted to log in, on the return callback the service redirects the user to the appropriate subdirectory based on their Auth0 org role assignment. This all works fine.
The problem I’m having here is that each subdirectory is a NextJS service, with their own Auth0 application linked (again using the auth0-nextjs SDK). When the user logs into the root domain it sets a session cookie on the root path and the subdirectory cannot decrypt due it having its own AUTH0_SECRET.
What’s the recommended practice here? I feel all the services sharing the same decryption env var AUTH0_SECRET is wrong.
Hi @lee.campbell,
Welcome to the Auth0 Community!
In these types of use cases, we recommend a Multiple Organization Architecture. This way, you can use a single Auth0 tenant with separate applications to manage your user sessions.
Let me know if you have any follow-up questions.
Thanks,
Rueben
Hi @rueben.tiow,
Thanks for the reply.
That’s the setup I have in place. The problem I’m having is that when users log into the universal application I rely on the Auth0 Organisation selector to determine which organisation they wish to access. On the auth callback from Auth0 this selection to the universal application I redirect the user the appropriate sub directory.
I.e. Tom has access to Tom’s Concrete Services & Tom’s Contracting. Tom logs into app.example.com (using Auth0 nextjs sdk) and the Auth0 Organisation selector shows the two organisations Tom has access to. Tom selects Tom’s Concrete Services, auth completes and the SDK behind app.example.com redirects Tom to app.example.com/toms-concrete (using Auth0 nextjs sdk). This subdirectory is a root on another application, backed by another Auth0 application with organisation login enabled.
The problem here is that /toms-concrete can’t determine Tom is authenticated and shows the Auth0 login prompt again. I’m guessing this is down to /toms-concrete using a different AUTH0_SECRET than app.example.com. Thus, not being able to decrypt the auth session cookie and thinking Tom is unauthenticated.
What should I do here? Should app.example.com and the subdirectories share the same AUTH0_SECRET env variable?
Hi @lee.campbell,
Thanks for the reply.
Yes, sharing the AUTH0_SECRET env variable is a valid approach, so your app can decrypt the auth session cookie.
However, to simplify authentication between your organizations, you could use a single Auth0 application instead of two separate applications. This way, you can have your application with Organizations enabled for both Tom’s Concrete Services and Tom’s Contracting, which allows the user to log in once and switch organizations within the same session.
During the login flow, when the user is prompted on the Organization selector page, they can choose whichever organization they prefer to log into. If, in the first login attempt, they chose Tom’s Concrete Services, and in the second attempt, they chose Tom’s Contracting, they wouldn’t be prompted to log in again because their session is active on the same app.
I hope this helps!
Best regards,
Rueben