Originally created by @Tryanks on GitHub (Jan 16, 2025).
Is your feature request related to a problem? Please describe.
The current OAuth2 only supports OIDC login with a well-known URL, such as https://accounts.google.com/.well-known/openid-configuration.
This makes the essence of all OAuth2 logins inherently OIDC logins. At the same time, this also makes it difficult to add support for Github OAuth2 to the same list, because Github OAuth does not provide a .well-known compatible solution.
Describe the solution you'd like
An unreasonable solution would be to move all current OAuth2 authentications under the OIDC category and establish a dedicated authentication implementation for OAuth2.
A slightly more reasonable solution would be to implement a separate authentication method for Github and directly add it to the OIDCs environment variables list in the configuration options.
Describe alternatives you've considered
Using oauth2-proxy can simplify enabling open webui to support Github authentication, and this is the solution I am currently using. However, its consistency is not ideal and can only be considered a temporary measure.
Additional context
I am interested in providing a PR for this feature, but the issue lies in the project structure. To support Github OAuth2, code reuse is obviously impossible, and the goal can only be achieved by writing a substantial amount of dedicated code for it.
I hope that the Members and everyone else can share their views on this requirement in this discussion.
Originally created by @Tryanks on GitHub (Jan 16, 2025).
**Is your feature request related to a problem? Please describe.**
The current OAuth2 only supports OIDC login with a well-known URL, such as https://accounts.google.com/.well-known/openid-configuration.
This makes the essence of all OAuth2 logins inherently OIDC logins. At the same time, this also makes it difficult to add support for Github OAuth2 to the same list, because Github OAuth does not provide a `.well-known` compatible solution.
**Describe the solution you'd like**
An unreasonable solution would be to move all current *OAuth2* authentications under the OIDC category and establish a dedicated authentication implementation for OAuth2.
A slightly more reasonable solution would be to implement a separate authentication method for Github and directly add it to the OIDCs environment variables list in the configuration options.
**Describe alternatives you've considered**
Using oauth2-proxy can simplify enabling `open webui` to support Github authentication, and this is the solution I am currently using. However, its consistency is not ideal and can only be considered a temporary measure.
**Additional context**
I am interested in providing a PR for this feature, but the issue lies in the project structure. To support Github OAuth2, code reuse is **obviously** impossible, and the goal can only be achieved by writing a substantial amount of dedicated code for it.
I hope that the Members and everyone else can share their views on this requirement in this discussion.
@Tryanks commented on GitHub (Jan 17, 2025):
> Also Google :)
The current Open WebUI inherently supports GOOGLE :)
https://docs.openwebui.com/features/sso#google
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 @Tryanks on GitHub (Jan 16, 2025).
Is your feature request related to a problem? Please describe.
The current OAuth2 only supports OIDC login with a well-known URL, such as https://accounts.google.com/.well-known/openid-configuration.
This makes the essence of all OAuth2 logins inherently OIDC logins. At the same time, this also makes it difficult to add support for Github OAuth2 to the same list, because Github OAuth does not provide a
.well-knowncompatible solution.Describe the solution you'd like
An unreasonable solution would be to move all current OAuth2 authentications under the OIDC category and establish a dedicated authentication implementation for OAuth2.
A slightly more reasonable solution would be to implement a separate authentication method for Github and directly add it to the OIDCs environment variables list in the configuration options.
Describe alternatives you've considered
Using oauth2-proxy can simplify enabling
open webuito support Github authentication, and this is the solution I am currently using. However, its consistency is not ideal and can only be considered a temporary measure.Additional context
I am interested in providing a PR for this feature, but the issue lies in the project structure. To support Github OAuth2, code reuse is obviously impossible, and the goal can only be achieved by writing a substantial amount of dedicated code for it.
I hope that the Members and everyone else can share their views on this requirement in this discussion.
@AzizDXT commented on GitHub (Jan 17, 2025):
Also Google :)
@Tryanks commented on GitHub (Jan 17, 2025):
The current Open WebUI inherently supports GOOGLE :)
https://docs.openwebui.com/features/sso#google