[Feature Request]: Oauth groups

[PovilasID]

🚀 Feature Summary

Oauth scope has 'group' tag importing would ease user management

📝 Detailed Description

Oauth has group as part of scope and ztnet has groups too. Importing a group tag from OAuth source or creating it if not present in group list would be nice.

🎯 Use Case

Multiple 'Jhons' (users with the same) that are on different teams and should have different access.
Having groups match helps user management and identification.

💡 Willing to Contribute

None

[sinamics]

Currently, ztnet only allows setting the limit on the number of networks a user can create within a group. Incorporating groups from OAuth may not offer substantial advantages, especially since this feature would require structured data in the OAuth scope for ztnet to recognize it effectively.

Nonetheless, I'm interested in understanding the potential structure of the groups object. Could you share an example of what this might look like?

Is it accurate to assume that the group object within the scope is configurable by the OAuth administrator?

[PovilasID]

Yes you can edit group assignments from OAuth provider side.
Importing them on login should not be much of an issue since you already have OAUTH_SCOPE="read:user user:email" and you can add read:group from already provided data. Now checking if if user still has the same group would be trickier... that should probably updated on every login at least. I am not sure how you handeled OAuth.

There are 3 ways to group permissions: roles/groups/organizations 'admin, user, manager' etc.
For me roles are most useful because I do not need more complex structures and a lot of other stuff uses them... though sometimes roles are mapped as groups and groups I think would be easier to start with.
Here is an example of groups and roles mixing https://grafana.com/docs/grafana/latest/setup-grafana/configure-security/configure-authentication/github/#configure-role-mapping (this not a good example because it produces fragile configs but it explains a lot)
Each client can have roles specific to it but also available for the entire permission realm.
To be honest... I do not care what pram group or role you import I can adjust.
Group as a user tag does not have a lot of value but is still useful when doing fleet management. I.e. in this department/project there should be X amount of users if I have fewer that means something has not been invited yet etc.
Roles would be more useful OAuth import but may be trickier because a lot of implementation of them and not does it the same...
Custom permissions is also an option. You can add some custom scopes that indicate specific permissions (like gihub does) this makes it more useful for advanced users but harder for novices.

[github-actions]

This issue is stale because it has been open for 30 days with no activity.