Gitea: 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!