How do we authenticate on many custom domains for our multi-tenant SaaS?

jarrod

Hello, we've got a multitenant SaaS, and we'd like to offer our users custom domains. Setting up a custom domain will be self-service, and there will potentially be thousands. The backend is .NET Core, and the frontend is Remix (Node, React).

Our main app is served at app.ourdomain.com, and custom-domain users will access the app at subdomain.theirdomain.com. Everyone shares a single instance of the app.

For now, we don't mind using the same user pool for all domains (including the main app). We can host the auth service at some kind of generic domain to maintain the white-labeling aspect (it doesn't have to be per-user).

We've got routing and SSL sorted for the custom domains - the main question is: how do we authenticate securely?

Do we whitelist a large amount of callback URLs?
Do we create an Application per custom domain? (Does this mean we have to sync users?)
Do we redirect to the main app and perform some kind of sidechannel/backchannel SSO iframe magic?

Our app currently has its own internal notion of Tenants, Teams/other hierarchies, but we can migrate to the concepts in FusionAuth if that's required.

Any guidance would be appreciated, thank you!

dan

@jarrod

Do we whitelist a large amount of callback URLs?

This would work. We have tested with a couple of thousand different URLs.

Do we create an Application per custom domain? (Does this mean we have to sync users?)

This would work too. You won't have to sync users, but you would have to add registration for each application a user is supposed to have access to. Then you provide a different client id for each subdomain (using a mapping maintained in your database).

Do we redirect to the main app and perform some kind of sidechannel/backchannel SSO iframe magic?

I'd avoid this if at all possible.

This might be helpful reading for you: https://fusionauth.io/docs/get-started/core-concepts/users#segmenting-users if you haven't seen it yet.

but we can migrate to the concepts in FusionAuth if that's required.

Not required, but may be helpful. The question I always ask when discussing this is "would a user who is going to subdomain.theirdomain.com be unpleasantly surprised if they had the same credentials there as they do at the account at subdomain2.anotherdomain.com"? If so, tenants are a good fit. If not, keep things simpler and use one tenant.

akoskm

@jarrod We just rolled out such an app to one of our clients, and I'm happy to share my experiences with you.

Do we whitelist a large amount of callback URLs?

We haven't. Same as in your case, the user registers through a self-serve sign-up form where they enter the tenant details, such as the subdomain. During tenant creation on our backend, we simply construct the new tenant URLs for login and Oauth (we configure Oauth because we have a desktop app connecting to this same backend).

  const newFusionAuthAppConfig = {
    name: `"${organizationName}"'s Project`,
    oauthConfiguration: {
      ...blueprintAppConfig.oauthConfiguration,
      enabledGrants: [GrantType.authorization_code, GrantType.refresh_token],
      authorizedRedirectURLs: [`${newAppUrl}/api/oauth-redirect`],
      logoutURL: `${newAppUrl}/api/logout`,
    },
    loginConfiguration: blueprintAppConfig.loginConfiguration,
  };

So when the new tenant is set up, it already has everything tenant-specific. We use the default tenant as the blueprint for some of our configurations - blueprintAppConfig.

Do we create an Application per custom domain? (Does this mean we have to sync users?)

This is what we did, but I guess it depends on your use case. For us, it was important that one user can register on different subdomains with the same email.

Do we redirect to the main app and perform some kind of sidechannel/backchannel SSO iframe magic?

I can assure you there's no magic once you correctly set up the tenant creation. The entire front end (React here) works the same as before. Most of the "magic" on the backend is simply realizing from which tenant the request came and constructing a tenant-specific Fusion Auth client to retrieve tenant-specific user details, apps, etc.

FusionAuth's official documentation on multitenant setup was an immense help to us.