🚀 Feature: Per-client group mappings #566

New Issue

OVERLORD · 2026-02-04T20:29:25+03:00

OVERLORD commented

2026-02-04 20:29:25 +03:00

Originally created by @jc0b on GitHub (Dec 13, 2025).

Feature description

It should be possible to map group names to different values in the groups claim.
So, if you had a group in Pocket ID with name app_proxmox_admin, you would be able to (in the OIDC client settings) be able to specify that it should be passed with a different name through in the groups claim.

Pitch

Some applications expect specific groups to be passed in the groups claim for roles. For example, they expect that you are a member of the group admin to give you an admin role.

If you have a naming convention, then you suddenly have to break from this convention for one app. This could be circumvented with the mappings.

Originally created by @jc0b on GitHub (Dec 13, 2025). ### Feature description It should be possible to map group names to different values in the `groups` claim. So, if you had a group in Pocket ID with name `app_proxmox_admin`, you would be able to (in the OIDC client settings) be able to specify that it should be passed with a different name through in the `groups` claim. ### Pitch Some applications expect specific groups to be passed in the groups claim for roles. For example, they expect that you are a member of the group `admin` to give you an admin role. If you have a naming convention, then you suddenly have to break from this convention for one app. This could be circumvented with the mappings.

OVERLORD closed this issue

2026-02-04 20:29:30 +03:00

OVERLORD commented

2026-02-04 20:29:34 +03:00

@stonith404 commented on GitHub (Dec 21, 2025):

Tbh this feels like something that should be addressed on the OIDC client side. All OIDC clients I'm using allow you to configure which group users need to belong to in order to receive admin privileges, and that’s the correct place for this logic.

Implementing it on our side would essentially mean introducing a workaround for a design issue in the client rather than solving the root cause. Because of that, we don’t plan to implement this.

@stonith404 commented on GitHub (Dec 21, 2025): Tbh this feels like something that should be addressed on the OIDC client side. All OIDC clients I'm using allow you to configure which group users need to belong to in order to receive admin privileges, and that’s the correct place for this logic. Implementing it on our side would essentially mean introducing a workaround for a design issue in the client rather than solving the root cause. Because of that, we don’t plan to implement this.

OVERLORD referenced this issue

2026-02-04 20:57:42 +03:00

[PR #566] [MERGED] feat: JWT bearer assertions for client authentication #835

OVERLORD referenced this issue

2026-02-04 20:59:18 +03:00

[PR #636] [MERGED] chore: Add docs link and rename to Federated Client Credentials #860

OVERLORD referenced this issue

2026-02-04 20:59:22 +03:00

[PR #640] [MERGED] feat: allow introspection and device code endpoints to use Federated Client Credentials #861

Sign in to join this conversation.