mirror of
https://github.com/fosrl/pangolin.git
synced 2026-05-22 09:32:36 -05:00
[GH-ISSUE #737] OIDC User being removed from Organisation #6397
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/pangolin#6397
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @joshdinsdale on GitHub (May 16, 2025).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/737
Originally assigned to: @miloschwartz on GitHub.
Added my Pocket ID admin user to Pangolin and set it to have the Admin role.
Open an incognito browser tab and connect to one of my proxied resources that is Uprotected in Pangolin and uses OIDC to auth directly with pocket touch. I am redirected to Pocket Touch, login and amsucesfully redirected to the resource.
I open another tab, and connect to a Protected resource, i get the Pangolin login page and choose the pocket id login option, i am already authed but am then told by Pangolin that i do not have access.
In my other browser logged into Pangolin as admin, i browse to users for the resource and find that my pocket id user no longer shows in the user list. If i go to Server Admin I can see the users in the list here.
Some mechanism in Pangolin is removing this user from the site.
@jhedfors commented on GitHub (May 16, 2025):
I am having the exact same thing happening using Google identity provider.
https://www.reddit.com/r/PangolinReverseProxy/comments/1klunp7/access_denied/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button
I also posted my issue on the Discord support channel.
@joshdinsdale commented on GitHub (May 16, 2025):
I've just confirmed this for another user account on my system byt logging in withe a 1-time link, unprotected resources are fine, but as soon as the user tries to access a protected resource something is removing the account from the organisation.
@jonzey231 commented on GitHub (May 16, 2025):
I'm seeing this intermittently with Google Auth. Seems fine for some users but completely breaks with others even thought they were all setup at the same time the same way.
@jonzey231 commented on GitHub (May 16, 2025):
Disable Auto provisioning if you're not actively using it to assign roles/orgs. It fixes this issue.
@joshdinsdale commented on GitHub (May 16, 2025):
This sounds promising, I did turn this on after upgrading. Will disable and visit a try.
Thanks!
@joshdinsdale commented on GitHub (May 16, 2025):
I can confirm disabling auto provisioning worked for me.
@jonzey231 commented on GitHub (May 16, 2025):
Awesome. Glad it's working now.
@Hutch79 commented on GitHub (May 19, 2025):
Same problem with Authentik.
Can confirm that disabling Auto Provisioning works as a Workaround.
@jonzey231 commented on GitHub (May 19, 2025):
Glad it's working now.
@themadcodger commented on GitHub (May 21, 2025):
Ahh, this fixed it for me too.
@SiriXAU commented on GitHub (May 30, 2025):
I found the exact same issue, account was created & working in Pangolin with Pocket ID as the OIDC, everything worked, turned on auto provision to see what would happen and ran into this, seems like it's missing a way to make the connection with the organisation after this happens.
Ie. The auto-provision only seems to be able to provision a new user, and they need to create a new org? they can't select an existing one from their end, and the admin, although you can see the user in the Server Admin > All Users, you can't select the user and put them into an org seemingly.
@kmanwar89 commented on GitHub (Jun 2, 2025):
+1 that disabling the auto provision worked.
@github-actions[bot] commented on GitHub (Jun 17, 2025):
This issue has been automatically marked as stale due to 14 days of inactivity. It will be closed in 14 days if no further activity occurs.
@sepffuzzball commented on GitHub (Jun 22, 2025):
Yeah I definitely had this issue - is there any way with the admin user to add either the admin or an OIDC user (I use Authentik) back into an Organization? Currently via the UI it seems I have no good way to add someone back to the org.
I've disabled auto-provision, but apparently since I created the org/site I was using as the OIDC user (I hate staying logged in as an admin) I can't seem to get to it.
Edit: Just looked up the schema and updated the database to insert my user so all good, but yeah, would be nice to fix!
@myhrmans commented on GitHub (Jun 28, 2025):
Same issue here, as soon as they authenticate on a new device or after getting signed out they are removed from the organization.
@miloschwartz commented on GitHub (Jun 30, 2025):
@myhrmans If auto provision is enabled, on each log in the policies you set are re-checked, so if the policies don't match the user to a org/role then they aren't put in that org (if they were previously in it, they'd be removed)
@boomam commented on GitHub (Jul 18, 2025):
Disabling auto-provision is not a solution, its a workaround.
This still needs to be investigated and resolved.
@Hutch79 commented on GitHub (Aug 29, 2025):
Is there an update on this?
This bug limits the use of SSO severely and is still not fixed.
Is there a way as a non TypeScript savvy person to help fix this bug?
@miloschwartz commented on GitHub (Dec 4, 2025):
Unless there is a bug with auto provisioning this sounds like it's working as intended. Auto provisioning requires upfront manual configuration. It's up to the admin who sets up the IDP to configure a policy that maps user's based on criteria to organizations. Once setup users will be automatically created and placed into the correct roles and orgs based on the expressions. You can map users to all organizations, or you map them to specific orgs based on groups, etc. Users will be removed from an organization if the policy doesn't resolve them to the org. In newer versions of Pangolin, once a user is created, and if the IDP has auto provision enabled, there is a toggle on the user in the org users table where you can override auto provision.
@boomam commented on GitHub (Dec 4, 2025):
@miloschwartz
I think there's a misunderstanding as to what the issue being reported is. Its not a case of what is creating/managing the users.
The issue is that often an already provisioned user is getting removed from Pangolin, so the next login, anything applied too it already are lost.
Similar to others, it makes OIDC a difficult feature to use in production, as there is currently no inherent guarantee that a config would apply to make it usable.
You're correct in so far that policies can be applied to apply defaults to the OIDC user on login, but even that is a little flakey at times tbh.
Ultimately, if a user has had manual configs applied to them, they should stick until such time that they are removed from Pangolin.
@miloschwartz commented on GitHub (Dec 4, 2025):
I believe this is already supported. Once a user is auto provisioned, if you manually change the role, this auto provision checkbox turns off. The auto provision algorithm on login should respect this. Otherwise, every time you login the auto provision algorithm runs again and will updates the values (as expected).
The output is deterministic because it's based on the JMES path expression you input. It should always return the same values you define unless the info provided from the IDP changes like if the group in the IdP changes.
Note that if a user is "auto provisioned" and not actually mapped to an org, once the user creates an org, they will be removed from that org unless the expression maps them to the org. Again this is intended, but can be confusing. Not saying it can't be handled better though.
Maybe it'd be helpful if you can provide exact steps or even a video so I can see if this is actually just a bug or confusing behavior.
@boomam commented on GitHub (Dec 4, 2025):
Maybe that's the issue then.
It should just be updating on each login, as a lot of other OIDC clients do, but instead the user is having its config wiped?
Re: Steps
Setup OIDC, Setup default mappings, Login - rinse and repeat. :-p
Can't speak for others, but that's literally what i do. Nothing complicated.
Happy to send logs when i get some time, but maybe others can chime in to comment on both their OIDC configs and mappings and what they observe - just in case its one or several issues being conflated.
@Hutch79 commented on GitHub (Dec 5, 2025):
I think the current system, although very capable, is somewhat unintuitive even to more experienced users.
The "Auto Provisioned" checkbox is the best solution for manually changing user permissions. Nothing to complain there.
The group mapping with JMES path expression is the main confusing part for me.
It provides grate customizability, but is kinda complex if you never used such a system. Personally, I still don't fully understand the syntax.
It may also be a documentation issue. At least, when I played around with it, the docs did not provide much help regarding the syntax.
I think a way to improve the state of OIDC in Pangolin would be to move the OIDC Providers from the admin dashboard to a per org basis, so every org can configure their own providers.
This will be a huge change and may also be an EE or Cloud only feature.
But this way you'd remove the default org mapping and could offer an option to auto create groups from the IDP if a user has one.
The auto created groups would be a grate help for me personally. But with this we're at the discussion of the current 1..1 relation between users and groups, which would need to change to a 1..n relation for this to work properly.