mirror of
https://github.com/open-webui/open-webui.git
synced 2026-07-16 06:03:26 -05:00
[GH-ISSUE #8319] OIDC Login Fails with 500 Error Pydantic ValidationError on Missing 'name' Field #15081
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 @karllee830 on GitHub (Jan 4, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/8319
Bug Report
Installation Method
Docker
Environment
Confirmation:
Expected Behavior:
Users should be able to successfully log in to Open WebUI using OIDC authentication, even if the OIDC provider doesn't explicitly provide a user's full name. If no name is provided in the OIDC response, a default name should be used or handled gracefully without causing an error.
When the name field is empty, username should be used as the name.
Actual Behavior:
When attempting to log in with OIDC, the login process fails with a 500 Internal Server Error if the OIDC provider does not return a
namefield (or similar field) in its response. This results in the inability to log in.Description
Bug Summary:
OIDC login fails due to a Pydantic validation error when the user's
namefield is missing in the OIDC response. This is caused by theUserModelrequiring a non-null string for thenameattribute.Reproduction Details
Steps to Reproduce:
pydantic_core._pydantic_core.ValidationErrorfor theUserModel, specifically indicating thenamefield is missing.Logs and Screenshots
Docker Container Logs:
Screenshots/Screen Recordings (if applicable):

Additional Information
The issue seems to be related to the way Open WebUI handles user creation during the OIDC login process. The
UserModelin/app/backend/open_webui/models/users.pyexpects a valid string for thenamefield, and if this field is missing from the OIDC provider's response, a validation error occurs, causing the login process to fail. This could be fixed by either using username as name or having Open WebUI generate a default name in cases when the name is not returned by OIDC.Note
If the bug report is incomplete or does not follow the provided instructions, it may not be addressed. Please ensure that you have followed the steps outlined in the README.md and troubleshooting.md documents, and provide all necessary information for us to reproduce and address the issue. Thank you!
@tjbck commented on GitHub (Jan 5, 2025):
PR Welcome here!
@annatech commented on GitHub (Jan 9, 2025):
I can confirm this issue as well. I currently have this implemented with OneLogin as the oidc provider. Testing if configuring oidc to return a "name" field in the response will bypass this bug.
@annatech commented on GitHub (Jan 9, 2025):
Tested by including name in the oidc response and confirmed that name is included in the OAUTH_SCOPES list. The same issue persists. I suspect here that the error is baked into the code, requiring a PR to fix it.
@kyunwang commented on GitHub (Jan 12, 2025):
Been trying to reproduce this issue but unable to do so.
Having looked into to the code, the default value
Usershould have taken over if the name property was not in the response.Or in the off chance that the provider returned the
namefield as a different type, such as a number.Tested with few scenarios and the default value is taken over as expected.
Below is the example user info returned by the provider which does not contain any name or related information. And uses the fallback as expected.
Example user info returned by provider
Have a small PR to fix this in case the provider does indeed return a non string value for the
namefield. If anyone can review who has this issue.https://github.com/open-webui/open-webui/pull/8493
@annatech commented on GitHub (Jan 22, 2025):
Confirmed that open-webui v0.5.5 does not fix this issue. I guess the PR wasn't merged yet? I meant to test it but because I deploy to kubernetes, I'd have to build and deploy my own image with the changes included. Doable. Just haven't gotten around to it yet.
Anyone else out there available to test?
UPDATE
@karllee830 commented on GitHub (Jan 24, 2025):
Based on my testing, version 0.5.7 still has this issue. It is expected to wait for https://github.com/open-webui/open-webui/pull/8493 to be approved.
@tjbck commented on GitHub (Jan 30, 2025):
Should be fixed on dev, testing wanted here!
@karllee830 commented on GitHub (Jan 31, 2025):
Confirmed after my testing that this has been fixed. :)