🚀 Feature: Map allowed groups to applications #437

Closed
opened 2025-10-09 16:46:43 +03:00 by OVERLORD · 19 comments
Owner

Originally created by @luketainton on GitHub.

Feature description

Applications should have a list of allowed groups, i.e. groups of users that are allowed to use this application.

Pitch

This allows better control over which users can use which applications.

Example:
I'd like to be able to add a user to group "X" and then tell Pocket ID that for a user to be allowed access to an application, they must be in group "X". If the user signs into the app and they are in group "X" then it works as it does today. If they are not, Pocket ID should disallow authentication.

Originally created by @luketainton on GitHub. ### Feature description Applications should have a list of allowed groups, i.e. groups of users that are allowed to use this application. ### Pitch This allows better control over which users can use which applications. Example: I'd like to be able to add a user to group "X" and then tell Pocket ID that for a user to be allowed access to an application, they must be in group "X". If the user signs into the app and they are in group "X" then it works as it does today. If they are not, Pocket ID should disallow authentication.
OVERLORD added the feature label 2025-10-09 16:46:43 +03:00
Author
Owner

@simono41 commented on GitHub:

Isn't that something that the client should handle? For example Pingvin Share or Nextcloud allow you to specify which groups can access the service.

I also think, it could also be set at grafana that only certain groups have access to the dashboards.

But would be a cool feature if the pocket id could also regulate itself, e.g. such an exclude or include option which services can be used with the account and which cannot.

@simono41 commented on GitHub: > Isn't that something that the client should handle? For example Pingvin Share or Nextcloud allow you to specify which groups can access the service. I also think, it could also be set at grafana that only certain groups have access to the dashboards. But would be a cool feature if the pocket id could also regulate itself, e.g. such an exclude or include option which services can be used with the account and which cannot.
Author
Owner

@stonith404 commented on GitHub:

Okay, I see.

While I personally wouldn’t use this feature and believe that handling group-based access is more appropriately managed by the client, I’ll keep an eye on the interest level. If this feature request gets more likes (👍), I’ll consider implementing it.

Of course I'm also open for a pull request.

@stonith404 commented on GitHub: Okay, I see. While I personally wouldn’t use this feature and believe that handling group-based access is more appropriately managed by the client, I’ll keep an eye on the interest level. If this feature request gets more likes (👍), I’ll consider implementing it. Of course I'm also open for a pull request.
Author
Owner

@stonith404 commented on GitHub:

This feature has received a lot of attention, so I’ll probably work on it after finishing the LDAP implementation.

@stonith404 commented on GitHub: This feature has received a lot of attention, so I’ll probably work on it after finishing the LDAP implementation.
Author
Owner

@stonith404 commented on GitHub:

Isn't that something that the client should handle? For example Pingvin Share or Nextcloud allow you to specify which groups can access the service.

@stonith404 commented on GitHub: Isn't that something that the client should handle? For example Pingvin Share or Nextcloud allow you to specify which groups can access the service.
Author
Owner

@luketainton commented on GitHub:

Isn't that something that the client should handle? For example Pingvin Share or Nextcloud allow you to specify which groups can access the service.

In an ideal world yes each client would handle this themselves, but unfortunately there are plenty of applications out there that don't. Some examples:

@luketainton commented on GitHub: > Isn't that something that the client should handle? For example Pingvin Share or Nextcloud allow you to specify which groups can access the service. In an ideal world yes each client would handle this themselves, but unfortunately there are plenty of applications out there that don't. Some examples: - [GlitchTip](https://glitchtip.com) - [Gatus](https://gatus.io) (you can tell it specific users to allow but not groups) - [Stirling PDF](https://stirlingpdf.com)
Author
Owner

@fallenleavesgocrunch commented on GitHub:

I just found this issue too. I may have missed something but both Hoarder and Seafile don't seem to have a way to specify what groups to allow. The ideal world the clients would handle this but the reality seems to be the oidc provider needs to.

To expand on this - I use caddy security and I reverse_proxy seafile. This was working great because caddy lets me select the required groups to use. But then I added seadoc and seadoc refused to work behind caddy security. I configured seafile as an oidc client instead and of course now I cannot specify the group to use. sigh.

@fallenleavesgocrunch commented on GitHub: I just found this issue too. I may have missed something but both Hoarder and Seafile don't seem to have a way to specify what groups to allow. The ideal world the clients would handle this but the reality seems to be the oidc provider needs to. To expand on this - I use caddy security and I reverse_proxy seafile. This was working great because caddy lets me select the required groups to use. But then I added seadoc and seadoc refused to work behind caddy security. I configured seafile as an oidc client instead and of course now I cannot specify the group to use. *sigh*.
Author
Owner

@halictuz commented on GitHub:

I was redirected to this issue. I upvote it. Would be great to see this feature. Its the only thing im missing from Authentik.

One more example. WHen using oauth2-proxy with Pocket ID it would be cool to handle access rights within Pocket ID even for such services that do not have OIDC/SSO support. While I also agree, that the services itself should handle the groups and users themselves. The reality is different though.

@halictuz commented on GitHub: I was redirected to this issue. I upvote it. Would be great to see this feature. Its the only thing im missing from Authentik. One more example. WHen using oauth2-proxy with Pocket ID it would be cool to handle access rights within Pocket ID even for such services that do not have OIDC/SSO support. While I also agree, that the services itself should handle the groups and users themselves. The reality is different though.
Author
Owner

@Mattchewone commented on GitHub:

I agree, I have multiple apps that just pull back profile but don't reject based on groups. So having pocketid set the allowed users/groups to the OIDC clients would be a really nice feature

@Mattchewone commented on GitHub: I agree, I have multiple apps that just pull back profile but don't reject based on groups. So having pocketid set the allowed users/groups to the OIDC clients would be a really nice feature
Author
Owner

@daniel-tp commented on GitHub:

I was redirected to this issue. I upvote it. Would be great to see this feature. Its the only thing im missing from Authentik.

One more example. WHen using oauth2-proxy with Pocket ID it would be cool to handle access rights within Pocket ID even for such services that do not have OIDC/SSO support. While I also agree, that the services itself should handle the groups and users themselves. The reality is different though.

Yes I have been looking into this recently. I have Pocket-ID setup with Vouch Proxy, and found that while it works it is a very blanket solution. While currently per-client permissions can't be set in pocket-ID, when it is I think the only current solution (Beyond pocket-ID implementing it's own forward-auth or similar) is to have a different instance (and thus client credentials) of oauth2proxy/vouch per client that doesn't support OIDC. This may work for some, but isn't great for me.

@daniel-tp commented on GitHub: > I was redirected to this issue. I upvote it. Would be great to see this feature. Its the only thing im missing from Authentik. > > One more example. WHen using oauth2-proxy with Pocket ID it would be cool to handle access rights within Pocket ID even for such services that do not have OIDC/SSO support. While I also agree, that the services itself should handle the groups and users themselves. The reality is different though. Yes I have been looking into this recently. I have Pocket-ID setup with Vouch Proxy, and found that while it works it is a very blanket solution. While currently per-client permissions can't be set in pocket-ID, when it is I think the only current solution (Beyond pocket-ID implementing it's own forward-auth or similar) is to have a different instance (and thus client credentials) of oauth2proxy/vouch per client that doesn't support OIDC. This may work for some, but isn't great for me.
Author
Owner

@ExXxtr3me commented on GitHub:

Great that you want to implent this feature, i think it makes it easier for someone that's not a pro with setting SSO up, it' would be much easier to just allow a group access to an application in Pocket ID than to set it up in some applications. 👍

@ExXxtr3me commented on GitHub: Great that you want to implent this feature, i think it makes it easier for someone that's not a pro with setting SSO up, it' would be much easier to just allow a group access to an application in Pocket ID than to set it up in some applications. 👍
Author
Owner

@fallenleavesgocrunch commented on GitHub:

Also - timing couldn't be better. With the home-assistant issues I ended up installing an oidc client in that and it looks for groups: instead of roles: with its query, so I couldn't correctly set the 'users' vs 'admin' group properly in its configuration. Now I can block right in pocket-id and have it pick up 'group' for the admin role.

@fallenleavesgocrunch commented on GitHub: Also - timing couldn't be better. With the home-assistant issues I ended up installing an oidc client in that and it looks for groups: instead of roles: with its query, so I couldn't correctly set the 'users' vs 'admin' group properly in its configuration. Now I can block right in pocket-id and have it pick up 'group' for the admin role.
Author
Owner

@stonith404 commented on GitHub:

I've just created a first version of this feature. If you want to test it you can use the stonith404/pocket-id:development image. I would appreciate some feedback :) For example is the setup confusing or are there features that I missed?

Image

@stonith404 commented on GitHub: I've just created a first version of this feature. If you want to test it you can use the `stonith404/pocket-id:development` image. I would appreciate some feedback :) For example is the setup confusing or are there features that I missed? ![Image](https://github.com/user-attachments/assets/b3ef3fdb-faca-43d4-b492-2208832ba25a)
Author
Owner

@luketainton commented on GitHub:

Your screenshot looks really good :)

I've just pulled the development image and when trying to edit the OIDC client I get this - not sure if it's just me or not though.

Image
@luketainton commented on GitHub: Your screenshot looks really good :) I've just pulled the development image and when trying to edit the OIDC client I get this - not sure if it's just me or not though. <img width="940" alt="Image" src="https://github.com/user-attachments/assets/9a6e4979-a8d6-4ea3-9dd2-8c772d32900b" />
Author
Owner

@stonith404 commented on GitHub:

@luketainton Hm okay, could you share the container logs?

@stonith404 commented on GitHub: @luketainton Hm okay, could you share the container logs?
Author
Owner

@fallenleavesgocrunch commented on GitHub:

Looking very good so far!

@fallenleavesgocrunch commented on GitHub: Looking very good so far!
Author
Owner

@stonith404 commented on GitHub:

Released in v0.28.0.

@stonith404 commented on GitHub: Released in `v0.28.0`.
Author
Owner

@luketainton commented on GitHub:

Image

Potentially didn't migrate the DB when I upgraded the container image to development?

@luketainton commented on GitHub: <img width="1220" alt="Image" src="https://github.com/user-attachments/assets/64794491-a78b-47db-aee1-61f1d365a176" /> Potentially didn't migrate the DB when I upgraded the container image to `development`?
Author
Owner

@stonith404 commented on GitHub:

@luketainton Thanks for sharing the logs. I forgot to add the migrations for Postgres. Could you try the latest development image again?

@stonith404 commented on GitHub: @luketainton Thanks for sharing the logs. I forgot to add the migrations for Postgres. Could you try the latest `development` image again?
Author
Owner

@luketainton commented on GitHub:

@stonith404 working now, thanks! Will test and provide feedback but this is already looking very promising. Appreciate you taking the time to implement this.

@luketainton commented on GitHub: @stonith404 working now, thanks! Will test and provide feedback but this is already looking very promising. Appreciate you taking the time to implement this.
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-2#437