Users seeing other Users in same Org
⚙️Configuration🔬Roles & Permissions❓Question🏗️Architecture✅Solved
Hey, love the product!
I wonder how the following use case is typically handled:
My application should show who last edited a resource. E.g., user A, “Hans,” sees that user B, “John,” has last edited an entry.
The user ID (123) is saved to my application's database, but not the username (Hans). The user information is in Zitadel, referenced by said user ID. So far, I like this strict separation, as it keeps the data in my application anonymized.
I have explored two approaches but don't believe either is good:
1. Create a service user in Zitadel that has access rights to read users within the same organization. Then, use it in my application with a PAT (stored as a secret) to look up usernames from Zitadel's management API.
2. Configure a custom Zitadel access right for users to read other users within the same organization. Like a restricted version of CUSTOM_ORG_USER_VIEWER. Then, look up via the V1 management API.
I believe it is not good practice to use the management API for this (correct if wrong). Is there a better way than storing the username in my application database?
I wonder how the following use case is typically handled:
My application should show who last edited a resource. E.g., user A, “Hans,” sees that user B, “John,” has last edited an entry.
The user ID (123) is saved to my application's database, but not the username (Hans). The user information is in Zitadel, referenced by said user ID. So far, I like this strict separation, as it keeps the data in my application anonymized.
I have explored two approaches but don't believe either is good:
1. Create a service user in Zitadel that has access rights to read users within the same organization. Then, use it in my application with a PAT (stored as a secret) to look up usernames from Zitadel's management API.
2. Configure a custom Zitadel access right for users to read other users within the same organization. Like a restricted version of CUSTOM_ORG_USER_VIEWER. Then, look up via the V1 management API.
I believe it is not good practice to use the management API for this (correct if wrong). Is there a better way than storing the username in my application database?
