Is your feature request related to a problem? Please describe.
Currently, OpenWebUI allows users to create local accounts with email/password authentication even when OAuth is configured. This creates potential security risks and confusion among employees who should exclusively use OAuth for authentication. Additionally, the login page displays both authentication methods, which might lead employees to attempt using username/password instead of the intended OAuth method.
A related issue is that new accounts can only be set to one of three states during registration:
pending
user
admin
Currently, email/password registrations are automatically set to "user" status, which could lead to unauthorized access.
Describe the solution you'd like
1. Authentication Configuration
A configuration option to completely disable local authentication (email/password) when OAuth is enabled
Make the authentication method configurable through environment variables or config file
2. Modified Login Page Design
When OAuth is enabled: Show only the OAuth login button
For admin access: Create a separate, clearly marked login URL/path
Remove username/password fields from the main login page when OAuth is the intended authentication method
3. Interim Security Enhancement
As a minimal solution: Ensure that new email/password registrations are automatically set to "pending" status instead of "user"
Require admin approval before access is granted
Describe alternatives you've considered
CSS-based Solution
Using CSS to hide the username/password fields
Rejected: Not secure enough as it could be bypassed
Separate Docker Images
Creating separate Docker images for different authentication methods
Rejected: Too complex to maintain
Universal Pending Status
Setting all new registrations to "pending" status
Accepted: This would be a good intermediate solution until full OAuth-only configuration is implemented
Additional context
This feature would enhance security by:
Preventing unauthorized local account creation
Reducing confusion about the correct login method
Streamlining the authentication process for organizations using OAuth
Maintaining separate admin access while enforcing OAuth for regular users
Ensuring new local accounts require admin approval before gaining access
Originally created by @unicorn667 on GitHub (Nov 24, 2024).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/7309
# Feature Request: Enhanced Authentication Configuration & Login Page Design
## Is your feature request related to a problem? Please describe.
Currently, OpenWebUI allows users to create local accounts with email/password authentication even when OAuth is configured. This creates potential security risks and confusion among employees who should exclusively use OAuth for authentication. Additionally, the login page displays both authentication methods, which might lead employees to attempt using username/password instead of the intended OAuth method.
A related issue is that new accounts can only be set to one of three states during registration:
- pending
- user
- admin
Currently, email/password registrations are automatically set to "user" status, which could lead to unauthorized access.
## Describe the solution you'd like
### 1. Authentication Configuration
- A configuration option to completely disable local authentication (email/password) when OAuth is enabled
- Make the authentication method configurable through environment variables or config file
### 2. Modified Login Page Design
- When OAuth is enabled: Show only the OAuth login button
- For admin access: Create a separate, clearly marked login URL/path
- Remove username/password fields from the main login page when OAuth is the intended authentication method
### 3. Interim Security Enhancement
- As a minimal solution: Ensure that new email/password registrations are automatically set to "pending" status instead of "user"
- Require admin approval before access is granted
## Describe alternatives you've considered
1. **CSS-based Solution**
- Using CSS to hide the username/password fields
- Rejected: Not secure enough as it could be bypassed
2. **Separate Docker Images**
- Creating separate Docker images for different authentication methods
- Rejected: Too complex to maintain
3. **Universal Pending Status**
- Setting all new registrations to "pending" status
- Accepted: This would be a good intermediate solution until full OAuth-only configuration is implemented
## Additional context
This feature would enhance security by:
- Preventing unauthorized local account creation
- Reducing confusion about the correct login method
- Streamlining the authentication process for organizations using OAuth
- Maintaining separate admin access while enforcing OAuth for regular users
- Ensuring new local accounts require admin approval before gaining access
---
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @unicorn667 on GitHub (Nov 24, 2024).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/7309
Feature Request: Enhanced Authentication Configuration & Login Page Design
Is your feature request related to a problem? Please describe.
Currently, OpenWebUI allows users to create local accounts with email/password authentication even when OAuth is configured. This creates potential security risks and confusion among employees who should exclusively use OAuth for authentication. Additionally, the login page displays both authentication methods, which might lead employees to attempt using username/password instead of the intended OAuth method.
A related issue is that new accounts can only be set to one of three states during registration:
Currently, email/password registrations are automatically set to "user" status, which could lead to unauthorized access.
Describe the solution you'd like
1. Authentication Configuration
2. Modified Login Page Design
3. Interim Security Enhancement
Describe alternatives you've considered
CSS-based Solution
Separate Docker Images
Universal Pending Status
Additional context
This feature would enhance security by: