E-Mail as username already taken, user cannot join organization
Scenario
We as a company have the following scenario:
We offer various online services; most of them are for b2b customers and are paid. Here we simply create one organization per customer, which works wonderfully with zitadel.
But we also have a blog (wordpress) where users can register and comment. The blog is intended for everyone, including private individuals or employees of a company that is not a “customer” of ours.
Here it is neither possible nor sensible to assign users to a specific organization. Instead, we would create a general “public” organization and assign the users of the blog to it.
Problem
But now the following problem arises:
- the user peter@company.com registers for the blog and ends up in the “public” organization
- shortly afterwards company.com becomes a customer with us and gets its own organization “company”, to which the domain company.com is assigned
- peter@company.com cannot register / log in to “company” because he is already in “public”
- when trying to create / invite peter@company.com as manager of “company” directly via the console, the error “User already exists (V3-DKcYh)” appears (questionable from a security perspective, by the way, because of user enumeration, but this is a common trade-off and I understand the need)
We have emails as usernames, so according to zitadel they have to be globally unique, we are aware of that.
The problem with other usernames or domain suffixes is that it is a major UX killer for the 0815 default user, who is so used to emails and doesn't want to worry about domains, tenants etc.
Post is too long, see the comment below.
9 Replies
Intended behaviour
- registration / login via email (i.e. email = username)
- usernames (emails) should not have to be globally unique
- if there are several accounts in different organizations, it should be possible to select in the UI which one you want to log into (I know that this can be achieved with own UI and the zitadel APIs)
Looking through the github issues and the posts here, it is obvious that there is constant confusion and problems with the current concept around emails / usernames / uniqueness.
You are working on this as part of the "User Schema" epic, which is great!
I don't know if this will also solve the problem outlined here?
How can we solve this problem in the meantime?
Hi @irieimperator! :gigipixel:
Firstly, thank you for such a well written post that aligns with our posting template + guidelines. This is very thorough! I'll be looking into this with an engineer shortly so sit tight! I'll get back to you with some insight as soon as possible!
Hey @irieimperator!
User schemas might not be a fit for what you're outlining here - In a general sense, usernames have to be globally unique with or without suffixes. A good workaround would likely be to enable or deactivate loginname suffixes (in your domain settings) on an organizational level as needed. I.e. you enable it for the customer login & deactivate it for the public organization. 🦒
📚 Docs to look at
- Domain settings: https://zitadel.com/docs/guides/manage/console/default-settings#domain-settings
ZITADEL Docs
Default settings work as default or fallback settings for your organizational settings. Most of the time you only have to set default settings for the cases where you don't need specific behavior in the organizations themselves or you only have one organization.
@Raccine With pleasure, that's the least I can do🙂 Thanks for the quick answer!
Status quo
If I have correctly understood it after many hours of reading and testing, the following currently applies:
- the username must be globally unique
- the username can be the same as the email, but does not have to be
- there is no way to globally enforce a schema for the username
- even if you could, i can't think of anything meaningful with added value other than email, but you would lose the possibility of having an account with one email in several organizations; in addition, the username would then be completely redundant and obsolete
- the domain suffix can quickly lead to bulky, impractical usernames, which is bad from an UX point of view and causes confusion; moreover, it cannot be enforced globally because it is a setting at organization level (unless you give the organization admins minimal rights, but this severely limits self-service)
- the username can be chosen by the users themselves, which can currently be prevented for the console via workarounds, but not at all for the API
- what happens if the username is not the same as the email and the user forgets the username? how to recover?
- the username can also be an email with a real, foreign, arbitrary domain, unless this domain is already linked to an organization
- unlikely for public mail providers like @gmail.com, this allows for very annoying shenanigans
- if someone creates a user with username peter@company.com without being peter from company.com, and the domain is then linked to the legitimate organization “company”, a real peter@company.com could no longer register / log in with his regular username; if domain suffix is then deactivated, even implicit registration fails when logging in via external IdP(assumption, not tested)?
All in all, everything depends heavily on the username, over which I, as the SaaS operator, have virtually no control, plus the UX penalties and various options for abuse / accidents / edge cases.
Why is the username needed at all? And why does it have to be globally unique?
The mapping of a user to an organization at login is also possible in other ways, almost every other CIAM solves this without this restrictions.
Proposal
Why not simply use the email as the only login identifier (“username”) and, if in doubt, list to the user in which organizations he can log in with it? That would be username enumeration / information disclosure, but it already occurs in several places anyway.
With my current understanding / knowledge, this is a completely unnecessary and annoying complexity. Am I missing something, what were your considerations, what are the advantages?
I really like zitadel, I like the philosophy, the concept and your open approach. I would love to implement it in our company, otherwise I wouldn't go to the effort of a thorough evaluation, but the issue of “uniqueness” could really become a killer for us.
I could understand if you didn't want to have a fundamental discussion about your architecture here on discord, but I somehow care about zitadel and I think my feedback could be useful for you, so here I am😅
@Raccine Could you perhaps confirm or correct my assumptions about the status quo so that I can consider how to proceed based on them?
Unknown User•8mo ago
Message Not Public
Sign In & Join Server To View
Same here, we discovered this limitation today 🙁
Any suggestion or plan to allow a user to have the same email for different orgs?
Hey folks!
@irieimperator, @dmkmlg, & @sagion - Sorry for the delay in response. Let me loop in an engineer who can help here! ☺️
Unknown User•7mo ago
Message Not Public
Sign In & Join Server To View
Hey @JC! I've shared this feedback with product & engineering - We're currently looking into this and will get back to you as soon as possible! 🦒