🚀 Feature: Restrict acces to user-groups #451

Closed
opened 2025-10-08 00:09:13 +03:00 by OVERLORD · 5 comments
Owner

Originally created by @stephanvane on GitHub.

Feature description

Hi,

I'm thinking about using pocket-id to handle authentication for multiple services. Each of them will have their own OIDC client.

The problem is that not every app has the same list of users. I'd like to be able to configure pocket-id in a way that, for example, allows:

  • users of 'group A' to access 'App A'
  • users of 'group B' to access 'App B'
  • users of 'group Admin' to acces both apps.

Pitch

The 'user group' settings seemed suitable for this, but as far as I can find there is no way to restrict an OIDC client to only one (or more) user-groups.

Any thoughts? 😄

Originally created by @stephanvane on GitHub. ### Feature description Hi, I'm thinking about using pocket-id to handle authentication for multiple services. Each of them will have their own OIDC client. The problem is that not every app has the same list of users. I'd like to be able to configure pocket-id in a way that, for example, allows: - users of 'group A' to access 'App A' - users of 'group B' to access 'App B' - users of 'group Admin' to acces both apps. ### Pitch The 'user group' settings seemed suitable for this, but as far as I can find there is no way to restrict an OIDC client to only one (or more) user-groups. Any thoughts? 😄
OVERLORD added the feature label 2025-10-08 00:09:13 +03:00
Author
Owner

@stephanvane commented on GitHub:

Thank you for all the suggestions. Unfortunately it's often not that easy to let the client handle this. For example Immich, a pretty popular project, doesn't have any field to define a specific group to allow access for.

I'm sure they could add this, but it would be a pretty big task to expect every client to do this.

Keycloak supports realms

A realm is a space where you manage objects, including users, applications, roles, and groups. A user belongs to and logs into a realm. One Keycloak deployment can define, store, and manage as many realms as there is space for in the database.

The way that pocket-id is designed now, would mean that I'd have to deploy one instance for every service that I want to give people access to.

To be able to share one user among multiple projects/realms would be perfect. But even a simpler solution where we can have multiple projects/realms with each their own set of users (leading to multiple accounts for some users) would be a pretty nice addition!

@stephanvane commented on GitHub: Thank you for all the suggestions. Unfortunately it's often not that easy to let the client handle this. For example Immich, a pretty popular project, doesn't have any field to define a specific group to allow access for. I'm sure they could add this, but it would be a pretty big task to expect **every** client to do this. Keycloak supports [realms](https://www.keycloak.org/docs/latest/server_admin/#_configuring-realms) > A realm is a space where you manage objects, including users, applications, roles, and groups. A user belongs to and logs into a realm. **One Keycloak deployment can define, store, and manage as many realms as there is space for in the database.** The way that pocket-id is designed now, would mean that I'd have to deploy one instance for every service that I want to give people access to. To be able to share one user among multiple projects/realms would be perfect. But even a simpler solution where we can have multiple projects/realms with each their own set of users (leading to multiple accounts for some users) would be a pretty nice addition!
Author
Owner

@stonith404 commented on GitHub:

@stephanvane In my opinion multiple projects/realms are an overkill for Pocket ID. The main goal of the project is to remain a simple OIDC provider. For more complex use cases, I would recommend using Keycloak.

@stonith404 commented on GitHub: @stephanvane In my opinion multiple projects/realms are an overkill for Pocket ID. The main goal of the project is to remain a simple OIDC provider. For more complex use cases, I would recommend using Keycloak.
Author
Owner

@phil3741 commented on GitHub:

You can assign Custom Claims not only to users, but also to user groups.

e.g. I defined a Custom Claim "roles" -> "admin" for certain users and use that in my Caddy Reverse proxy (with AuthCrunch), where i defined an authorization policy based on this role.

That works for me to restrict admin access to certain apps via pocket ID

@phil3741 commented on GitHub: You can assign Custom Claims not only to users, but also to user groups. e.g. I defined a Custom Claim "roles" -> "admin" for certain users and use that in my Caddy Reverse proxy (with AuthCrunch), where i defined an authorization policy based on this role. That works for me to restrict admin access to certain apps via pocket ID
Author
Owner

@stonith404 commented on GitHub:

I think this is something that should be handled by the client. Or do other providers like Keycloak support client authorization permissions?

@stonith404 commented on GitHub: I think this is something that should be handled by the client. Or do other providers like Keycloak support client authorization permissions?
Author
Owner

@simono41 commented on GitHub:

Well, I only know that with Grafana (i.e. the OIDC client itself) that you have to be a member of a certain group and if not, then the certain user doesn't work for the login.

grafik

The user must either be in the grafana_admin group, and or be in the Admin group for the normal admin. If he is not in one or both groups, the user is not created.

grafik

@simono41 commented on GitHub: Well, I only know that with Grafana (i.e. the OIDC client itself) that you have to be a member of a certain group and if not, then the certain user doesn't work for the login. ![grafik](https://github.com/user-attachments/assets/2d19b3b0-41fb-44f5-9b96-dcb79e5f0b2f) The user must either be in the grafana_admin group, and or be in the Admin group for the normal admin. If he is not in one or both groups, the user is not created. ![grafik](https://github.com/user-attachments/assets/4147df00-3c79-4ace-8876-405de696af16)
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/pocket-id-pocket-id-1#451