[GH-ISSUE #12470] issue: Microsoft OAUTH Login doesn't work with custom signing keys #16615

New Issue

GiteaMirror · 2026-04-19T22:30:40-05:00

GiteaMirror commented

2026-04-19 22:30:40 -05:00

Originally created by @aleprj on GitHub (Apr 4, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/12470

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

0.6.0

Ollama Version (if applicable)

No response

Operating System

Ubuntu

Browser (if applicable)

Chrome

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 listed steps to reproduce the bug in detail.

Expected Behavior

When trying to use an Azure login that requires custom signing keys, it should work.

Actual Behavior

It says the email or password provided is incorrect, and there's a message in the console saying "Invalid JSON Web Key Set".

Steps to Reproduce

Configure an application in Azure AD with custom signing keys (e.g., by implementing claims-mapping policies).
Set the env vars: MICROSOFT_CLIENT_ID, MICROSOFT_CLIENT_SECRET and MICROSOFT_CLIENT_TENANT_ID
Try to login with Microsoft

Logs & Screenshots

The relevant message in the log is: Invalid JSON Web Key Set
(sorry, I didn't keep the full log)

Additional Information

The application currently retrieves the OpenID Connect metadata document from (this is backend/open_webui/config.py):
https://login.microsoftonline.com/{MICROSOFT_CLIENT_TENANT_ID.value}/v2.0/.well-known/openid-configuration
To ensure the jwks_uri in the metadata points to the correct signing key information, we need the appid query parameter:
https://login.microsoftonline.com/{MICROSOFT_CLIENT_TENANT_ID.value}/v2.0/.well-known/openid-configuration?appid={MICROSOFT_CLIENT_ID.value}.
Appending the appid parameter is safe and does not impact applications that do not use custom signing keys, as it will return the common keys (I've tested both scenarios).
https://learn.microsoft.com/en-us/entra/identity-platform/access-tokens

Originally created by @aleprj on GitHub (Apr 4, 2025). Original GitHub issue: https://github.com/open-webui/open-webui/issues/12470 ### 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 0.6.0 ### Ollama Version (if applicable) _No response_ ### Operating System Ubuntu ### Browser (if applicable) Chrome ### 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. - [x] I have included the browser console logs. - [x] I have included the Docker container logs. - [x] I have listed steps to reproduce the bug in detail. ### Expected Behavior When trying to use an Azure login that requires custom signing keys, it should work. ### Actual Behavior It says the email or password provided is incorrect, and there's a message in the console saying "Invalid JSON Web Key Set". ### Steps to Reproduce 1. Configure an application in Azure AD with custom signing keys (e.g., by implementing claims-mapping policies). 2. Set the env vars: MICROSOFT_CLIENT_ID, MICROSOFT_CLIENT_SECRET and MICROSOFT_CLIENT_TENANT_ID 3. Try to login with Microsoft ### Logs & Screenshots The relevant message in the log is: Invalid JSON Web Key Set (sorry, I didn't keep the full log) ### Additional Information The application currently retrieves the OpenID Connect metadata document from (this is backend/open_webui/config.py): https://login.microsoftonline.com/{MICROSOFT_CLIENT_TENANT_ID.value}/v2.0/.well-known/openid-configuration To ensure the jwks_uri in the metadata points to the correct signing key information, we need the appid query parameter: https://login.microsoftonline.com/{MICROSOFT_CLIENT_TENANT_ID.value}/v2.0/.well-known/openid-configuration?appid={MICROSOFT_CLIENT_ID.value}. Appending the appid parameter is safe and does not impact applications that do not use custom signing keys, as it will return the common keys (I've tested both scenarios). https://learn.microsoft.com/en-us/entra/identity-platform/access-tokens

GiteaMirror added the bug label 2026-04-19 22:30:40 -05:00

GiteaMirror closed this issue

2026-04-19 22:30:41 -05:00

GiteaMirror commented

2026-04-19 22:30:42 -05:00

@icsy7867 commented on GitHub (Apr 5, 2025):

I dont know if this is the same issue. open-webui is using oauth2-proxy in the background, and when using ADFS, you have to use either increase the proxy buffer size, or use redis.

And open-webui doesnt have redis storage configured for oauth2-proxy internally. I ended up running oauth2-proxy in another docker container, and setting up redis, and then used header auth.

https://github.com/open-webui/open-webui/issues/11392

If you look the the ADFS configuration, or the Azure (not sure if that is the same thing you are using), but look at the note on the bottom of the page...

https://oauth2-proxy.github.io/oauth2-proxy/configuration/providers/azure

Notes:

When using v2.0 Azure Auth endpoint (https://login.microsoftonline.com/{tenant-id}/v2.0) as --oidc_issuer_url, in conjunction with --resource flag, be sure to append /.default at the end of the resource name. See https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-permissions-and-consent#the-default-scope for more details.

When using the Azure Auth provider with nginx and the cookie session store you may find the cookie is too large and doesn't get passed through correctly. Increasing the proxy_buffer_size in nginx or implementing the [redis session storage](https://oauth2-proxy.github.io/oauth2-proxy/configuration/session_storage#redis-storage) should resolve this.

@icsy7867 commented on GitHub (Apr 5, 2025): I dont know if this is the same issue. open-webui is using oauth2-proxy in the background, and when using ADFS, you have to use either increase the proxy buffer size, or use redis. And open-webui doesnt have redis storage configured for oauth2-proxy internally. I ended up running oauth2-proxy in another docker container, and setting up redis, and then used header auth. https://github.com/open-webui/open-webui/issues/11392 If you look the the ADFS configuration, or the Azure (not sure if that is the same thing you are using), but look at the note on the bottom of the page... https://oauth2-proxy.github.io/oauth2-proxy/configuration/providers/azure ``` Notes: When using v2.0 Azure Auth endpoint (https://login.microsoftonline.com/{tenant-id}/v2.0) as --oidc_issuer_url, in conjunction with --resource flag, be sure to append /.default at the end of the resource name. See https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-permissions-and-consent#the-default-scope for more details. When using the Azure Auth provider with nginx and the cookie session store you may find the cookie is too large and doesn't get passed through correctly. Increasing the proxy_buffer_size in nginx or implementing the [redis session storage](https://oauth2-proxy.github.io/oauth2-proxy/configuration/session_storage#redis-storage) should resolve this. ```

GiteaMirror referenced this issue

2026-04-20 00:23:51 -05:00

[GH-ISSUE #17141] issue: Cmd+Enter shortcut to send message fails after activating IME #18182

GiteaMirror referenced this issue

2026-04-20 05:16:40 -05:00

[PR #16619] [MERGED] fix: fix the Enter issue of Chinese input (fix #16615) #24186

GiteaMirror referenced this issue

2026-04-20 05:18:56 -05:00

[PR #16885] [MERGED] fix: fix Safari IME composition bug (#16615) #24270

GiteaMirror referenced this issue

2026-04-25 07:35:55 -05:00

[GH-ISSUE #17141] issue: Cmd+Enter shortcut to send message fails after activating IME #33711