[GH-ISSUE #7583] Bug: Signout doesn't terminate SSO sessions #53470

Closed
opened 2026-05-05 14:47:43 -05:00 by GiteaMirror · 22 comments
Owner

Originally created by @sreinwald on GitHub (Dec 3, 2024).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/7583

Bug Report

Installation Method

Docker compose

Environment

  • Open WebUI Version: v0.4.7
  • Ollama (if applicable): v0.4.7
  • Operating System: Ubuntu 24.04.1 LTS
  • Browser (if applicable): Tested in Firefox v133.0 and Google Chrome 131.0.6778.86

Confirmation:

  • I have read and followed all the instructions provided in the README.md.
  • I am on the latest version of both Open WebUI and Ollama.
  • Not applicable: I have included the browser console logs.
  • Not applicable: I have included the Docker container logs.
  • I have provided the exact steps to reproduce the bug in the "Steps to Reproduce" section below.

Expected Behavior

When a user clicks on the logout button, it should fully terminate their session both within Open WebUI and with the SSO provider, in our case Keycloak.
The user should have to re-authenticate before being able to access the webui after logging out.

Actual Behavior

Clicking the logout button only deletes the cookie for Open Webui, but does not end the session in Keycloak.

As a result, users can still access the webui (and any other SSO-enabled service) without having to re-authenticate by simply clicking the button to sign in with the IDP again.

Description

Bug Summary:
Logout functionality is incomplete because when using SSO, logging out does not properly terminate the user's SSO session.

Reproduction Details

Steps to Reproduce:

  1. Log into Open WebUI using a Keycloak identity.
  2. Click on the logout button within the application.
  3. While the webui cookie is deleted, but the Keycloak session remains active.
  4. Clicking the button to log in with OIDC immediately redirects the user to the authenticated state of the webui without having to re-authenticate

Logs and Screenshots

Screenshots/Screen Recordings (if applicable):

Additional Information

In my opinion, this is potentially a security issue because when a user logs out of an application, they expect all SSO sessions to terminate. The session not being terminated properly means anyone with physical access to the user's device could use the still existing session to access all other SSO-enabled services without having to re-authenticate.

I've taken a brief look at the code, and it seems like the logout function does not attempt to call an end session endpoint at all, which is why I suspect this is not related to Keycloak specifically but likely affects every OAuth2/OIDC deployment.

c4ea31357f/backend/open_webui/apps/webui/routers/auths.py (L500-L503)

Originally created by @sreinwald on GitHub (Dec 3, 2024). Original GitHub issue: https://github.com/open-webui/open-webui/issues/7583 # Bug Report ## Installation Method Docker compose ## Environment - **Open WebUI Version:** v0.4.7 - **Ollama (if applicable):** v0.4.7 - **Operating System:** Ubuntu 24.04.1 LTS - **Browser (if applicable):** Tested in Firefox v133.0 and Google Chrome 131.0.6778.86 **Confirmation:** - [x] I have read and followed all the instructions provided in the README.md. - [x] I am on the latest version of both Open WebUI and Ollama. - Not applicable: I have included the browser console logs. - Not applicable: I have included the Docker container logs. - [x] I have provided the exact steps to reproduce the bug in the "Steps to Reproduce" section below. ## Expected Behavior When a user clicks on the logout button, it should fully terminate their session both within Open WebUI and with the SSO provider, in our case Keycloak. The user should have to re-authenticate before being able to access the webui after logging out. ## Actual Behavior Clicking the logout button only deletes the cookie for Open Webui, but does not end the session in Keycloak. As a result, users can still access the webui (and any other SSO-enabled service) without having to re-authenticate by simply clicking the button to sign in with the IDP again. ## Description **Bug Summary:** Logout functionality is incomplete because when using SSO, logging out does not properly terminate the user's SSO session. ## Reproduction Details **Steps to Reproduce:** 1. Log into Open WebUI using a Keycloak identity. 2. Click on the logout button within the application. 3. While the webui cookie is deleted, but the Keycloak session remains active. 4. Clicking the button to log in with OIDC immediately redirects the user to the authenticated state of the webui without having to re-authenticate ## Logs and Screenshots **Screenshots/Screen Recordings (if applicable):** - https://www.youtube.com/watch?v=4bB6qe2ahDE ## Additional Information In my opinion, this is potentially a security issue because when a user logs out of an application, they expect all SSO sessions to terminate. The session not being terminated properly means anyone with physical access to the user's device could use the still existing session to access all other SSO-enabled services without having to re-authenticate. I've taken a brief look at the code, and it seems like the logout function does not attempt to call an end session endpoint at all, which is why I suspect this is not related to Keycloak specifically but likely affects every OAuth2/OIDC deployment. https://github.com/open-webui/open-webui/blob/c4ea31357f49d08a14c86b2bd85fdcd489512e91/backend/open_webui/apps/webui/routers/auths.py#L500-L503
Author
Owner

@tjbck commented on GitHub (Dec 3, 2024):

PR welcome!

<!-- gh-comment-id:2515484543 --> @tjbck commented on GitHub (Dec 3, 2024): PR welcome!
Author
Owner

@ZaibanAli commented on GitHub (Dec 6, 2024):

Bump, facing the same issue. I will work on it over the weekend and open a pull request.

<!-- gh-comment-id:2522005035 --> @ZaibanAli commented on GitHub (Dec 6, 2024): Bump, facing the same issue. I will work on it over the weekend and open a pull request.
Author
Owner

@ZaibanAli commented on GitHub (Dec 7, 2024):

@tjbck I have opened a pull request 7678, please review. Thanks.

Demonstration Video

<!-- gh-comment-id:2525108324 --> @ZaibanAli commented on GitHub (Dec 7, 2024): @tjbck I have opened a [pull request 7678,](https://github.com/open-webui/open-webui/pull/7678) please review. Thanks. [Demonstration Video](https://drive.qaiv.com/s/8tkkEHQXYZ7i6Jm)
Author
Owner

@tjbck commented on GitHub (Dec 10, 2024):

@ZaibanAli's PR has been merged, should be fixed in dev. Testing wanted here!

<!-- gh-comment-id:2530687220 --> @tjbck commented on GitHub (Dec 10, 2024): @ZaibanAli's PR has been merged, should be fixed in dev. Testing wanted here!
Author
Owner

@ZaibanAli commented on GitHub (Dec 10, 2024):

@tjbck will do it today. Thanks for merging the PR.

<!-- gh-comment-id:2530852400 --> @ZaibanAli commented on GitHub (Dec 10, 2024): @tjbck will do it today. Thanks for merging the PR.
Author
Owner

@ZaibanAli commented on GitHub (Dec 10, 2024):

@ZaibanAli's PR has been merged, should be fixed in dev. Testing wanted here!

@tjbck I have tested the functionality. It works!

we can close this issue.

<!-- gh-comment-id:2531103909 --> @ZaibanAli commented on GitHub (Dec 10, 2024): > @ZaibanAli's PR has been merged, should be fixed in dev. Testing wanted here! @tjbck I have tested the functionality. It works! we can close this issue.
Author
Owner

@sreinwald commented on GitHub (Dec 10, 2024):

@ZaibanAli's PR has been merged, should be fixed in dev. Testing wanted here!

Just tested the dev branch in our test environment and it worked as expected. Could observe sessions being properly terminated in Keycloak.

Personally, I'd be happy to consider this issue closed, but further testing with other SSO providers would probably be a good idea.

Thanks again, @ZaibanAli

<!-- gh-comment-id:2531534019 --> @sreinwald commented on GitHub (Dec 10, 2024): > @ZaibanAli's PR has been merged, should be fixed in dev. Testing wanted here! Just tested the dev branch in our test environment and it worked as expected. Could observe sessions being properly terminated in Keycloak. Personally, I'd be happy to consider this issue closed, but further testing with other SSO providers would probably be a good idea. Thanks again, @ZaibanAli
Author
Owner

@nagug commented on GitHub (Dec 11, 2024):

Before raising another ticket, I have the similar issue with Authentik integration as well for logout. Is this fix specific to Keycloak?

<!-- gh-comment-id:2536080677 --> @nagug commented on GitHub (Dec 11, 2024): Before raising another ticket, I have the similar issue with Authentik integration as well for logout. Is this fix specific to Keycloak?
Author
Owner

@ZaibanAli commented on GitHub (Dec 11, 2024):

@nagug I expect it to work with Authentik as well, can you please test?

<!-- gh-comment-id:2536256564 --> @ZaibanAli commented on GitHub (Dec 11, 2024): @nagug I expect it to work with Authentik as well, can you please test?
Author
Owner

@nagug commented on GitHub (Dec 11, 2024):

@ZaibanAli let me set up the env and come back. I have been using docker images so far.

<!-- gh-comment-id:2536434567 --> @nagug commented on GitHub (Dec 11, 2024): @ZaibanAli let me set up the env and come back. I have been using docker images so far.
Author
Owner

@sreinwald commented on GitHub (Dec 11, 2024):

@nagug You can just replace the docker release tag.
Duplicate your docker compose, change volumes to be safe and change the release tag from main to dev

So change

services:
  openwebui:
    image: ghcr.io/open-webui/open-webui:main

to

services:
  openwebui:
    image: ghcr.io/open-webui/open-webui:dev
<!-- gh-comment-id:2536516527 --> @sreinwald commented on GitHub (Dec 11, 2024): @nagug You can just replace the docker release tag. Duplicate your docker compose, change volumes to be safe and change the release tag from `main` to `dev` So change ``` services: openwebui: image: ghcr.io/open-webui/open-webui:main ``` to ``` services: openwebui: image: ghcr.io/open-webui/open-webui:dev ```
Author
Owner

@nagug commented on GitHub (Dec 11, 2024):

Thanks, thats exactly what i tried and looks like its not fixed yet for Aunthetik. the behaviour is same as the orginal keycloak. Is there anything more i can provide to help. what additional context would you prefer?

<!-- gh-comment-id:2536552232 --> @nagug commented on GitHub (Dec 11, 2024): Thanks, thats exactly what i tried and looks like its not fixed yet for Aunthetik. the behaviour is same as the orginal keycloak. Is there anything more i can provide to help. what additional context would you prefer?
Author
Owner

@sreinwald commented on GitHub (Dec 11, 2024):

@nagug I could be wrong, but I believe you have to do a docker compose pull - it might still be using the main image.

<!-- gh-comment-id:2536611600 --> @sreinwald commented on GitHub (Dec 11, 2024): @nagug I could be wrong, but I believe you have to do a `docker compose pull` - it might still be using the main image.
Author
Owner

@nagug commented on GitHub (Dec 11, 2024):

I did a system prune and cleanedup everything. Then created a new docker compose file and did a compose up with all env variables. Let me try again

<!-- gh-comment-id:2536618982 --> @nagug commented on GitHub (Dec 11, 2024): I did a system prune and cleanedup everything. Then created a new docker compose file and did a compose up with all env variables. Let me try again
Author
Owner

@nagug commented on GitHub (Dec 11, 2024):

Nope. checked again. pretty much clean sheet. the issue exists. double checked my image pulled. here is the docker compose file. Please let me know if i am doing something wrong,

name: openwebui-dev
services:
    open-webui:
        ports:
            - 3000:8080
        volumes:
            - open-webui:/app/backend/data
        container_name: open-webui
        extra_hosts:
            - host.docker.internal:host-gateway
        restart: always
        image: ghcr.io/open-webui/open-webui:dev
        environment:
          - ENABLE_OAUTH_SIGNUP=TRUE
          - OAUTH_MERGE_ACCOUNTS_BY_EMAIL=TRUE
          - OAUTH_PROVIDER_NAME=Authentik
          - OPENID_PROVIDER_URL=https://xxxxxxxxx/application/o/test/.well-known/openid-configuration
          - OAUTH_CLIENT_ID=xxxxxxx
          - OAUTH_CLIENT_SECRET=xxxxxxx
          - OAUTH_SCOPES=openid email profile

volumes:
    open-webui:
        name: open-webui

<!-- gh-comment-id:2536831306 --> @nagug commented on GitHub (Dec 11, 2024): Nope. checked again. pretty much clean sheet. the issue exists. double checked my image pulled. here is the docker compose file. Please let me know if i am doing something wrong, ``` name: openwebui-dev services: open-webui: ports: - 3000:8080 volumes: - open-webui:/app/backend/data container_name: open-webui extra_hosts: - host.docker.internal:host-gateway restart: always image: ghcr.io/open-webui/open-webui:dev environment: - ENABLE_OAUTH_SIGNUP=TRUE - OAUTH_MERGE_ACCOUNTS_BY_EMAIL=TRUE - OAUTH_PROVIDER_NAME=Authentik - OPENID_PROVIDER_URL=https://xxxxxxxxx/application/o/test/.well-known/openid-configuration - OAUTH_CLIENT_ID=xxxxxxx - OAUTH_CLIENT_SECRET=xxxxxxx - OAUTH_SCOPES=openid email profile volumes: open-webui: name: open-webui ```
Author
Owner

@nagug commented on GitHub (Dec 11, 2024):

Also the .well-known/openid-configuration from authentik looks like below

{
  "issuer": "https://domain.abc/application/o/test/",
  "authorization_endpoint": "https://domain.abc/application/o/authorize/",
  "token_endpoint": "https://domain.abc/application/o/token/",
  "userinfo_endpoint": "https://domain.abc/application/o/userinfo/",
  "end_session_endpoint": "https://domain.abc/application/o/test/end-session/",
  "introspection_endpoint": "https://domain.abc/application/o/introspect/",
  "revocation_endpoint": "https://domain.abc/application/o/revoke/",
  "device_authorization_endpoint": "https://domain.abc/application/o/device/",
  "response_types_supported": [
    "code",
    "id_token",
    "id_token token",
    "code token",
    "code id_token",
    "code id_token token"
  ],
  "response_modes_supported": [
    "query",
    "fragment",
    "form_post"
  ],
  "jwks_uri": "https://domain.abc/application/o/test/jwks/",
  "grant_types_supported": [
    "authorization_code",
    "refresh_token",
    "implicit",
    "client_credentials",
    "password",
    "urn:ietf:params:oauth:grant-type:device_code"
  ],
  "id_token_signing_alg_values_supported": [
    "RS256"
  ],
  "subject_types_supported": [
    "public"
  ],
  "token_endpoint_auth_methods_supported": [
    "client_secret_post",
    "client_secret_basic"
  ],
  "acr_values_supported": [
    "goauthentik.io/providers/oauth2/default"
  ],
  "scopes_supported": [
    "openid",
    "email",
    "profile"
  ],
  "request_parameter_supported": false,
  "claims_supported": [
    "sub",
    "iss",
    "aud",
    "exp",
    "iat",
    "auth_time",
    "acr",
    "amr",
    "nonce",
    "email",
    "email_verified",
    "name",
    "given_name",
    "preferred_username",
    "nickname",
    "groups"
  ],
  "claims_parameter_supported": false,
  "code_challenge_methods_supported": [
    "plain",
    "S256"
  ]
}
<!-- gh-comment-id:2536853689 --> @nagug commented on GitHub (Dec 11, 2024): Also the .well-known/openid-configuration from authentik looks like below ``` { "issuer": "https://domain.abc/application/o/test/", "authorization_endpoint": "https://domain.abc/application/o/authorize/", "token_endpoint": "https://domain.abc/application/o/token/", "userinfo_endpoint": "https://domain.abc/application/o/userinfo/", "end_session_endpoint": "https://domain.abc/application/o/test/end-session/", "introspection_endpoint": "https://domain.abc/application/o/introspect/", "revocation_endpoint": "https://domain.abc/application/o/revoke/", "device_authorization_endpoint": "https://domain.abc/application/o/device/", "response_types_supported": [ "code", "id_token", "id_token token", "code token", "code id_token", "code id_token token" ], "response_modes_supported": [ "query", "fragment", "form_post" ], "jwks_uri": "https://domain.abc/application/o/test/jwks/", "grant_types_supported": [ "authorization_code", "refresh_token", "implicit", "client_credentials", "password", "urn:ietf:params:oauth:grant-type:device_code" ], "id_token_signing_alg_values_supported": [ "RS256" ], "subject_types_supported": [ "public" ], "token_endpoint_auth_methods_supported": [ "client_secret_post", "client_secret_basic" ], "acr_values_supported": [ "goauthentik.io/providers/oauth2/default" ], "scopes_supported": [ "openid", "email", "profile" ], "request_parameter_supported": false, "claims_supported": [ "sub", "iss", "aud", "exp", "iat", "auth_time", "acr", "amr", "nonce", "email", "email_verified", "name", "given_name", "preferred_username", "nickname", "groups" ], "claims_parameter_supported": false, "code_challenge_methods_supported": [ "plain", "S256" ] } ```
Author
Owner

@nagug commented on GitHub (Dec 11, 2024):

@ZaibanAli - i was trying to see what is the redirect url is. It look like the url looks correct. a 307 redirect. But the browser does not seem to redirect at all.

I tried to see, how the logout is implemented in audiobookshelf (which logs out correctly). Found there is a call made to
/end-session/?post_logout_redirect_uri=

Not sure that is of any help

<!-- gh-comment-id:2536876861 --> @nagug commented on GitHub (Dec 11, 2024): @ZaibanAli - i was trying to see what is the redirect url is. It look like the url looks correct. a 307 redirect. But the browser does not seem to redirect at all. I tried to see, how the logout is implemented in audiobookshelf (which logs out correctly). Found there is a call made to `/end-session/?post_logout_redirect_uri=` Not sure that is of any help
Author
Owner

@ZaibanAli commented on GitHub (Dec 12, 2024):

@nagug thank you for the detail information. I will look into this again on weekend. (will push a patch)

<!-- gh-comment-id:2537786219 --> @ZaibanAli commented on GitHub (Dec 12, 2024): @nagug thank you for the detail information. I will look into this again on weekend. (will push a patch)
Author
Owner

@nagug commented on GitHub (Dec 15, 2024):

@ZaibanAli - any luck., feel free to ping, if you need any additional data

<!-- gh-comment-id:2543846634 --> @nagug commented on GitHub (Dec 15, 2024): @ZaibanAli - any luck., feel free to ping, if you need any additional data
Author
Owner

@ZaibanAli commented on GitHub (Dec 16, 2024):

@nagug on it, haven't got the time to setup the authentik

<!-- gh-comment-id:2546235448 --> @ZaibanAli commented on GitHub (Dec 16, 2024): @nagug on it, haven't got the time to setup the authentik
Author
Owner

@nagug commented on GitHub (Dec 18, 2024):

Thanks for the effort. Look forward to it

<!-- gh-comment-id:2551815076 --> @nagug commented on GitHub (Dec 18, 2024): Thanks for the effort. Look forward to it
Author
Owner

@ZaibanAli commented on GitHub (Dec 18, 2024):

@nagug looks like it is Authentik specific issue. When the openwebui redirect the response to the endsession url it actually signout from the Authentik application but not from the authentik instance.

I am not an expert with Authentik but it is something to do with how the authentik handles the flows?

When the end_session url http://<authentik_instance_url>/application/o/openwebui/end-session/?id_token_hint=..... is clicked I get the following https://snipboard.io/vMZ7SP.jpg which actually show that the flow is working on openwebui end.

<!-- gh-comment-id:2552134761 --> @ZaibanAli commented on GitHub (Dec 18, 2024): @nagug looks like it is Authentik specific issue. When the openwebui redirect the response to the endsession url it actually signout from the Authentik application but not from the authentik instance. I am not an expert with Authentik but it is something to do with how the authentik handles the flows? When the end_session url http://<authentik_instance_url>/application/o/openwebui/end-session/?id_token_hint=..... is clicked I get the following https://snipboard.io/vMZ7SP.jpg which actually show that the flow is working on openwebui end.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/open-webui#53470