feat: Add a way to set OAuth response_mode and handle large groups claim (AD FS + allatclaims) #6309

New Issue

2025-11-11T16:50:39-06:00

GiteaMirror commented

2025-11-11 16:50:39 -06:00

Originally created by @m20l22 on GitHub (Sep 3, 2025).

Check Existing Issues

I have searched the existing issues and discussions.

Problem Description

I’m running Open WebUI with Microsoft AD FS as the OIDC provider and I use OAuth Group Management by emitting a groups claim (enabled via the AD FS allatclaims scope). In practice, AD FS + allatclaims works and users can authenticate successfully, and Open WebUI reads groups on login.

However, when a user belongs to many groups, the resulting ID/access token (with the groups claim) becomes large. Open WebUI appears to store token data in a cookie, and for users with a large groups claim this exceeds common browser cookie size limits. The net effect is:

Authentication succeeds, but
Group membership in Open WebUI does not update for that user (the large claim can’t be persisted/processed because the cookie is too big).

Separately, Microsoft’s guidance for AD FS when customizing ID tokens (e.g., to include extra claims like groups) requires using response_mode=form_post. Open WebUI currently has no configuration/env var to set response_mode, so AD FS deployments can’t explicitly choose form_post.

Desired Solution you'd like

Configurable response_mode: Add an environment variable (and/or admin setting) to control the OIDC authorization request response_mode. Example:

OAUTH_RESPONSE_MODE=form_post|query|fragment
If set, include response_mode=<value> on the /authorize request.

Handle large claims without cookie overflow (any one of the below would help):

Store tokens (or parsed claims) server-side and keep only a session identifier in the cookie.
Allow using the UserInfo endpoint to fetch the groups claim on login instead of relying on a large ID/access token in the cookie.
Provide an option to strip or compress large claims from the cookie while still using them once during the login callback to update groups.

Either (2a), (2b), or (2c) would prevent group sync from silently failing when the groups claim is large.

Alternatives Considered

Reducing group memberships / claim size: Not practical in enterprise AD environments.
Mapping groups to a smaller claim: Possible, but still risks hitting size limits for some users.
Switching IdP (e.g., Keycloak/Okta): Not feasible for organizations standardized on AD FS.
Relying only on access tokens: Doesn’t address cookie size if the access token itself is large and stored the same way.

Additional Context

Scenario: AD FS emits groups via allatclaims; Open WebUI parses groups on login to assign roles/teams. Works for users with few groups. Fails to update groups for users with many groups due to cookie size.
Request is twofold:
1. Add OAUTH_RESPONSE_MODE so AD FS setups can use form_post per Microsoft guidance.
2. Add a mechanism to handle large groups claims without exceeding cookie limits (server-side session, UserInfo fetch, or similar).
Repro (simplified):
1. Configure AD FS client with claim rules to emit groups; grant allatclaims.
2. Enable Open WebUI SSO with group management (groups claim).
3. Log in as a user who belongs to a large number of groups.
4. Observe: login succeeds, but the user’s groups in Open WebUI are not updated.

Originally created by @m20l22 on GitHub (Sep 3, 2025). ### Check Existing Issues - [x] I have searched the existing issues and discussions. ### Problem Description I’m running Open WebUI with Microsoft AD FS as the OIDC provider and I use OAuth Group Management by emitting a `groups` claim (enabled via the AD FS `allatclaims` scope). In practice, AD FS + `allatclaims` works and users can authenticate successfully, and Open WebUI reads groups on login. However, when a user belongs to many groups, the resulting ID/access token (with the `groups` claim) becomes large. Open WebUI appears to store token data in a cookie, and for users with a large `groups` claim this exceeds common browser cookie size limits. The net effect is: - Authentication succeeds, but - Group membership in Open WebUI does not update for that user (the large claim can’t be persisted/processed because the cookie is too big). Separately, [Microsoft’s guidance for AD FS when customizing ID tokens](https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/development/ad-fs-openid-connect-oauth-concepts#customize-id-token-extra-claims-in-id-token) (e.g., to include extra claims like `groups`) requires using `response_mode=form_post`. Open WebUI currently has no configuration/env var to set `response_mode`, so AD FS deployments can’t explicitly choose `form_post`. ### Desired Solution you'd like 1. Configurable `response_mode`: Add an environment variable (and/or admin setting) to control the OIDC authorization request `response_mode`. Example: - `OAUTH_RESPONSE_MODE=form_post|query|fragment` - If set, include `response_mode=<value>` on the `/authorize` request. 2. Handle large claims without cookie overflow (any one of the below would help): - Store tokens (or parsed claims) server-side and keep only a session identifier in the cookie. - Allow using the UserInfo endpoint to fetch the `groups` claim on login instead of relying on a large ID/access token in the cookie. - Provide an option to strip or compress large claims from the cookie while still using them once during the login callback to update groups. Either (2a), (2b), or (2c) would prevent group sync from silently failing when the `groups` claim is large. ### Alternatives Considered - Reducing group memberships / claim size: Not practical in enterprise AD environments. - Mapping groups to a smaller claim: Possible, but still risks hitting size limits for some users. - Switching IdP (e.g., Keycloak/Okta): Not feasible for organizations standardized on AD FS. - Relying only on access tokens: Doesn’t address cookie size if the access token itself is large and stored the same way. ### Additional Context - Scenario: AD FS emits groups via allatclaims; Open WebUI parses groups on login to assign roles/teams. Works for users with few groups. Fails to update groups for users with many groups due to cookie size. - Request is twofold: 1. Add OAUTH_RESPONSE_MODE so AD FS setups can use form_post per Microsoft guidance. 2. Add a mechanism to handle large groups claims without exceeding cookie limits (server-side session, UserInfo fetch, or similar). - Repro (simplified): 1. Configure AD FS client with claim rules to emit groups; grant allatclaims. 2. Enable Open WebUI SSO with group management (groups claim). 3. Log in as a user who belongs to a large number of groups. 4. Observe: login succeeds, but the user’s groups in Open WebUI are not updated.

GiteaMirror closed this issue

2025-11-11 16:50:39 -06:00

GiteaMirror commented

2025-11-11 16:50:40 -06:00