Disable password logins when oauth2 is used #11066

Closed
opened 2025-11-02 09:26:36 -06:00 by GiteaMirror · 9 comments
Owner

Originally created by @luna-duclos on GitHub (Jun 20, 2023).

Feature Description

It would be great if gitea would allow me to disable password changes for users who's account has been created via an oauth2 login and disallow them to login using it even if they had set it.

As well as hide the relevant components of the web UI.

a PR for this was made in the past: #19344, but it seems it was closed without review. I was wondering if it would be something that is ok to potentially recontribute ?

Screenshots

No response

Originally created by @luna-duclos on GitHub (Jun 20, 2023). ### Feature Description It would be great if gitea would allow me to disable password changes for users who's account has been created via an oauth2 login and disallow them to login using it even if they had set it. As well as hide the relevant components of the web UI. a PR for this was made in the past: #19344, but it seems it was closed without review. I was wondering if it would be something that is ok to potentially recontribute ? ### Screenshots _No response_
GiteaMirror added the type/proposaltype/feature labels 2025-11-02 09:26:36 -06:00
Author
Owner

@lunny commented on GitHub (Jun 20, 2023):

Should that be an option of this OAuth2 source setting?

@lunny commented on GitHub (Jun 20, 2023): Should that be an option of this OAuth2 source setting?
Author
Owner

@silverwind commented on GitHub (Jun 20, 2023):

Has to be a global config option I assume as there can be multiple oauth sources etc. Also, it is quite a risky thing because if oauth provider is down, not even admin can log in.

@silverwind commented on GitHub (Jun 20, 2023): Has to be a global config option I assume as there can be multiple oauth sources etc. Also, it is quite a risky thing because if oauth provider is down, not even admin can log in.
Author
Owner

@wxiaoguang commented on GitHub (Jun 21, 2023):

I do not think this issue can be resolved by "easy" patches.

See

The first step IMO is to have a (nearly) complete design,to define the expected behaviors for various situations.

@wxiaoguang commented on GitHub (Jun 21, 2023): I do not think this issue can be resolved by "easy" patches. See * https://github.com/go-gitea/gitea/issues/24821 > The first step IMO is to have a (nearly) complete design,to define the expected behaviors for various situations.
Author
Owner

@luna-duclos commented on GitHub (Jun 21, 2023):

Has to be a global config option I assume as there can be multiple oauth sources etc. Also, it is quite a risky thing because if oauth provider is down, not even admin can log in.

As long as its an app.ini setting, whoever administers the instance could disable it again to log in as admin again, no ?

@luna-duclos commented on GitHub (Jun 21, 2023): > Has to be a global config option I assume as there can be multiple oauth sources etc. Also, it is quite a risky thing because if oauth provider is down, not even admin can log in. As long as its an app.ini setting, whoever administers the instance could disable it again to log in as admin again, no ?
Author
Owner

@jaltgen commented on GitHub (Jun 5, 2024):

I'd be in favor of this as well, Portainer has this option in the GUI, for example 👍 I understand it may not fit in the current scope of work or schedule, its just one of those small things that may increase security and make adoption with organisations easier?

@jaltgen commented on GitHub (Jun 5, 2024): I'd be in favor of this as well, Portainer has this option in the GUI, for example 👍 I understand it may not fit in the current scope of work or schedule, its just one of those small things that may increase security and make adoption with organisations easier?
Author
Owner

@gtherond commented on GitHub (Sep 9, 2024):

I'd like to second this as we exactly use that with our on-premise coder (coder.com) instance and it works like a bliss as we can still enable back the password based login by just switching back the environment variable to its default value.

This allows us (as long as with the disabled signup feature) to tightly control who access and sign in the forge.

Additionally, we're using a kubernetes deployment so switching back some env vars is swift and smooth without any visible interrupt for our users.

@gtherond commented on GitHub (Sep 9, 2024): I'd like to second this as we exactly use that with our on-premise coder (coder.com) instance and it works like a bliss as we can still enable back the password based login by just switching back the environment variable to its default value. This allows us (as long as with the disabled signup feature) to tightly control who access and sign in the forge. Additionally, we're using a kubernetes deployment so switching back some env vars is swift and smooth without any visible interrupt for our users.
Author
Owner

@phluxx commented on GitHub (Nov 9, 2024):

Third for this request

@phluxx commented on GitHub (Nov 9, 2024): Third for this request
Author
Owner

@Edo78 commented on GitHub (Jan 21, 2025):

I just installed gitea and I'm working through the configuration options to have it tailored to my needs.
I found

ENABLE_BASIC_AUTHENTICATION: true: Disable this to disallow authentication using HTTP BASIC and the user's password. Please note if you disable this you will not be able to access the tokens API endpoints using a password. Further, this only disables BASIC authentication using the password - not tokens or OAuth Basic.

ENABLE_PASSWORD_SIGNIN_FORM: true: Show the password login form (for password-based login). If you set it to false, maybe it also needs to set ENABLE_BASIC_AUTHENTICATION to false to completely disable password-based authentication.

but even with both set to false the login form is still there.
Then I came here searching for an answer but, while writing this comment, I noticed the latest helm chart is for version 1.22.3 while the latest gitea release is the 1.23.1 ... I forced the chart to use the latest release and the two options worked like a charm and the login form vanished ...

... so why is this issue still open? Am I missing something?

@Edo78 commented on GitHub (Jan 21, 2025): I just installed gitea and I'm working through the configuration options to have it tailored to my needs. I found ``` ENABLE_BASIC_AUTHENTICATION: true: Disable this to disallow authentication using HTTP BASIC and the user's password. Please note if you disable this you will not be able to access the tokens API endpoints using a password. Further, this only disables BASIC authentication using the password - not tokens or OAuth Basic. ENABLE_PASSWORD_SIGNIN_FORM: true: Show the password login form (for password-based login). If you set it to false, maybe it also needs to set ENABLE_BASIC_AUTHENTICATION to false to completely disable password-based authentication. ``` but even with both set to `false` the login form is still there. Then I came here searching for an answer but, while writing this comment, I noticed the latest helm chart is for version 1.22.3 while the latest gitea release is the 1.23.1 ... I forced the chart to use the latest release and the two options worked like a charm and the login form vanished ... ... so why is this issue still open? Am I missing something?
Author
Owner

@wxiaoguang commented on GitHub (Jan 21, 2025):

Yes, I think this issue has been resolved in 1.23 (there are too many related issues, this one is missing to close)

Thank you for your feedback!

@wxiaoguang commented on GitHub (Jan 21, 2025): Yes, I think this issue has been resolved in 1.23 (there are too many related issues, this one is missing to close) Thank you for your feedback!
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#11066