[Summary] Improve auth source / login system

[wxiaoguang]

Feature Description

There are more and more requirements for a better login system.

Including (but not only):

• Determine desired password-handling behavior for ExternalLoginUsers #1036
• Always put OAuth user info in the ExternalLoginUser table #1143
• Allow to disable local login #13606
• Is it possible to choose default auth source? #7633
• DISABLE_2FA parameter for disabling 2FA added #18481
• DISABLE_LOCAL_USER_MANAGEMENT mode added #18466
• Add setting to force login through openid #21851
• Show OpenID Connect and OAuth on signup page #20242
• Improving authentication with hardware keys / FIDO2 / webauthn + 2FA #21675
• Enforce two-factor auth (2FA: TOTP or WebAuthn) #34187

Some of them might be improved by a "patch", but Gitea really needs a better login system to satisfies most users, otherwise some changes may conflict and block each other eventually.

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

Screenshots

No response

[pboguslawski]

Ideas to consider:

• implement separate framework (go interface, as stable as possible to avoid breaking compatibility with modules/plugins, as general as possible to allow different solutions, even not known today) for (1) authentication and (2) authorization and (3) user list and migrate existing stuff as separate modules/plugins; allow implementing other modules/plugins in the future,
• ad (1): allow user choose active authentication backends; user should be authenticated if any of active backends allows user (don't think of tokens, passwords only; present HTTP header or sometimes client IP may be enough for some scenarios); don't force users to use specific backends (i.e. oauth, tokens, passwords) nor 2fa (not required when frontend proxy is safe enough and should be trusted blindly); don't assume signon/signin/2fa features are always required (external user backends like LDAP/reverse proxy may work without it),
• ad (2): privileges from different active authz backends should be summarized problably,
• ad (3): users should be periodically synchronized from all active backends (i.e. disable inactive users from LDAP) and created automatically on first login (before sync),
• don't allow local modification of user data that is synchronized from external backend (or allow to disable local user management globally in app if easier),
• for easier maintenance (i.e. less code, automatic setup friendly) and security probably (no access to sensitive config stuff from SQL) allow backend configuration in files (i.e. app.ini) only not UI+SQL (UI is not required for such things and costs time for implementation and maintenance),
• due to the high level of difficulty should be implemented in stages probably.

[jrjake]

I think a good first step to this would be to only show username/email field on login page for first render, so flow sort of looks like this:

• User enter email/username and click "Next" button
• Browser POST with email/username, Gitea checks that account exists.
  • If not exist, Gitea either shows error or redirects to default authentication source (maybe make this configurable in future, but just default to local authentication for now).
  • If exist, Gitea will change action based on account type.
    • If local/SMTP/PAM/LDAP, render password form for user.
    • If SPNEGO, Gitea will send 401 header with Authenticate: Negotiate header and render some "Login in progress" template which gives info about what to do if not working (something like "This authentication method is only supported by computers running Windows. If login does not occur within a reasonable timeframe, please contact your system administrator")
    • If OpenID, Gitea will redirect to IdP instead of prompt for password.
• User complete authentication challenge, which logs them in using existing functionality.

A good example of this would be https://accounts.zoho.com/signin. What do others think?

[pboguslawski]

I think a good first step to this would be to only show username/email field on login page for first render

In case of reverse proxy auth/header auth/certificate auth no login form is used and should not be rendered nor available.