mirror of
https://github.com/open-webui/open-webui.git
synced 2026-05-05 18:38:17 -05:00
[GH-ISSUE #929] feat: allow login without authentication #50920
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/open-webui#50920
Reference in New Issue
Block a user
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?
Originally created by @mckennajones on GitHub (Feb 26, 2024).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/929
Originally assigned to: @tjbck on GitHub.
Many self hosted programs have an authentication-by-default approach these days. I get why that's the case, but, if a user has deployed the app only locally in their intranet, or if it's behind a secure network using a tool like Tailscale, then a password protected app isn't as necessary, and feels a bit cumbersome.
Possible solutions:
@duhow commented on GitHub (Feb 27, 2024):
💡 This can be split into two steps:
@justinh-rahb commented on GitHub (Feb 27, 2024):
Frontend will need a way to disable the login screen anyway if we're to implement a system whereby we can have a separate build flag to produce the "Lite" version of the UI only.
@adlostwolf commented on GitHub (Mar 4, 2024):
Is there no way to reset your password? I can't login.
@justinh-rahb commented on GitHub (Mar 4, 2024):
https://github.com/open-webui/open-webui/discussions/1027#discussioncomment-8661327
@sammcj commented on GitHub (Mar 20, 2024):
I'm no js/svelte dev but maybe something like https://github.com/open-webui/open-webui/compare/main...sammcj:open-webui:main
@Chukarslan commented on GitHub (Mar 21, 2024):
@duhow do you have a PR / Fork for this?
@jikkuatwork commented on GitHub (Mar 25, 2024):
True, its sort of weird to see an authentication page for a local app.
@luboszima commented on GitHub (Mar 29, 2024):
Any update?
I tried to disable signup with hope to be able login without signup but It doesnt work. I am glad for this open issue, I hope someone can implement it soon.
@blazp7 commented on GitHub (Apr 3, 2024):
I thought if there is no OIDC auth in this app, i could just disable logins and secure the app with a reverse proxy. Either one would be nice to have.
@sammcj commented on GitHub (Apr 6, 2024):
I’ve tried hacking on the code a few times to try and contribute a fix but my limited webdev skills only got me so far.
Running the app behind existing authentication or even in single user mode would be ideal but I’m not sure I can craft a good enough fix to submit.
I’ve just sponsored the project, so I hope that helps at least.
@tjbck commented on GitHub (Apr 6, 2024):
Related: https://github.com/open-webui/open-webui/issues/483
@sammcj commented on GitHub (Apr 7, 2024):
Thanks @tjbck, I suspect this might resolve quite a number of the use cases that people in this thread share (i.e. those of us that already have the app running behind an auth system such as Authentik etc...).
For me I am now able to use Open WebUI without logging in a second time by simply passing through the email header from Authentik 🎉:
I think there are probably still quite a few people that want no authentication all together but this is a good step forward.
@justinh-rahb commented on GitHub (Apr 7, 2024):
Not gonna lie, I think I like this solution better than building auth in ourselves, and it's been our stated opinion that we feel auth shouldn't be optional.
@sammcj commented on GitHub (Apr 7, 2024):
If there was a 💯 reaction emoji you would have just got it.
@sammcj commented on GitHub (Apr 7, 2024):
I might even do a PR to add an example docker-compose with everything you need for auth with Traefik+Authentik, but perhaps there's a lighter weight option than Authentik (it's java 🤮) I'm not aware of that'd be better suited.
@justinh-rahb commented on GitHub (Apr 7, 2024):
I am not against this, if it can be done as an optional additional compose file like we've done for GPU support for example, I say go for it.
@sammcj commented on GitHub (Apr 7, 2024):
Here's a really rough example if anyone else wants it, you'll need to tweak things for your environment/network/secrets etc... and follow a tutorial on setting up Authentik for domain forward auth.
example-docker-compose.yaml
@eingemaischt commented on GitHub (Apr 10, 2024):
Another option would be to rely authorization on header flags set by a reverse proxy - so that my apache2 can do openid and set the username as "x-forwarded-user" flag and the "x-forwarded-group" as admin, if the user should have administrative privileges...
@chrisbward commented on GitHub (Apr 30, 2024):
Oh, just found this ticket!
I've tried running the docker container with the documented env flag set to "False", and still have the login form;
https://github.com/open-webui/open-webui/issues/1875
@tjbck commented on GitHub (May 8, 2024):
https://docs.openwebui.com/getting-started/env-configuration#webui_auth
@sammcj commented on GitHub (May 8, 2024):
Maybe I'm doing something wrong, but with a fresh install / container volumes with
WEBUI_AUTH: falsegives the error:docker-compose:
@justinh-rahb commented on GitHub (May 8, 2024):
@sammcj The intent of this "feature" wasn't to be replaced by something like Authentik. That could have already been put in in-front of our authentication before, using the trusted email auth header which effectively delegates it to an external proxy.
@tjbck commented on GitHub (May 8, 2024):
@sammcj investigating
@sammcj commented on GitHub (May 8, 2024):
@tjbck thanks it looks like that fixed webui_auth:true + authentik.
FYI the behaviour is now:
Note however -
@tjbck commented on GitHub (May 8, 2024):
Just updated the code, see if that did anything for you.
@sammcj commented on GitHub (May 8, 2024):
That fixed it!
Now:
You folks are awesome :)
@ghost commented on GitHub (Mar 13, 2025):
Just fork and remove this nonsense
@qhaas commented on GitHub (Apr 22, 2025):
Can an example be provided? Per issue #13090 , simply setting
WEBUI_AUTH_TRUSTED_EMAIL_HEADERto the header field containing the user's email as provided by the external authentication mechanism / reverse proxy (e.g. keycloak + OpenResty + lua-resty-openidc) doesn't appear to be sufficient.@eroyee commented on GitHub (May 11, 2025):
Like many other people, per the official advice, I originally installed open-webui using docker and setup a local admin account etc. At the time I wondered why this was necessary, but there didn't immediately seem to be a way to avoid this.
Later, after it became too annoying I landed here trying to figure out how to remove auth. Unfortunately just setting WEBUI_AUTH=False when starting the service won't work (as advertised) and it wasn't initially clear how to deal with this.
So, for anyone else using Ubuntu with the docker version of open-webui, and who has the db maintained externally per the official run command (docker run -d -p 3000:8080 -v open-webui:/app/backend/data --name open-webui ghcr.io/open-webui/open-webui:main), this is what I did to resolve the issue. Note that this maintains a copy of the original db should one want to revert, but the result will, necessarily, remove all history etc from the UI so it's as if starting from new albeit no longer requiring login credentials:
docker stop open-webuimv /var/lib/docker/volumes/open-webui/_data/webui.db /var/lib/docker/volumes/open-webui/_data/webui.db.originaldocker rm open-webuidocker run -d -p 3000:8080 -e WEBUI_AUTH=False -v open-webui:/app/backend/data --name open-webui ghcr.io/open-webui/open-webui:mainThat's it, you should now be able to use open-webui without login. To revert you'd stop the instance again and simply move (or copy) the renamed db back to it's original name eg:
mv /var/lib/docker/volumes/open-webui/_data/webui.db.original /var/lib/docker/volumes/open-webui/_data/webui.dbFinally, as comment for any future development, if it were possible to auth just with a simple username instead of a full email address that may be less aggravating? If one could use a simple one-letter user/pass then it may address some of the other comments/issues I've seen, and may not require much re-factoring in the present code to implement?