4 ms·
> Or is there some other use case for which multi tenant support is critical? To support multi tenants in software-as-services. I need to support "company1.ap
by mamcx 6y ago
> Or is there some other use case for which multi tenant support is critical?
To support multi tenants in software-as-services. I need to support "company1.app.com, company2.app.com" in my apps.
> Do you mean the ability to store arbitrary data on the objects provided by the auth system...
The thing is that a "user" have different means. I have salesman's, customers, operators, etc.
Them have fields, like email, is_active, personal info, that are critical for the logic of the app.
IDEALLY the auth server manage the security and read only the fields that are needed to operate this (like for send a password reset).
The other fields, triggers, indexes, etc are more important the rest of the time.
And I don't want to use a "will create corrupted integrity for sure, aka: micro services" because I work in the "sync data across dbs" and it ALWAYS will happened if data is not in single transaction.
- mooreds 6y agoI have definitely seen folks use the id created by the auth system but nothing else. Everything else keys off the GUID, which should be immutable, and is stored in application specific tables. The password and username are in the auth system, but everything else stays in control of the application, in one database. I don't see why you couldn't use that pattern no matter which external auth provider you are using. You'd just give up things like self service registration, but that may be the right choice for your app.