[Summary] Improve auth source / login system #10882

New Issue

GiteaMirror · 2025-11-02T09:21:04-06:00

GiteaMirror commented

2025-11-02 09:21:04 -06:00

Originally created by @wxiaoguang on GitHub (May 20, 2023).

Feature Description

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

Including (but not only):

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

Originally created by @wxiaoguang on GitHub (May 20, 2023). ### Feature Description There are more and more requirements for a better login system. Including (but not only): * #1036 * #1143 * #13606 * #7633 * #18481 * #18466 * #21851 * #20242 * #21675 * #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_

GiteaMirror added the type/summary label 2025-11-02 09:21:05 -06:00

GiteaMirror commented

2025-11-02 09:21:05 -06:00

@pboguslawski commented on GitHub (May 20, 2023):

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.

@pboguslawski commented on GitHub (May 20, 2023): 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.

GiteaMirror commented

2025-11-02 09:21:05 -06:00

@jrjake commented on GitHub (Jul 9, 2023):

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?

@jrjake commented on GitHub (Jul 9, 2023): 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?

GiteaMirror commented

2025-11-02 09:21:06 -06:00

@pboguslawski commented on GitHub (Jul 10, 2023):

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.

@pboguslawski commented on GitHub (Jul 10, 2023): > 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.

GiteaMirror commented

2025-11-02 09:21:06 -06:00

@hramrach commented on GitHub (Aug 19, 2025):

Related: #23382 #24160 and perhaps 24359 (don't really understand this one, is Gitea suposed to be oauth2 provider in this case?)

@hramrach commented on GitHub (Aug 19, 2025): Related: #23382 #24160 and perhaps 24359 (don't really understand this one, is Gitea suposed to be oauth2 provider in this case?)

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#10882