[GH-ISSUE #17510] User role from OAuth Entra ID assignment fails for users with more than 200 AD groups #138040

New Issue

GiteaMirror · 2026-05-25T09:12:13-05:00

GiteaMirror commented

2026-05-25 09:12:13 -05:00

Originally created by @TeodoraBrotea on GitHub (Sep 17, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/17510

Check Existing Issues

I have searched for any existing and/or related issues.
I have searched for any existing and/or related discussions.
I am using the latest version of Open WebUI.

Installation Method

Docker

Open WebUI Version

v0.6.28

Ollama Version (if applicable)

No response

Operating System

Ubuntu 22.04

Browser (if applicable)

No response

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 provided every relevant configuration, setting, and environment variable used in my setup.
I have clearly listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc).
I have documented step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation. My steps:
Start with the initial platform/version/OS and dependencies used,
Specify exact install/launch/configure commands,
List URLs visited, user input (incl. example values/emails/passwords if needed),
Describe all options and toggles enabled or changed,
Include any files or environmental changes,
Identify the expected and actual result at each stage,
Ensure any reasonably skilled user can follow and hit the same issue.

Expected Behavior

Enabling OIDC and setting OAUTH_ROLES_CLAIM to groups, would allow users to login and get an assigned role either as admin or users based on their group membership. Also, as a caution measure, DEFAULT_USER_ROLE would be set to pending so that users who are not members of the AD groups listed in OAUTH_ADMIN_ROLES and OAUTH_ALLOWED_ROLES won't be able to access OpenWebUI.

Actual Behavior

We have discovered a limitation during OAuth during the authorization process regarding the retrieval of Active Directory (AD) groups. This limitation affects users who are members of a large number of groups and impacts the role assignment functionality. The affected users are mainly the ones who belong to approximately 200 or more AD groups. Groups are not visible during the authorization process and role assignment based on AD groups fails to function properly. The effect is that users are automatically redirected to the default user role instead of their intended role.

Steps to Reproduce

Setup environment variables related to OAuth:

ENABLE_PERSISTENT_CONFIG: "False"
ENABLE_OAUTH_ROLE_MANAGEMENT: "True"
ENABLE_OAUTH_SIGNUP: "True"
DEFAULT_USER_ROLE: pending
OAUTH_ADMIN_ROLES: my-AD-admin-group
OAUTH_ALLOWED_ROLES: my-AD-user-group
OAUTH_ROLES_CLAIM: group
GLOBAL_LOG_LEVEL: DEBUG

Enable also OIDC login
Deploy the container with the above environment variables
Try to login with an account that has around 200 AD groups
In the UI you get assigned the default user role, pending, and see the message from the pending screen
In the pod logs, you will have the logs:

Running OAUTH role management
Oauth Role claim: groups
User roles from oauth: [[]

Try to login with an account that has less than 170 AD groups
You will be assigned the the correct role based on group membership
In the pod logs, you will have the logs:

Running OAUTH role management
Oauth Role claim: groups
User roles from oauth: ["group-1", "group-2", "my-AD-user-group"]
Accepted user roles: ["my-AD-user-group"]
Accepted admin roles: ["my-AD-admin-group"]
Assigned user to the user role

Logs & Screenshots

Less than 180 AD groups:

Around 200 AD groups:

Additional Information

We believe that the issue is related to the overage claim of Entra ID, but this is currently not supported in OpenWebUI. Implementing a solution for supporting the overage claim, more than 200 AD groups, would solve the issue.

Reference: https://learn.microsoft.com/en-us/troubleshoot/entra/entra-id/app-integration/get-signed-in-users-groups-in-access-token

Originally created by @TeodoraBrotea on GitHub (Sep 17, 2025). Original GitHub issue: https://github.com/open-webui/open-webui/issues/17510 ### Check Existing Issues - [x] I have searched for any existing and/or related issues. - [x] I have searched for any existing and/or related discussions. - [x] I am using the latest version of Open WebUI. ### Installation Method Docker ### Open WebUI Version v0.6.28 ### Ollama Version (if applicable) _No response_ ### Operating System Ubuntu 22.04 ### Browser (if applicable) _No response_ ### 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 **provided every relevant configuration, setting, and environment variable used in my setup.** - [x] I have clearly **listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup** (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc). - [x] I have documented **step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation**. My steps: - Start with the initial platform/version/OS and dependencies used, - Specify exact install/launch/configure commands, - List URLs visited, user input (incl. example values/emails/passwords if needed), - Describe all options and toggles enabled or changed, - Include any files or environmental changes, - Identify the expected and actual result at each stage, - Ensure any reasonably skilled user can follow and hit the same issue. ### Expected Behavior Enabling OIDC and setting `OAUTH_ROLES_CLAIM` to groups, would allow users to login and get an assigned role either as admin or users based on their group membership. Also, as a caution measure, `DEFAULT_USER_ROLE` would be set to `pending` so that users who are not members of the AD groups listed in `OAUTH_ADMIN_ROLES` and `OAUTH_ALLOWED_ROLES` won't be able to access OpenWebUI. ### Actual Behavior We have discovered a limitation during OAuth during the authorization process regarding the retrieval of Active Directory (AD) groups. This limitation affects users who are members of a large number of groups and impacts the role assignment functionality. The affected users are mainly the ones who belong to approximately 200 or more AD groups. Groups are not visible during the authorization process and role assignment based on AD groups fails to function properly. The effect is that users are automatically redirected to the default user role instead of their intended role. ### Steps to Reproduce 1. Setup environment variables related to OAuth: ```bash ENABLE_PERSISTENT_CONFIG: "False" ENABLE_OAUTH_ROLE_MANAGEMENT: "True" ENABLE_OAUTH_SIGNUP: "True" DEFAULT_USER_ROLE: pending OAUTH_ADMIN_ROLES: my-AD-admin-group OAUTH_ALLOWED_ROLES: my-AD-user-group OAUTH_ROLES_CLAIM: group GLOBAL_LOG_LEVEL: DEBUG ``` 2. Enable also OIDC login 3. Deploy the container with the above environment variables 4. Try to login with an account that has around 200 AD groups 5. In the UI you get assigned the default user role, pending, and see the message from the pending screen 6. In the pod logs, you will have the logs: ```bash Running OAUTH role management Oauth Role claim: groups User roles from oauth: [[] ``` 7. Try to login with an account that has less than 170 AD groups 8. You will be assigned the the correct role based on group membership 9. In the pod logs, you will have the logs: ```bash Running OAUTH role management Oauth Role claim: groups User roles from oauth: ["group-1", "group-2", "my-AD-user-group"] Accepted user roles: ["my-AD-user-group"] Accepted admin roles: ["my-AD-admin-group"] Assigned user to the user role ``` ### Logs & Screenshots Less than 180 AD groups: <img width="1486" height="429" alt="Image" src="https://github.com/user-attachments/assets/a1fdca76-0c77-4b9a-8c65-e04e9f2db517" /> Around 200 AD groups: <img width="581" height="113" alt="Image" src="https://github.com/user-attachments/assets/7bc305b9-41ae-416f-a566-7fce47661506" /> ### Additional Information We believe that the issue is related to the `overage claim` of Entra ID, but this is currently not supported in OpenWebUI. Implementing a solution for supporting the overage claim, more than 200 AD groups, would solve the issue. Reference: https://learn.microsoft.com/en-us/troubleshoot/entra/entra-id/app-integration/get-signed-in-users-groups-in-access-token

GiteaMirror added the bug label 2026-05-25 09:12:13 -05:00

GiteaMirror commented

2026-05-25 09:12:17 -05:00

@tusharrrr1 commented on GitHub (Sep 18, 2025):

Implement support for overage claims by:

1)Detecting the hasgroups claim.

2)Calling Microsoft Graph API to retrieve the user’s full group membership.

3)Using that data for role assignment.

Allow me to work on this if possible

@tusharrrr1 commented on GitHub (Sep 18, 2025): Implement support for overage claims by: 1)Detecting the hasgroups claim. 2)Calling Microsoft Graph API to retrieve the user’s full group membership. 3)Using that data for role assignment. Allow me to work on this if possible

GiteaMirror commented

2026-05-25 09:12:18 -05:00

@beng90 commented on GitHub (Oct 20, 2025):

I've experienced the same problem. Any workaround?

@beng90 commented on GitHub (Oct 20, 2025): I've experienced the same problem. Any workaround?

GiteaMirror commented

2026-05-25 09:12:24 -05:00

@Ruben-Wien commented on GitHub (Dec 22, 2025):

Hi, I may have a workaround (not a fix) based on how we configured Entra ID group/role forwarding to OpenWebUI.

What we did:

For the OAUTH_ROLES_CLAIM mapping, we used the default claim (roles) instead of trying to forward all Entra groups.
In Entra ID, we went to the Enterprise Application and explicitly assigned only the groups we actually want to pass through to OpenWebUI, and assigned them the appropriate app role:

Enterprise Applications → Your App → Users and groups
Add the selected groups and assign them the app role User or Admin.

Result: Not all groups are forwarded—only the groups explicitly assigned in Entra ID. This avoids the “too many groups” / token size issues and worked well for us.

This should also be automatable via a Terraform script.

My Config:

OAUTH_ROLES_CLAIM=roles
ENABLE_OAUTH_GROUP_MANAGEMENT=true
ENABLE_OAUTH_GROUP_CREATION=true
OAUTH_GROUP_CLAIM=groups
ENABLE_OAUTH_ROLE_MANAGEMENT=true
OAUTH_ALLOWED_ROLES=user,admin
OAUTH_ADMIN_ROLES=admin

@Ruben-Wien commented on GitHub (Dec 22, 2025): Hi, I may have a workaround (not a fix) based on how we configured Entra ID group/role forwarding to OpenWebUI. **What we did:** * For the `OAUTH_ROLES_CLAIM` mapping, we used the default claim (`roles`) instead of trying to forward all Entra groups. * In Entra ID, we went to the **Enterprise Application** and explicitly assigned **only the groups we actually want to pass through to OpenWebUI**, and assigned them the appropriate app role: Enterprise Applications → Your App → **Users and groups** Add the selected groups and assign them the app role **User** or **Admin**. **Result:** Not all groups are forwarded—only the groups explicitly assigned in Entra ID. This avoids the “too many groups” / token size issues and worked well for us. This should also be automatable via a Terraform script. My Config: OAUTH_ROLES_CLAIM=roles ENABLE_OAUTH_GROUP_MANAGEMENT=true ENABLE_OAUTH_GROUP_CREATION=true OAUTH_GROUP_CLAIM=groups ENABLE_OAUTH_ROLE_MANAGEMENT=true OAUTH_ALLOWED_ROLES=user,admin OAUTH_ADMIN_ROLES=admin

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/open-webui#138040