elina_shoko•6d ago

Give your feedback on user groups implementation

Hi there 👋 We're currently implementing user groups which have been requested by 100+ users from our community 🙌 We’re currently working on including group info in ID/Access token claims, and we’d love your input on how this should look to make it easy for you. Below are three possible formats - please cast your votes :gigilove:

GitHub

User group authorizations · Issue #5822 · zitadel/zitadel

As an administrator I want to be able to manage groups, add users and be able to give the whole group authorizations for a project in the ZITADEL console, so I do not have to manage it for all user...

4 Replies

elina_shokoOP•6d ago

Which format would you prefer for token claims? 1️⃣ Group names 2️⃣ Group IDs 3️⃣ Structured objects (ID + Name) Option 1: Group Names

"groups": ["admin", "support", "dev"]

"groups": ["admin", "support", "dev"]

✅ readable and familiar ⚠️ group names can change + may expose sensitive role names (e.g. “admin”) Option 2: Group IDs

"groups": ["345057045931622542", "345057223853998222", "345097223878998111"]

"groups": ["345057045931622542", "345057223853998222", "345097223878998111"]

✅ stable identifiers, no leakage ⚠️ need an extra lookup to display names Option 3: Structured Objects (ID + Name)

"urn:zitadel:iam:user:groups": [
  { "id": "345057045931622542", "name": "admin" },
  { "id": "345057223853998222", "name": "support" },
  { "id": "345097223878998111", "name": "dev" }
]

"urn:zitadel:iam:user:groups": [
  { "id": "345057045931622542", "name": "admin" },
  { "id": "345057223853998222", "name": "support" },
  { "id": "345097223878998111", "name": "dev" }
]

✅ stable IDs + human-readable, extendable ⚠️ includes names → potential exposure, slightly more custom format

AYEEDITYA•6d ago

To clarify, if it were option 3, we’d end up with a similar situation as current roles which many apps don’t support a layered structure in. Is that correct? And how would this potentially change workflows if we’re already using the inbuilt roles for user grouping for RBAC? In that, actions V1 automatically assign roles on registrations and the flat roles action traverses that info back to the app for appropriate access levels?

peini7•6d ago

Keycloak for example let you configure the token content by creating custom "mappers". They define how a value is mapped into the token.

feliwir•6d ago

I want to point out that LDAP group support should be thought of aswell: - groups need to optionally have some mapping attribute to match them to their LDAP group - there are "nested" groups in LDAP. So a group can contain other groups (not just users) - these kind of groups must not be editable from within zitadel / should just be a 1:1 sync to their LDAP group

Give your feedback on user groups implementation

Did you find this page helpful?