github-starred/open-webui
2
0
Fork 0
mirror of https://github.com/open-webui/open-webui.git synced 2026-07-16 14:39:31 -05:00
Code Issues 2.4k Packages Projects Releases 129 Wiki Activity

[GH-ISSUE #13676] issue: OAUTH_ALLOWED_ROLES ignored, everyone is able to login with a valid OIDC token. #103990

New Issue
Closed
opened 2026-05-18 01:38:36 -05:00 by GiteaMirror · 7 comments
GiteaMirror commented 2026-05-18 01:38:36 -05:00
Owner
Copy Link

Originally created by @tht on GitHub (May 8, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/13676

Check Existing Issues

  • I have searched the existing issues and discussions.
  • I am using the latest version of Open WebUI.

Installation Method

Other

Open WebUI Version

v0.6.7

Ollama Version (if applicable)

No response

Operating System

Kubernetes Installation

Browser (if applicable)

Edge, Brave

Confirmation

  • I have read and followed all instructions in README.md.
  • I am using the latest version of both Open WebUI and Ollama.
  • I have included the browser console logs.
  • I have included the Docker container logs.
  • I have listed steps to reproduce the bug in detail.

Expected Behavior

We use SSO using Keycloak as IDP. Keycloak does provide the Roles for User (GPT_USER) and Admin (GPT_ADMIN). We do have a lot of additional users in Keycloak which DO NOT have any of these two Roles.

When setting OAUTH_ALLOWED_ROLES to GPT_USER I expect only the users with the role GPT_USER to be able to login. This is what I expect looking a the documentation where this is written:

OAUTH_ALLOWED_ROLES - A comma-separated list of roles that are allowed to log in (receive open webui role user). (https://docs.openwebui.com/features/sso/#oauth-role-management)

Actual Behavior

It seems the parameter OAUTH_ALLOWED_ROLES is ignored. Every user with a valid ticket from Keycloak is able to log in even if the role GPT_USER is missing.

Looking at https://github.com/open-webui/open-webui/blob/v0.6.7/backend/open_webui/utils/oauth.py#L297 it seems OAUTH_ALLOWED_ROLES is not checked when logging in.

Steps to Reproduce

  1. Make sure you have SSO configured using an OIDC Identity Provider.
  2. Add OAUTH_ALLOWED_ROLES to the configuration and set to a random string which DOES NOT match an user's role.
  3. Restart Open WebUI
  4. Try to log in with a user. It should not work as the role is missing. But it does work.

Login like this works for existing users and also for new users.

Logs & Screenshots

Login from a new User missing the role:

open_webui.utils.oauth:get_user_role:98 - Running OAUTH Role management - {}
open_webui.utils.oauth:get_user_role:114 - Oauth Roles claim: roles - {}
open_webui.utils.oauth:get_user_role:115 - User roles from oauth: [] - {}
open_webui.utils.oauth:get_user_role:116 - Accepted user roles: ['gpt_NONEXIStING_user'] - {}
open_webui.utils.oauth:get_user_role:117 - Accepted admin roles: ['gpt_admin'] - {}
open_webui.utils.oauth:update_user_groups:145 - Running OAUTH Group management - {}
open_webui.utils.oauth:update_user_groups:174 - Checking for missing groups to create... - {}
open_webui.utils.oauth:update_user_groups:180 - Using creator ID 540xxxxxxxxxxxx9155 for potential group creation. - {}
open_webui.utils.oauth:update_user_groups:217 - Oauth Groups claim: groups - {}
open_webui.utils.oauth:update_user_groups:218 - User oauth groups: [] - {}
open_webui.utils.oauth:update_user_groups:219 - User's current groups: [] - {}
open_webui.utils.oauth:update_user_groups:220 - All groups available in OpenWebUI: ['Testgroup2', 'Power User', 'Testgroup1'] - {}

Browser logs not attached as this is a backend issue. The backend does have to prevent a login.

Additional Information

No response

Originally created by @tht on GitHub (May 8, 2025). Original GitHub issue: https://github.com/open-webui/open-webui/issues/13676 ### Check Existing Issues - [x] I have searched the existing issues and discussions. - [x] I am using the latest version of Open WebUI. ### Installation Method Other ### Open WebUI Version v0.6.7 ### Ollama Version (if applicable) _No response_ ### Operating System Kubernetes Installation ### Browser (if applicable) Edge, Brave ### Confirmation - [x] I have read and followed all instructions in `README.md`. - [x] I am using the latest version of **both** Open WebUI and Ollama. - [x] I have included the browser console logs. - [x] I have included the Docker container logs. - [x] I have listed steps to reproduce the bug in detail. ### Expected Behavior We use SSO using Keycloak as IDP. Keycloak does provide the Roles for User (GPT_USER) and Admin (GPT_ADMIN). We do have a lot of additional users in Keycloak which DO NOT have any of these two Roles. When setting `OAUTH_ALLOWED_ROLES` to `GPT_USER` I expect only the users with the role GPT_USER to be able to login. This is what I expect looking a the documentation where this is written: > OAUTH_ALLOWED_ROLES - A comma-separated list of roles that are allowed to log in (receive open webui role user). (https://docs.openwebui.com/features/sso/#oauth-role-management) ### Actual Behavior It seems the parameter `OAUTH_ALLOWED_ROLES` is ignored. Every user with a valid ticket from Keycloak is able to log in even if the role `GPT_USER` is missing. Looking at https://github.com/open-webui/open-webui/blob/v0.6.7/backend/open_webui/utils/oauth.py#L297 it seems `OAUTH_ALLOWED_ROLES` is not checked when logging in. ### Steps to Reproduce 1. Make sure you have SSO configured using an OIDC Identity Provider. 2. Add `OAUTH_ALLOWED_ROLES` to the configuration and set to a random string which DOES NOT match an user's role. 3. Restart Open WebUI 4. Try to log in with a user. It should not work as the role is missing. But it does work. Login like this works for existing users and also for new users. ### Logs & Screenshots Login from a new User missing the role: ``` open_webui.utils.oauth:get_user_role:98 - Running OAUTH Role management - {} open_webui.utils.oauth:get_user_role:114 - Oauth Roles claim: roles - {} open_webui.utils.oauth:get_user_role:115 - User roles from oauth: [] - {} open_webui.utils.oauth:get_user_role:116 - Accepted user roles: ['gpt_NONEXIStING_user'] - {} open_webui.utils.oauth:get_user_role:117 - Accepted admin roles: ['gpt_admin'] - {} open_webui.utils.oauth:update_user_groups:145 - Running OAUTH Group management - {} open_webui.utils.oauth:update_user_groups:174 - Checking for missing groups to create... - {} open_webui.utils.oauth:update_user_groups:180 - Using creator ID 540xxxxxxxxxxxx9155 for potential group creation. - {} open_webui.utils.oauth:update_user_groups:217 - Oauth Groups claim: groups - {} open_webui.utils.oauth:update_user_groups:218 - User oauth groups: [] - {} open_webui.utils.oauth:update_user_groups:219 - User's current groups: [] - {} open_webui.utils.oauth:update_user_groups:220 - All groups available in OpenWebUI: ['Testgroup2', 'Power User', 'Testgroup1'] - {} ``` Browser logs not attached as this is a backend issue. The backend does have to prevent a login. ### Additional Information _No response_
GiteaMirror added the bug label 2026-05-18 01:38:36 -05:00
GiteaMirror commented 2026-05-18 01:38:38 -05:00
Author
Owner
Copy Link

@Menschomat commented on GitHub (May 11, 2025):

Hey there,
we are experiencing that, too!

As a work-around I switched DEFAULT_USER_ROLE to pending.
With Authentik you can easily decide which user can access an application/client. For KeyCloak this seems to be more complicated.
Having a fix for this security-relevant feature indeed would be great.

<!-- gh-comment-id:2869539391 --> @Menschomat commented on GitHub (May 11, 2025): Hey there, we are experiencing that, too! As a work-around I switched `DEFAULT_USER_ROLE` to `pending`. With Authentik you can easily decide which user can access an application/client. For KeyCloak this seems to be more complicated. Having a fix for this security-relevant feature indeed would be great.
GiteaMirror commented 2026-05-18 01:38:39 -05:00
Author
Owner
Copy Link

@tht commented on GitHub (May 12, 2025):

I think we identified the issue. It is this line: 4ce1e88750/backend/open_webui/utils/oauth.py (L122)

Assume a user DOES not have the admin or user role in the OIDC ticket, then we receive an empty list here. An empty list is not True in Python so we never enter this block and the user keeps DEFAULT_USER_ROLE as this was assigned before.

So this may even be by design. In this case the documentation should be updated as this is IMHO not correct:

OAUTH_ALLOWED_ROLES - A comma-separated list of roles that are allowed to log in (receive open webui role user).

As proposed by @Menschomat setting DEFAULT_USER_ROLE does help. What remains is the wrong message a non-authorised user gets. Instead of a access denied he's shown a "access pending" message.

<!-- gh-comment-id:2871560223 --> @tht commented on GitHub (May 12, 2025): I think we identified the issue. It is this line: https://github.com/open-webui/open-webui/blob/4ce1e88750c6da2f94b834697902ceb9f5524726/backend/open_webui/utils/oauth.py#L122 Assume a user DOES not have the *admin* or *user* role in the OIDC ticket, then we receive an empty list here. An empty list is not `True` in Python so we never enter this block and the user keeps `DEFAULT_USER_ROLE` as this was assigned before. So this may even be *by design*. In this case the documentation should be updated as this is IMHO not correct: > OAUTH_ALLOWED_ROLES - A comma-separated list of roles that are allowed to log in (receive open webui role user). As proposed by @Menschomat setting `DEFAULT_USER_ROLE` does help. What remains is the *wrong* message a non-authorised user gets. Instead of a access denied he's shown a "access pending" message.
GiteaMirror commented 2026-05-18 01:38:39 -05:00
Author
Owner
Copy Link

@tjbck commented on GitHub (May 23, 2025):

docs need to be updated, PR welcome!

<!-- gh-comment-id:2904924801 --> @tjbck commented on GitHub (May 23, 2025): docs need to be updated, PR welcome!
GiteaMirror commented 2026-05-18 01:38:40 -05:00
Author
Owner
Copy Link

@Menschomat commented on GitHub (May 25, 2025):

@tjbck I hope it is not just me, but I love to have this actually fixed... Using OpenWebUI in e.g. an institution for a limited user-base would lead to many unnecessary pending requests. This still keeps "unwanted" users out, but could be avoided if the access could actually be limited to a certian set of user-groups.
Maye an easy way out could be to provide the possibility to set the DEFAULT_USER_ROLE to something like "forbidden". This way you are a bit more flexible than just do a hard restriction by OAUTH_ALLOWED_ROLES.

<!-- gh-comment-id:2907698146 --> @Menschomat commented on GitHub (May 25, 2025): @tjbck I hope it is not just me, but I love to have this actually fixed... Using OpenWebUI in e.g. an institution for a limited user-base would lead to many unnecessary pending requests. This still keeps "unwanted" users out, but could be avoided if the access could actually be limited to a certian set of user-groups. Maye an easy way out could be to provide the possibility to set the DEFAULT_USER_ROLE to something like "forbidden". This way you are a bit more flexible than just do a hard restriction by OAUTH_ALLOWED_ROLES.
GiteaMirror commented 2026-05-18 01:38:40 -05:00
Author
Owner
Copy Link

@AlbertDoesProgramming commented on GitHub (Sep 8, 2025):

So I think this is still an issue since I've come across this myself today. I'll try and sort out in the next 2 weeks time permitting.

<!-- gh-comment-id:3267887159 --> @AlbertDoesProgramming commented on GitHub (Sep 8, 2025): So I think this is still an issue since I've come across this myself today. I'll try and sort out in the next 2 weeks time permitting.
GiteaMirror commented 2026-05-18 01:38:40 -05:00
Author
Owner
Copy Link

@ibizaman commented on GitHub (Oct 9, 2025):

FYI I created a discussion before opening a PR: https://github.com/open-webui/open-webui/discussions/18170

<!-- gh-comment-id:3383600401 --> @ibizaman commented on GitHub (Oct 9, 2025): FYI I created a discussion before opening a PR: https://github.com/open-webui/open-webui/discussions/18170
GiteaMirror commented 2026-05-18 01:38:41 -05:00
Author
Owner
Copy Link

@wolfaba commented on GitHub (Nov 7, 2025):

Version 0.6.36 still affected. User without user and admin role can still login. Setting DEFAULT_USER_ROLE to pending does not help. As workaround, we have to configure OIDC in apache reverse proxy to correctly deny access to unauthorized users.

<!-- gh-comment-id:3501783277 --> @wolfaba commented on GitHub (Nov 7, 2025): Version 0.6.36 still affected. User without `user` and `admin` role can still login. Setting `DEFAULT_USER_ROLE` to `pending` does not help. As workaround, we have to configure OIDC in apache reverse proxy to correctly deny access to unauthorized users.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
confirmed
confirmed issue
core
documentation
enhancement
good first issue
help wanted
non-core
pull-request
Mirrored from GitHub Pull Request
 python
question
testing wanted
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/open-webui#103990
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?