Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.
I'm building a saas app that I want to allow white labeling on certain plans. The paying user would be able to use a custom domain.
I also want to allow users to have multiple accounts on this platform. Like Basecamp or Asana where you log in and see a list of accounts you're a part of.
If I use their email address as the unique login, it's fine for user to see multiple non-white-label accounts when they log in.
But if the user is then invited to an account that is a white label account, they wouldn't be able to register since their email is already in our system. This would confuse them since they're thinking this is a completely different website than the main site because it's white labeled.
I can't say "this email is in our system already" or even "use the forgot password flow", since those things would "reveal" the white label aspect.
How can I handle this?
I could require a unique email address for each account. Ie, not allow multiple accounts for users. But that's a pain for people who want to use a single email to log in to all the accounts. But that's probably the simplest solution.
I could use a username as the unique login, but that seems more complicated than it needs to be. Ie users with multiple logins that have the same email but different user names.
I'll add that it will be rare that a user would have multiple accounts, but it could happen and I'm just trying to cover all potential scenarios. Maybe the simplest way to go is to just say: one email/user = 1 account. And if you want to join another, you have to use another email address.
Any advice? Thank you!
perhaps one day your customers may request to have a single sign-on feature using google or microsoft account to login.. how the system should handle it??
Not so sure about your system, but I think it's fair to let the customer to know there are already registered, otherwise, the system should allow to store the user account in each customer database separately just like no related or a totally different product.
@split19 If you want to support this scenario, then you’re going to have to “bucket” users some how.
For the white-labelled instances, you’ll need to create a new “bucket” of users. When a user tries to log in, you’ll need to check if there’s a user account with that email and password in the “bucket” for that account. Same with other authentication features like resetting passwords, etc.
It’s not something I’ve done before, but if you have something like an account model that contains the domain for the white-labelling aspect, you could then add a nullable account_id model to your users table. You can then create a unique key on the combination of account_id and email. This will allow a user to use the same email address multiple times (but only once per account). So when you a user tries to log in, depending on the domain they’re on you’ll know what account it is, and can add that account ID check to your credentials check.
Thanks for your ideas. I'm thinking that white labeling is maybe not that useful of a feature in my case and wouldn't be worth it to build something to handle this complexity.
I think I will probably just offer "custom branding" (custom colors and logo) which I was going to do anyway. I think that will suffice. And if many customers are clamoring for it, then I can dig deeper into ways to accomplish white labeling.
Thank you.
if the sites are apparently different organisations, then the user will expect to create an account. Therefore there is no need for the user account to be shared across accounts.
From that point of view [email protected] in tenant abc is a different user to [email protected] in account xyz
So if you always append the application id with the email address for all aspects of authentication then the accounts will be seperate, and noone will be confused.
The alternative is that you implement multi-tenancy with isolated database instances for each tenant. Then it just becomes like seperate websites each with its own set of users
@snapey thanks. Interesting idea to append the account id to make them unique. I will think about this.
I thought about multitenancy, but probably not worth the effort in my case since this feature will probably rarely be used.
But thanks for your input. I appreciate it.
Please or to participate in this conversation.