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 #15551] issue: OAuth Role Management Ignored: OAUTH_ALLOWED_ROLES and OAUTH_ADMIN_ROLES Not Applied on OIDC Login #88339

New Issue
Closed
opened 2026-05-15 12:53:48 -05:00 by GiteaMirror · 4 comments
GiteaMirror commented 2026-05-15 12:53:48 -05:00
Owner
Copy Link

Originally created by @Hani-K on GitHub (Jul 6, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/15551

Originally assigned to: @jackthgu on GitHub.

Check Existing Issues

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

Installation Method

Docker

Open WebUI Version

v0.6.15

Ollama Version (if applicable)

No response

Operating System

Ubuntu 24.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

  1. When ENABLE_OAUTH_ROLE_MANAGEMENT=true, incoming tokens with roles matching OAUTH_ALLOWED_ROLES should be created as active users.
  2. Tokens with roles matching OAUTH_ADMIN_ROLES should be created as active admins.
  3. Users whose roles claim does not match OAUTH_ALLOWED_ROLES should be denied login.

Actual Behavior

  • Any valid OAuth user is created with the default role (pending, user or admin), regardless of their roles claim.
  • When an already registered user logs in with role admin, the user's role gets reset to the Default User Role.
  • Manually promoting the user to an Admin in the UI is undone on the next login.

Steps to Reproduce

  1. Start with installing a fresh Ubuntu 24.04.2 LTS on a VM, with Kernel 6.8.0-63-generic.
  2. Install docker version 28.3.1
  3. Using docker compose, set up Open WebUI using the following configuration:
services:
  webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    environment:
      - OLLAMA_BASE_URL=http://ollama_rocm:11434
      - ENABLE_LOGIN_FORM=true
      - WEBUI_URL=https://DOMAIN.TLD
      - OAUTH_PROVIDER_NAME=Authentik
      - ENABLE_OAUTH_SIGNUP=true
      - ENABLE_OAUTH_ROLE_MANAGEMENT=true
      - OAUTH_ROLES_CLAIM=roles
      - OAUTH_ADMIN_ROLES=admin
      - OAUTH_ALLOWED_ROLES=user,admin
      - OAUTH_CLIENT_ID=${OAUTH_CLIENT_ID}
      - OAUTH_CLIENT_SECRET=${OAUTH_CLIENT_SECRET}
      - OPENID_PROVIDER_URL=${OPENID_PROVIDER_URL}
      - OPENID_REDIRECT_URI=https://DOMAIN.TLD/oauth/oidc/callback
      - OAUTH_SCOPES=openid email profile
      - OAUTH_MERGE_ACCOUNTS_BY_EMAIL=true
    ports:
      - "3000:8080"
    volumes:
      - ./data:/app/backend/data
    restart: unless-stopped
    networks:
      - ollama-net

networks:
  ollama-net:
    external: true
  1. After Open WebUI is installed, create the primary admin account and a password and log in.
  2. In Open WebUI Admin Panel > General > Authentication. Keep the Default User Role as pending or user.
  3. Configure an OIDC provider for Open WebUI in Authentik.
  4. Insure that the provider's ID token actually contains:
"roles": ["admin"]
  1. Restart Open WebUI using
docker compose down && docker compose up -d
  1. Login using a OIDC using a token that has roles=["admin"] or roles=["user"]

Logs & Screenshots

Docker container logs at the time of login:

open-webui  | 2025-07-05 18:07:04.604 | INFO     | uvicorn.protocols.http.httptools_impl:send:476 - 176.6.131.144:0 - "GET /_app/version.json HTTP/1.1" 200 - {}
open-webui  | 2025-07-05 18:07:10.333 | INFO     | uvicorn.protocols.http.httptools_impl:send:476 - 176.6.131.144:0 - "GET /api/config HTTP/1.1" 200 - {}
open-webui  | 2025-07-05 18:07:11.718 | INFO     | uvicorn.protocols.http.httptools_impl:send:476 - 176.6.131.144:0 - "GET /oauth/oidc/login HTTP/1.1" 302 - {}
open-webui  | 2025-07-05 18:07:13.624 | INFO     | httpx._client:_send_single_request:1740 - HTTP Request: POST https://auth.cosycove.net/application/o/token/ "HTTP/1.1 200 OK" - {}
open-webui  | 2025-07-05 18:07:13.627 | INFO     | uvicorn.protocols.http.httptools_impl:send:476 - 176.6.131.144:0 - "GET /oauth/oidc/callback?code=... HTTP/1.1" 307 - {}
open-webui  | 2025-07-05 18:07:13.802 | INFO     | uvicorn.protocols.http.httptools_impl:send:476 - 176.6.131.144:0 - "GET /api/config HTTP/1.1" 200 - {}
open-webui  | 2025-07-05 18:07:13.887 | INFO     | uvicorn.protocols.http.httptools_impl:send:476 - 176.6.131.144:0 - "GET /api/v1/auths/ HTTP/1.1" 200 - {}
open-webui  | 2025-07-05 18:07:13.991 | INFO     | uvicorn.protocols.http.httptools_impl:send:476 - 176.6.131.144:0 - "GET /api/config HTTP/1.1" 200 - {}
open-webui  | 2025-07-05 18:07:14.226 | INFO     | uvicorn.protocols.http.httptools_impl:send:476 - 176.6.131.144:0 - "GET /api/v1/chats/archived?page=1&order_by=updated_at&direction=desc HTTP/1.1" 200 - {}
open-webui  | 2025-07-05 18:07:14.265 | INFO     | uvicorn.protocols.http.httptools_impl:send:476 - 176.6.131.144:0 - "GET /api/changelog HTTP/1.1" 200 - {}
open-webui  | 2025-07-05 18:07:14.268 | INFO     | uvicorn.protocols.http.httptools_impl:send:476 - 176.6.131.144:0 - "GET /api/v1/users/user/settings HTTP/1.1" 200 - {}
open-webui  | 2025-07-05 18:07:14.282 | INFO     | uvicorn.protocols.http.httptools_impl:send:476 - 176.6.131.144:0 - "GET /api/v1/channels/ HTTP/1.1" 200 - {}

No warnings or errors about role matching appear in the logs.

My docker-compose.yml:

services:
  webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    environment:
      - OLLAMA_BASE_URL=http://ollama_rocm:11434
      - ENABLE_LOGIN_FORM=true
      - WEBUI_URL=https://DOMAIN.TLD
      - OAUTH_PROVIDER_NAME=Authentik
      - ENABLE_OAUTH_SIGNUP=true
      - ENABLE_OAUTH_ROLE_MANAGEMENT=true
      - OAUTH_ROLES_CLAIM=roles
      - OAUTH_ADMIN_ROLES=admin
      - OAUTH_ALLOWED_ROLES=user,admin
      - OAUTH_CLIENT_ID=${OAUTH_CLIENT_ID}
      - OAUTH_CLIENT_SECRET=${OAUTH_CLIENT_SECRET}
      - OPENID_PROVIDER_URL=${OPENID_PROVIDER_URL}
      - OPENID_REDIRECT_URI=https://DOMAIN.TLD/oauth/oidc/callback
      - OAUTH_SCOPES=openid email profile
      - OAUTH_MERGE_ACCOUNTS_BY_EMAIL=true
    ports:
      - "3000:8080"
    volumes:
      - ./data:/app/backend/data
    restart: unless-stopped
    networks:
      - ollama-net

networks:
  ollama-net:
    external: true

A preview of the JWT payload sent by authentik:

{
    "iss": "https://authentik.tld/application/o/open-web-ui/",
    "sub": "XXX",
    "aud": "XXX",
    "exp": 1751841671,
    "iat": 1751839871,
    "auth_time": 1751839871,
    "acr": "goauthentik.io/providers/oauth2/default",
    "email": "XXX@gmail.com",
    "email_verified": true,
    "name": "YYY",
    "given_name": "YYY",
    "preferred_username": "ZZZ",
    "nickname": "ZZZ",
    "groups": [
        "group a",
        "group b"
    ],
    "roles": [
        "admin"
    ]
}

Additional Information

  • A parallel issue (#13676) reports that OAUTH_ALLOWED_ROLES is never checked when logging in, even in Keycloak setups.
  • Setting ENABLE_PERSISTENT_CONFIG=false and wiping webui.db does not cause the new role-management defaults to take effect.
Originally created by @Hani-K on GitHub (Jul 6, 2025). Original GitHub issue: https://github.com/open-webui/open-webui/issues/15551 Originally assigned to: @jackthgu on GitHub. ### Check Existing Issues - [x] I have searched the existing issues and discussions. - [x] I am using the latest version of Open WebUI. ### Installation Method Docker ### Open WebUI Version v0.6.15 ### Ollama Version (if applicable) _No response_ ### Operating System Ubuntu 24.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. - [ ] 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 1. When ENABLE_OAUTH_ROLE_MANAGEMENT=true, incoming tokens with roles matching OAUTH_ALLOWED_ROLES should be created as active users. 2. Tokens with roles matching OAUTH_ADMIN_ROLES should be created as active admins. 3. Users whose roles claim does not match OAUTH_ALLOWED_ROLES should be denied login. ### Actual Behavior - Any valid OAuth user is created with the default role (pending, user or admin), regardless of their roles claim. - When an already registered user logs in with role admin, the user's role gets reset to the Default User Role. - Manually promoting the user to an Admin in the UI is undone on the next login. ### Steps to Reproduce 1. Start with installing a fresh Ubuntu 24.04.2 LTS on a VM, with Kernel 6.8.0-63-generic. 2. Install docker version 28.3.1 3. Using docker compose, set up Open WebUI using the following configuration: ``` services: webui: image: ghcr.io/open-webui/open-webui:main container_name: open-webui environment: - OLLAMA_BASE_URL=http://ollama_rocm:11434 - ENABLE_LOGIN_FORM=true - WEBUI_URL=https://DOMAIN.TLD - OAUTH_PROVIDER_NAME=Authentik - ENABLE_OAUTH_SIGNUP=true - ENABLE_OAUTH_ROLE_MANAGEMENT=true - OAUTH_ROLES_CLAIM=roles - OAUTH_ADMIN_ROLES=admin - OAUTH_ALLOWED_ROLES=user,admin - OAUTH_CLIENT_ID=${OAUTH_CLIENT_ID} - OAUTH_CLIENT_SECRET=${OAUTH_CLIENT_SECRET} - OPENID_PROVIDER_URL=${OPENID_PROVIDER_URL} - OPENID_REDIRECT_URI=https://DOMAIN.TLD/oauth/oidc/callback - OAUTH_SCOPES=openid email profile - OAUTH_MERGE_ACCOUNTS_BY_EMAIL=true ports: - "3000:8080" volumes: - ./data:/app/backend/data restart: unless-stopped networks: - ollama-net networks: ollama-net: external: true ``` 4. After Open WebUI is installed, create the primary admin account and a password and log in. 5. In Open WebUI Admin Panel > General > Authentication. Keep the Default User Role as pending or user. 6. Configure an OIDC provider for Open WebUI in Authentik. 7. Insure that the provider's ID token actually contains: ``` "roles": ["admin"] ``` 8. Restart Open WebUI using ``` docker compose down && docker compose up -d ``` 9. Login using a OIDC using a token that has roles=["admin"] or roles=["user"] ### Logs & Screenshots Docker container logs at the time of login: ``` open-webui | 2025-07-05 18:07:04.604 | INFO | uvicorn.protocols.http.httptools_impl:send:476 - 176.6.131.144:0 - "GET /_app/version.json HTTP/1.1" 200 - {} open-webui | 2025-07-05 18:07:10.333 | INFO | uvicorn.protocols.http.httptools_impl:send:476 - 176.6.131.144:0 - "GET /api/config HTTP/1.1" 200 - {} open-webui | 2025-07-05 18:07:11.718 | INFO | uvicorn.protocols.http.httptools_impl:send:476 - 176.6.131.144:0 - "GET /oauth/oidc/login HTTP/1.1" 302 - {} open-webui | 2025-07-05 18:07:13.624 | INFO | httpx._client:_send_single_request:1740 - HTTP Request: POST https://auth.cosycove.net/application/o/token/ "HTTP/1.1 200 OK" - {} open-webui | 2025-07-05 18:07:13.627 | INFO | uvicorn.protocols.http.httptools_impl:send:476 - 176.6.131.144:0 - "GET /oauth/oidc/callback?code=... HTTP/1.1" 307 - {} open-webui | 2025-07-05 18:07:13.802 | INFO | uvicorn.protocols.http.httptools_impl:send:476 - 176.6.131.144:0 - "GET /api/config HTTP/1.1" 200 - {} open-webui | 2025-07-05 18:07:13.887 | INFO | uvicorn.protocols.http.httptools_impl:send:476 - 176.6.131.144:0 - "GET /api/v1/auths/ HTTP/1.1" 200 - {} open-webui | 2025-07-05 18:07:13.991 | INFO | uvicorn.protocols.http.httptools_impl:send:476 - 176.6.131.144:0 - "GET /api/config HTTP/1.1" 200 - {} open-webui | 2025-07-05 18:07:14.226 | INFO | uvicorn.protocols.http.httptools_impl:send:476 - 176.6.131.144:0 - "GET /api/v1/chats/archived?page=1&order_by=updated_at&direction=desc HTTP/1.1" 200 - {} open-webui | 2025-07-05 18:07:14.265 | INFO | uvicorn.protocols.http.httptools_impl:send:476 - 176.6.131.144:0 - "GET /api/changelog HTTP/1.1" 200 - {} open-webui | 2025-07-05 18:07:14.268 | INFO | uvicorn.protocols.http.httptools_impl:send:476 - 176.6.131.144:0 - "GET /api/v1/users/user/settings HTTP/1.1" 200 - {} open-webui | 2025-07-05 18:07:14.282 | INFO | uvicorn.protocols.http.httptools_impl:send:476 - 176.6.131.144:0 - "GET /api/v1/channels/ HTTP/1.1" 200 - {} ``` No warnings or errors about role matching appear in the logs. My docker-compose.yml: ``` services: webui: image: ghcr.io/open-webui/open-webui:main container_name: open-webui environment: - OLLAMA_BASE_URL=http://ollama_rocm:11434 - ENABLE_LOGIN_FORM=true - WEBUI_URL=https://DOMAIN.TLD - OAUTH_PROVIDER_NAME=Authentik - ENABLE_OAUTH_SIGNUP=true - ENABLE_OAUTH_ROLE_MANAGEMENT=true - OAUTH_ROLES_CLAIM=roles - OAUTH_ADMIN_ROLES=admin - OAUTH_ALLOWED_ROLES=user,admin - OAUTH_CLIENT_ID=${OAUTH_CLIENT_ID} - OAUTH_CLIENT_SECRET=${OAUTH_CLIENT_SECRET} - OPENID_PROVIDER_URL=${OPENID_PROVIDER_URL} - OPENID_REDIRECT_URI=https://DOMAIN.TLD/oauth/oidc/callback - OAUTH_SCOPES=openid email profile - OAUTH_MERGE_ACCOUNTS_BY_EMAIL=true ports: - "3000:8080" volumes: - ./data:/app/backend/data restart: unless-stopped networks: - ollama-net networks: ollama-net: external: true ``` A preview of the JWT payload sent by authentik: ``` { "iss": "https://authentik.tld/application/o/open-web-ui/", "sub": "XXX", "aud": "XXX", "exp": 1751841671, "iat": 1751839871, "auth_time": 1751839871, "acr": "goauthentik.io/providers/oauth2/default", "email": "XXX@gmail.com", "email_verified": true, "name": "YYY", "given_name": "YYY", "preferred_username": "ZZZ", "nickname": "ZZZ", "groups": [ "group a", "group b" ], "roles": [ "admin" ] } ``` ### Additional Information - A parallel issue (#13676) reports that OAUTH_ALLOWED_ROLES is never checked when logging in, even in Keycloak setups. - Setting ENABLE_PERSISTENT_CONFIG=false and wiping webui.db does not cause the new role-management defaults to take effect.
GiteaMirror added the bug label 2026-05-15 12:53:48 -05:00
GiteaMirror commented 2026-05-15 12:53:51 -05:00
Author
Owner
Copy Link

@guenhter commented on GitHub (Jul 10, 2025):

Could you turn on debug log because then we should see these lines:


            log.debug(f"Oauth Roles claim: {oauth_claim}")
            log.debug(f"User roles from oauth: {oauth_roles}")
            log.debug(f"Accepted user roles: {oauth_allowed_roles}")
            log.debug(f"Accepted admin roles: {oauth_admin_roles}")
<!-- gh-comment-id:3057359338 --> @guenhter commented on GitHub (Jul 10, 2025): Could you turn on debug log because then we should see these lines: ``` log.debug(f"Oauth Roles claim: {oauth_claim}") log.debug(f"User roles from oauth: {oauth_roles}") log.debug(f"Accepted user roles: {oauth_allowed_roles}") log.debug(f"Accepted admin roles: {oauth_admin_roles}") ```
GiteaMirror commented 2026-05-15 12:53:51 -05:00
Author
Owner
Copy Link

@2o1o0 commented on GitHub (Jul 12, 2025):

Hey,

I have a similar issue, I end up in a login cycle when using SSO, here are the logs with debug enable:

open-webui 2025-07-12 18:39:52.843 | DEBUG    | open_webui.utils.oauth:get_user_role:101 - Running OAUTH Role management - {}
open-webui 2025-07-12 18:39:52.843 | DEBUG    | open_webui.utils.oauth:get_user_role:117 - Oauth Roles claim: realm_access.roles - {}
open-webui 2025-07-12 18:39:52.843 | DEBUG    | open_webui.utils.oauth:get_user_role:118 - User roles from oauth: ['offline_access', 'admin', 'uma_authorization', 'default-roles-home', 'user'] - {}                                          
open-webui 2025-07-12 18:39:52.844 | DEBUG    | open_webui.utils.oauth:get_user_role:119 - Accepted user roles: ['user', 'admin'] - {}
open-webui 2025-07-12 18:39:52.844 | DEBUG    | open_webui.utils.oauth:get_user_role:120 - Accepted admin roles: ['admin'] - {}                           
open-webui 2025-07-12 18:39:52.844 | DEBUG    | open_webui.utils.oauth:get_user_role:128 - Assigned user the user role - {}                    
open-webui 2025-07-12 18:39:52.844 | DEBUG    | open_webui.utils.oauth:get_user_role:134 - Assigned user the admin role - {}

I'm deploying it with the helm chart, my login related values :

          - name: ENABLE_SIGNUP 
            value: "false"
          - name: ENABLE_LOGIN_FORM 
            value: "false"
          - name: ENABLE_OAUTH_ROLE_MANAGEMENT 
            value: "true"
          - name: ENABLE_OAUTH_SIGNUP
            value: "true"
          - name: OAUTH_CLIENT_ID 
            value: ollama
          - name: OAUTH_CLIENT_SECRET
            valueFrom:
              secretKeyRef:
                name: openwebui-secrets
                key: OAUTH_CLIENT_SECRET
          - name: OPENID_PROVIDER_URL  
            value: https://my.domain/realms/home/.well-known/openid-configuration 
          - name: OAUTH_PROVIDER_NAME 
            value: Keycloak 
          - name: OAUTH_ROLES_CLAIM
            value: "realm_access.roles"

Rolling back to chart 6.19.0 (open-webui:0.6.13) fix the issue.

Thanks!

<!-- gh-comment-id:3065958647 --> @2o1o0 commented on GitHub (Jul 12, 2025): Hey, I have a similar issue, I end up in a login cycle when using SSO, here are the logs with debug enable: ``` open-webui 2025-07-12 18:39:52.843 | DEBUG | open_webui.utils.oauth:get_user_role:101 - Running OAUTH Role management - {} open-webui 2025-07-12 18:39:52.843 | DEBUG | open_webui.utils.oauth:get_user_role:117 - Oauth Roles claim: realm_access.roles - {} open-webui 2025-07-12 18:39:52.843 | DEBUG | open_webui.utils.oauth:get_user_role:118 - User roles from oauth: ['offline_access', 'admin', 'uma_authorization', 'default-roles-home', 'user'] - {} open-webui 2025-07-12 18:39:52.844 | DEBUG | open_webui.utils.oauth:get_user_role:119 - Accepted user roles: ['user', 'admin'] - {} open-webui 2025-07-12 18:39:52.844 | DEBUG | open_webui.utils.oauth:get_user_role:120 - Accepted admin roles: ['admin'] - {} open-webui 2025-07-12 18:39:52.844 | DEBUG | open_webui.utils.oauth:get_user_role:128 - Assigned user the user role - {} open-webui 2025-07-12 18:39:52.844 | DEBUG | open_webui.utils.oauth:get_user_role:134 - Assigned user the admin role - {} ``` I'm deploying it with the helm chart, my login related values : ```yaml - name: ENABLE_SIGNUP value: "false" - name: ENABLE_LOGIN_FORM value: "false" - name: ENABLE_OAUTH_ROLE_MANAGEMENT value: "true" - name: ENABLE_OAUTH_SIGNUP value: "true" - name: OAUTH_CLIENT_ID value: ollama - name: OAUTH_CLIENT_SECRET valueFrom: secretKeyRef: name: openwebui-secrets key: OAUTH_CLIENT_SECRET - name: OPENID_PROVIDER_URL value: https://my.domain/realms/home/.well-known/openid-configuration - name: OAUTH_PROVIDER_NAME value: Keycloak - name: OAUTH_ROLES_CLAIM value: "realm_access.roles" ``` Rolling back to chart `6.19.0` (`open-webui:0.6.13`) fix the issue. Thanks!
GiteaMirror commented 2026-05-15 12:53:52 -05:00
Author
Owner
Copy Link

@jackthgu commented on GitHub (Jul 22, 2025):

Hello, @Hani-K

This issue is related to assigning admin privileges in Authentik. There are several ways to grant superuser rights to a user, but I first tested it by assigning the user to a specific group.

In this case, the OAUTH_ROLES_CLAIM must be set to groups.

With the latest version of Authentik, unless explicitly configured, the incoming payload typically does not include a roles field. So if you're using groups to assign permissions, make sure to update that environment variable accordingly.

Here is my env for test

AUTHENTIK_SECRET_KEY=xxx
AUTHENTIK_ERROR_REPORTING__ENABLED=true

ENABLE_OAUTH_SIGNUP=true
OAUTH_CLIENT_ID=xxx
OAUTH_CLIENT_SECRET=xxx
OPENID_PROVIDER_URL=http://localhost:9000/application/o/openwebui/.well-known/openid-configuration
OPENID_REDIRECT_URI=http://localhost:8080/oauth/oidc/callback
OAUTH_SCOPES="openid email profile"
OAUTH_PROVIDER_NAME="Authentik"

OAUTH_MERGE_ACCOUNTS_BY_EMAIL=true
ENABLE_OAUTH_GROUP_MANAGEMENT="true"
ENABLE_OAUTH_GROUP_CREATION="true"
OAUTH_ROLES_CLAIM="groups"
OAUTH_ADMIN_ROLES="admin"
OAUTH_ALLOWED_ROLES="user,admin"
ENABLE_OAUTH_ROLE_MANAGEMENT="true"

Let me know if you’d prefer to use a different method.

Jack.

<!-- gh-comment-id:3100708728 --> @jackthgu commented on GitHub (Jul 22, 2025): Hello, @Hani-K This issue is related to assigning admin privileges in Authentik. There are several ways to grant superuser rights to a user, but I first tested it by assigning the user to a specific group. In this case, the `OAUTH_ROLES_CLAIM` must be set to `groups`. With the latest version of Authentik, unless explicitly configured, the incoming payload typically does not include a `roles` field. So if you're using groups to assign permissions, make sure to update that environment variable accordingly. Here is my env for test AUTHENTIK_SECRET_KEY=xxx AUTHENTIK_ERROR_REPORTING__ENABLED=true ENABLE_OAUTH_SIGNUP=true OAUTH_CLIENT_ID=xxx OAUTH_CLIENT_SECRET=xxx OPENID_PROVIDER_URL=http://localhost:9000/application/o/openwebui/.well-known/openid-configuration OPENID_REDIRECT_URI=http://localhost:8080/oauth/oidc/callback OAUTH_SCOPES="openid email profile" OAUTH_PROVIDER_NAME="Authentik" OAUTH_MERGE_ACCOUNTS_BY_EMAIL=true ENABLE_OAUTH_GROUP_MANAGEMENT="true" ENABLE_OAUTH_GROUP_CREATION="true" OAUTH_ROLES_CLAIM="groups" OAUTH_ADMIN_ROLES="admin" OAUTH_ALLOWED_ROLES="user,admin" ENABLE_OAUTH_ROLE_MANAGEMENT="true" Let me know if you’d prefer to use a different method. Jack.
GiteaMirror commented 2026-05-15 12:53:52 -05:00
Author
Owner
Copy Link

@Hani-K commented on GitHub (Jul 25, 2025):

Hey @jackthgu Thanks for the hint, setting roles by using groups definitely works well.

I realized that Authentik doesn't pass OAuth custom parameters which get omitted from the actual JWT token. I opened an issue with authentik and realized that source property mappings only start after establishing the initial connection, so I resulted to using a middleware called dex.

The middleware works too but I wasn't a fan of the increased complexty of the stack.

For others facing this issue, you can either try with a middleware, Open WebUI -> Dex-> Authentik -> Auth.
Or use groups like @jackthgu mentioned.

I simply created 2 groups: OpenWebUI (Admins) and OpenWebUI
and add them to my env:

  • OAUTH_ROLES_CLAIM=groups
  • OAUTH_ADMIN_ROLES=OpenWebUI (Admins)
  • OAUTH_ALLOWED_ROLES=OpenWebUI,admin
  • DEFAULT_USER_ROLE=pending
<!-- gh-comment-id:3117429090 --> @Hani-K commented on GitHub (Jul 25, 2025): Hey @jackthgu Thanks for the hint, setting roles by using groups definitely works well. I realized that Authentik doesn't pass OAuth custom parameters which get omitted from the actual JWT token. I opened an issue with authentik and realized that source property mappings only start after establishing the initial connection, so I resulted to using a middleware called dex. The middleware works too but I wasn't a fan of the increased complexty of the stack. For others facing this issue, you can either try with a middleware, Open WebUI -> Dex-> Authentik -> Auth. Or use groups like @jackthgu mentioned. I simply created 2 groups: OpenWebUI (Admins) and OpenWebUI and add them to my env: - OAUTH_ROLES_CLAIM=groups - OAUTH_ADMIN_ROLES=OpenWebUI (Admins) - OAUTH_ALLOWED_ROLES=OpenWebUI,admin - DEFAULT_USER_ROLE=pending
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#88339
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?