mirror of
https://github.com/open-webui/open-webui.git
synced 2026-07-17 08:21:12 -05:00
[GH-ISSUE #17241] issue: OAuth with MS Entry stopped working #105212
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/open-webui#105212
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 @jdeepwell on GitHub (Sep 6, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/17241
Check Existing Issues
Installation Method
Docker
Open WebUI Version
v0.6.26
Ollama Version (if applicable)
No response
Operating System
Ubuntu 22.04.5 LTS
Browser (if applicable)
No response
Confirmation
README.md.Expected Behavior
After successful MS Entry OAuth being logged in to OpenWebUI (as it was in previous OpenWebUI versions)
Actual Behavior
MS Entra OAuth works, but user is being sent back to OpenWebUI Auth page
Steps to Reproduce
Logs & Screenshots
Log excerpt using OpenID OAuth provider
Log excerpt using Microsoft OAuth provider
Browser console output:
Additional Information
I was using MS Auth for some time now and it worked fine. The configuration in OpenWebUI, Apache and MS Entra was not changed, but MS OAuth in OpenWebUI stopped working. I am not sure with which update this started, because each already logged in users still works fine. But fresh users (or after clearing out all cookies for a currently logged in user) fail.
When everything is clean (no auth with MS yet or all cookies cleared), clicking the "Continue with Microsoft SSO" button on the login page sends me to the MS login. I can then perform the login there fine but when coming back OpenWebUI I again end up on the login page. Clicking the "Continue with Microsoft SSO" there again, again ends up at the login page (after a redirect round trip to MS).
I can tell that the MS auth worked, because if I then go to one of our other servers that's using the same auth, I'm logged in there.
Also: If I delete the oauth_sub value for a user and try to login via MS OAth, I get a new oauth_sub value ("oidc@....") - I assume that should mean that the OAuth basically worked. But nevertheless I always end up at the login page.
I see now error message in the logs.
I also switched to debug log mode ("GLOBAL_LOG_LEVEL=DEBUG") - still no error message.
Setup with generic OpenID (OIDC) OAuth:
I also tried switching from the generic OpenID (OIDC) OAuth provider to the specific Microsoft one - same behaviour.
Setup with explicit MS OAuth:
Here's the flow, when I already authenticated with MS:
(x.x.x.x beeing a placeholder for our server name)
When clicking the "Continue with Microsoft SSO" button on the login page I get directed to
https://login.microsoftonline.com/.../oauth2/v2.0/authorize?.... That in turn then redirects tohttps://x.x.x.x/oauth/oidc/callback?code=...but ends up showing the login page again (the request to/oauth/oidc/callback?...redirects to the/authpage again)@mpuzar commented on GitHub (Sep 12, 2025):
I can confirm the exact same behavior with Microsoft SSO in v0.6.28, after upgrading from an older version where everything worked smoothly for months.
Setup here:
The token and oauth_id_token are issued and seem to contain correct information and I can validate the signatures.
The tokens have the secure flag set (even though I tried disabling it with enviornment variables), so I do wonder whether that might be causing the issue.
I could find no error messages in any of the logs. It's just as if the tokens are ignored and every time it serves the non-logged-in page. I tried a lot of combinations of settings via environment variable, but nothing seems to help.
@jdeepwell commented on GitHub (Sep 13, 2025):
I stumbled over a similar issue with LiteLLM. There it was also closely related to the token cookie, so I checked again now with OpenWebUI.
It turns out it's the very same issue:
After successful authentication via Microsoft the token cookie is set. That token cookie has the
HttpOnlyset totrue.As long as this is so, I get redirected to the auth page.
Once I set that cookie to
HttpOnly=falseit immediately works, I am logged in and can use OWUI.Interestingly the cookie is immediately afterwards set to
HttpOnly=trueagain, but that does not seem to hurt – I can close the window and open it up again and am still logged in can use OWUI normally.I am assuming the JS code is trying to read that cookie, can not and therefore sends the use back to the auth page.
I am assuming that this as to do with the setup that OWUI is accessed via HTTP (not HTTPS) by the reverse-proxy (all the TLS towards the outside/user is handled by Apache in our case).
@Classic298 commented on GitHub (Sep 13, 2025):
You are missing
OPENID_PROVIDER_URLAlso, what's your cookie settings set to?
WEBUI_SESSION_COOKIE_SAME_SITE=laxWEBUI_AUTH_COOKIE_SAME_SITE=lax^ these are recommended if you encounter OAUTH issues.
WEBUI_AUTH_COOKIE_SECURE=True
WEBUI_SESSION_COOKIE_SECURE=True
@jdeepwell commented on GitHub (Sep 13, 2025):
Hey @Classic298 - thx for the reply!
So, I added
and updated to v0.6.28
But still the same behavior. Only difference is that I now also see the
oauth_id_tokenandoauth_session_idcookies. But despite the fact that after authenticating @ MS I have a validtokencookie, I still am getting redirected back to the auth page. Only when I (temporarily, once) set thetokencookie'sHttpOnlytofalseam I successfully logged in and can use OWUI.J.
@Classic298 commented on GitHub (Sep 13, 2025):
what reverse proxy do you use? how did you configure it
@jdeepwell commented on GitHub (Sep 13, 2025):
A have to use Apache.
We are using
mod_mdfor TLS / Let's Encrypt and we are using TLS client certificates for additional auth.And here's the OWUI part of the docker-compose.yaml
@Classic298 commented on GitHub (Sep 14, 2025):
@jdeepwell please try these:
WEBUI_SESSION_COOKIE_SECURE=false
WEBUI_AUTH_COOKIE_SECURE=false
WEBUI_SESSION_COOKIE_SAME_SITE=lax
WEBUI_AUTH_COOKIE_SAME_SITE=lax
ENABLE_OAUTH_PERSISTENT_CONFIG=false
and try these for apache
@jdeepwell commented on GitHub (Sep 14, 2025):
@Classic298 many thx for your reply!
I tried the config you proposed - unfortunately without change in outcome.
So the main changes were
The latter three I would assume could help if the OAuth process itself was the actual issue - but it very much seems that this is not the case. OAuth via Microsoft is successful! Otherwise I should not get a valid token cookie. And that token cookie really is valid, as when I just make it available to the client side JS (by setting its HttpOnly to false) I am successfully logged in.
As to the first one: I am not sure which "session cookies" these setting actually are referring to, but all cookies that end up in the browser still do have the secure set to true:
As far as OWUI is concerned it actually is not a secure connection - the connection from the backend (OWUI) to the reverse proxy (Apache) is http only.
So the behavior still is the same: All of OAuth works fine. but at the very and I still am getting redirected (by some client side JS code) to the login page. Setting the
tokencookie's HttpOnly to false immediately works and I am successfully logged in (without having to go through OAuth again)So I therefore tried adding this to the Apache config:
and this works. I can clear all cookies, start the authentication process via Microsoft and am logged in nicely 👍
the only question is - why? 🤷♂️
Why is OWUI setting the HttpOnly flag in the token cookie when there seems to be some client side JS that needs to read it for a successful login?
@Classic298 commented on GitHub (Sep 14, 2025):
@jdeepwell
try this: ENABLE_OAUTH_ID_TOKEN_COOKIE=false
yes, as intended, and it's a non issue really
@jdeepwell commented on GitHub (Sep 14, 2025):
@Classic298
Tried it -
oauth_id_tokenis now missing in the browser. Other than that, same as before 😢BTW: After one turnaround (clicking the "Continue with Microsoft" at the login page - full auth process @ MS - back to OWUI - redirect to login page again), clicking the "Continue with Microsoft" again only flashes the page (sends to MS and right back again)
@Classic298 commented on GitHub (Sep 14, 2025):
@jdeepwell i know this is possibly out of scope for you, but can you try NGINX instead of apache for testing purposes?
Either way, this seems more and more like a communication issue from the backend to the frontend
The frontend code seemingly hasn't been fully updated to work without direct cookie access
@jdeepwell commented on GitHub (Sep 14, 2025):
I can try to setup some test server that is reachable from the web (to test OAuth) and play it with Nginx. Unfortunately that would not be a solution for me, as I am tied to Apache...😥
It's interesting that I have the very same issue with the LiteLLM UI...🤔 (even without OAuth there)
Yes, that sounds plausible. For now I will stick to the
Header edit Set-Cookie...hack - especially because for some reason the cookie seems to get reset to HttpOnly=true by the frontend code anyway (after successful login), so my security concerns are moderate.Thx again for your input @Classic298
@AlexOrlov21 commented on GitHub (Sep 15, 2025):
@jdeepwell, try - OAUTH_USERNAME_CLAIM=whatever you use for username
It worked for my installation.
@jdeepwell commented on GitHub (Sep 16, 2025):
@AlexOrlov21 Thx for the tip - unfortunately same result: Sends me right back to the login page after successful auth @ MS...
@mpuzar commented on GitHub (Sep 19, 2025):
Ok, I can confirm that it is the HttpOnly parameter that is causing the problem. If I strip it away in haproxy (from all the cookies, while testing), I get in as expected and can seemingly use the application as before.