Determine desired password-handling behavior for ExternalLoginUsers

[morrildl]

Filing per @strk via gitter, for discussion to arrive at a design.

#679 and #1010 add support for logging in via OAuth2 (and "OpenID Connect") accounts; #618 adds support for (classic) OpenID. This bug is a proposal for how to handle local-to-gitea passwords for such accounts.

From discussions on the above PRs and gitter, there seem to be 3 primary considerations:

1. Need for some way to authenticate git-over-HTTP[S] writes
2. Whether the local Gitea account is expected by users/admins to be recoverable/usable if the upstream OAuth2 account goes away (i.e. can you still log in if you delete your Google/FB/Github account, etc.)
3. What are the right model & UI representations for such accounts & passwords (i.e. what LoginType, whether passwords should be toggle-able via admin UI, etc.)

The options I can think of are:

• Suppress all passwords in UI for OAuth2 accounts, and forbid HTTP[S] git operations -- require SSH-git for these users (allowing HTTP[S] for local-only accounts)
• Suppress (or make optional) passwords during OAuth2 self-reg, and use them only for HTTP-git operations
• Make local passwords a first-class auth mechanism; basically this makes OAuth2 a secondary login mechanism [this is how the OAuth2 code currently works]

Besides the above, there is also a secondary consideration:

• How OAuth2 accounts should interact with self-registration: it's difficult to pre-register local accounts for OAuth2 because the "real" OAuth2 ID is typically an opaque string that it is essentially impossible for an admin to know in advance, meaning in practice you can't currently enable OAuth2 and also turn off self-registration

For this, there are again a few options:

• Do not support disabling self-reg if OAuth2/OpenID is enabled as an auth source
• Support disabling self reg, and add a feature allowing admins to restrict self-registrations to a whitelist of email domains
• Support disabling self reg, and add a full-fledged "these users have requested accounts" moderation UI for admins

[morrildl]

I tried to present the options neutrally, but as a user/admin, my own preference among them is to suppress passwords during OAuth2 signup, but let the user add an HTTP[S] password after the fact, similar to how you'd add an SSH key. (This might even be worth considering in general -- keep UI login password separate from the git HTTP[S] password, so you can make git passwords revocable.)

For the self-reg restrictions, I'd prefer a domain whitelist. Gerrit (for comparison) separates signing up for an account from ACLs that let you actually see anything, so it essentially does the full "admins must approve users" model, and I don't personally think Gitea needs to go that far.

[strk]

Thanks for getting this started @morrildl.
I think a whitelits/blacklist approach is good for self-registration, this can be email (assuming confirmation is always requested for that) or domain/url (for those who are willing to register via OpenID). Not sure what would make a good whitelist/blacklist for OAuth, but in case dynamic-client-registration with OpenID-Connect is implemented the URL whitelist/blacklits could also be re-used there.

Allowing for a user to have no password at all seems an interesting idea to me, and could be implemented as a first step. Doing that would require to redefine how users confirm some critical operations (currently: password change, account deletion) as those are currently requiring to
enter your password again.

That said, I think username/password should be one over several ways to log in, for a user, who should then possibly have multiple ways to authenticate/login. This is already the case with the merged OAuth2 provider in that it has a separate table to list those "external account". And is the case with the OpenID PR, also using a separate table. The difference within the two is what they encode in the "User.LoginSource" field in the "User" table. My "OpenID" branch leaves "User.LoginSource" consistent with "User.LoginName" and "User.Passwd" (so that when logging in via username/password the system knows where to send them [think LDAP or SMTP etc.]), while the "OAuth" mechanism set "User.LoginSource" to the identifier of the OAuth2 source if and only if the user first registered by presenting the OAUth2 credentials. I think this is inconsistent and should be changed.

[strk]

@willemvd your thoughs are welcome on the matter with User.LoginSource

[morrildl]

Re: local password still working for logins -- I definitely recognize people will want this. However my concern here is that I will eventually be running an instance for a business operation, and our password doctrine is that we delegate to an OAuth2 provider, and explicitly don't want our users to have a (working) local password. The reason is that it encourages them to enter weak passwords, or skip using OAuth2 entirely.

IOW, some admins will want to use OAuth2/OpenID as just a way for users to link accounts, or as a convenience feature to pick up profile details; but others will want to use them to avoid local passwords to the extent possible. I feel these are both good use cases, depending in part on whether you're running a public/community or private instance.

[strk]

Treating "local" authentication just as another "LoginSource" to be enabled/disabled could allow implementing your usecase. You'd only enable an OAuth2 LoginSource and be done with it. I actually second that approach.

[peterahl]

Hello!

Is there anyone working on this? And if not, are there any suggestions on where to start, if one where to make a pull request?

A lot of the points made here makes sense, especially from an enterprise point of view. We are currently working on an implementation of gitea for hosting in-house projects.

I definitely recognize people will want this. However my concern here is that I will eventually be running an instance for a business operation, and our password doctrine is that we delegate to an OAuth2 provider, and explicitly don't want our users to have a (working) local password. The reason is that it encourages them to enter weak passwords, or skip using OAuth2 entirely.

We are really interested in this feature, as we are trying to federate our users using openid connect. For us, the best thing would be that the users are registered automatically the first time they log in using openid connect.

If we use the profile scope of OIDC, we would get name and email. We could perhaps use the first part of the email as username, since that would be familiar, and unique. This would off course not work with a publicly hosted version, but a great enterprise option.

I tried to present the options neutrally, but as a user/admin, my own preference among them is to suppress passwords during OAuth2 signup, but let the user add an HTTP[S] password after the fact, similar to how you'd add an SSH key

I second this opinion.

Kind regards
Peter

[lafriks]

@peterahl I think currently noone is working on this

[devmattrick]

Hi there, we are also trying to use Gitea for hosting in-house projects. I would be very useful if it was possible to authenticate using only OAuth and not have the need to link to existing/ new accounts, as we have a number of services that would be a pain to manage multiple credentials for. I think the method @morrildl method would work best for us as well:

as a user/admin, my own preference among them is to suppress passwords during OAuth2 signup, but let the user add an HTTP[S] password after the fact, similar to how you'd add an SSH key. (This might
even be worth considering in general -- keep UI login password separate from the git HTTP[S] password, so you can make git passwords revocable.)

I'm not sure what other uses cases people have, but that seems to make the most sense to me.

[johanhugg]

I am also interested in implementing this (which isn't surprising since both me and @peterahl work for the same company).

However, I am unsure how this would look if I make a solution that fits everyone. Right now I have a proof of concept where if you log in with your provider (for example we use OpenId connect with Keycloak, which is integrating with our Active Directory) a user "profile" is created, and linked with the provider. It is a user that has no password set, the provider is the primary authentication source. This solution works fine for us since the usernames we get from OpenId Connect is compatible with the format that Gitea wants, however different providers have different ways of representing a username, which could (and will) be a problem (this also includes OpenID Connect since the preferred_username can contain special characters and thus incompatible).

[Thulium-Drake]

@johanhugg : Hi Johan,
How did you get Gitea to automatically create useraccounts when the authentication succeeds? I've tried enabling the following options in app.ini, but no cigar..

DISABLE_REGISTRATION              = false
ALLOW_ONLY_EXTERNAL_REGISTRATION  = true
ENABLE_REVERSE_PROXY_AUTHENTICATION = true
ENABLE_REVERSE_PROXY_AUTO_REGISTRATION = true

I basically want my useraccounts to have no (useable) password on their profiles for the same reasons stated earlier (weak passwords, too many passwords etc.).

Did you configure it, or did you need to hack a bit on the code to make it work? In my current setup I'm still asked to fill in a form when signing in via Keycloak with a new useraccount.

Thanks in advance!

[moiflo033]

I would welcome the option for users to only be able to authenticate with ssh, as i don't want my users to skip 2FA like morrildl mentioned.

[tacerus]

Hi,

I would too appreciate if local passwords could be disabled for people who created their Gitea account through an OIDC sign-in - if I could choose whether passwords in Gitea will be completely hidden for those users (hence only allowing authenticated git using SSH), or whether there is a separate option to define passwords for git via HTTP(s), I would probably go for the former, as to not confuse less-tech-savvy users with more password boxes.

[Thulium-Drake]

I think this was fixed in #6606

[mewalig]

@Thulium-Drake #6606 seems to have been done in 2019, so assuming it is included in the code as of June 2021 which is what we are testing on, AFAIK this issue remains. If that's not the case, could anyone provide guidance as to how to make everything password-related disappear, for accounts that we want to be able to authenticate solely through a 3rd party provider such as Gmail? As of now, when we have such accounts, certain operations still ask for a password (at the least, "Delete account" does)

[Thulium-Drake]

It seems you're right, I looked in my config and I already have those options disabled (REQUIRE_EXTERNAL_REGISTRATION_PASSWORD in this case), but it's still possible for me to create a password.

And ofcourse the delete account thingey also asks for a password (though I'd probably never use it ;-) )

[w112nxs]

any idea if this is fixed,.. build a toal new server using the latest docker image and stil; asks for password for google Oauth

[kousu]

How did you get Gitea to automatically create useraccounts when the authentication succeeds? I've tried enabling the following options in app.ini, but no cigar..

DISABLE_REGISTRATION              = false
ALLOW_ONLY_EXTERNAL_REGISTRATION  = true
ENABLE_REVERSE_PROXY_AUTHENTICATION = true
ENABLE_REVERSE_PROXY_AUTO_REGISTRATION = true

I basically want my useraccounts to have no (useable) password on their profiles for the same reasons stated earlier (weak passwords, too many passwords etc.).

It's 4 years later and I have this implemented with gitea 1.17.1:

[service]
DISABLE_REGISTRATION = false
ALLOW_ONLY_EXTERNAL_REGISTRATION = true
ENABLE_CAPTCHA = false
DEFAULT_KEEP_EMAIL_PRIVATE = true
SHOW_REGISTRATION_BUTTON = false

[openid]
ENABLE_OPENID_SIGNIN = false
ENABLE_OPENID_SIGNUP = false

[oauth2_client]
ENABLE_AUTO_REGISTRATION = true
OPENID_CONNECT_SCOPES = email,profile
USERNAME = email
UPDATE_AVATAR = true

I've tested this against GitHub, Slack, and Google OAuth providers. They all behave: the user clicks "Sign in with [service]", they are bounced over to their GitHub/Slack/Google login page and asked "Do you authorize Gitea?", and then bounced right back, logged in with a new account.

Did you ever figure this out @Thulium-Drake?

[kousu]

Though I am happy my users can smoothly self-register without having to make up a new password, I came here to raise the opposite issue which I see @mewalig has already raised

As of now, when we have such accounts, certain operations still ask for a password (at the least, "Delete account" does)

That is: no one can ever delete their account from my server. It's not the end of the world, I can run gitea admin user delete for them, but they have to contact me for that. I'm worried this might give us GDPR-ey problems down the line, when we aren't able to efficiently implement the Right to Erasure.

I guess OAuth accounts would need to use something other than a password to confirm their intent? Can you force someone to re-login via OAuth? I guess that would be a weird UI flow. Does anyone have any ideas?