aboutsummaryrefslogtreecommitdiffstats
path: root/routers/web/auth
Commit message (Collapse)AuthorAgeFilesLines
* Support for email addresses containing uppercase characters when activating ↵Giteabot2024-12-272-3/+3
| | | | | | | | | | user account (#32998) (#33001) Backport #32998 by Zettat123 Fix #32807 Co-authored-by: Zettat123 <zettat123@gmail.com> Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
* Allow to disable the password-based login (sign-in) form (#32687)wxiaoguang2024-12-021-31/+17
| | | | | | | | | | | | | | Usually enterprise/organization users would like to only allow OAuth2 login. This PR adds a new config option to disable the password-based login form. It is a simple and clear approach and won't block the future login-system refactoring works. Fix a TODO in #24821 Replace #21851 Close #7633 , close #13606
* Fix: passkey login not working anymore (#32623)hiifong2024-11-261-5/+16
| | | | | | | Quick fix #32595, use authenticator auth flags to login --------- Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
* Enhancing Gitea OAuth2 Provider with Granular Scopes for Resource Access ↵Marcell Mars2024-11-221-1/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (#32573) Resolve #31609 This PR was initiated following my personal research to find the lightest possible Single Sign-On solution for self-hosted setups. The existing solutions often seemed too enterprise-oriented, involving many moving parts and services, demanding significant resources while promising planetary-scale capabilities. Others were adequate in supporting basic OAuth2 flows but lacked proper user management features, such as a change password UI. Gitea hits the sweet spot for me, provided it supports more granular access permissions for resources under users who accept the OAuth2 application. This PR aims to introduce granularity in handling user resources as nonintrusively and simply as possible. It allows third parties to inform users about their intent to not ask for the full access and instead request a specific, reduced scope. If the provided scopes are **only** the typical ones for OIDC/OAuth2—`openid`, `profile`, `email`, and `groups`—everything remains unchanged (currently full access to user's resources). Additionally, this PR supports processing scopes already introduced with [personal tokens](https://docs.gitea.com/development/oauth2-provider#scopes) (e.g. `read:user`, `write:issue`, `read:group`, `write:repository`...) Personal tokens define scopes around specific resources: user info, repositories, issues, packages, organizations, notifications, miscellaneous, admin, and activitypub, with access delineated by read and/or write permissions. The initial case I wanted to address was to have Gitea act as an OAuth2 Identity Provider. To achieve that, with this PR, I would only add `openid public-only` to provide access token to the third party to authenticate the Gitea's user but no further access to the API and users resources. Another example: if a third party wanted to interact solely with Issues, it would need to add `read:user` (for authorization) and `read:issue`/`write:issue` to manage Issues. My approach is based on my understanding of how scopes can be utilized, supported by examples like [Sample Use Cases: Scopes and Claims](https://auth0.com/docs/get-started/apis/scopes/sample-use-cases-scopes-and-claims) on auth0.com. I renamed `CheckOAuthAccessToken` to `GetOAuthAccessTokenScopeAndUserID` so now it returns AccessTokenScope and user's ID. In the case of additional scopes in `userIDFromToken` the default `all` would be reduced to whatever was asked via those scopes. The main difference is the opportunity to reduce the permissions from `all`, as is currently the case, to what is provided by the additional scopes described above. Screenshots: ![Screenshot_20241121_121405](https://github.com/user-attachments/assets/29deaed7-4333-4b02-8898-b822e6f2463e) ![Screenshot_20241121_120211](https://github.com/user-attachments/assets/7a4a4ef7-409c-4116-9d5f-2fe00eb37167) ![Screenshot_20241121_120119](https://github.com/user-attachments/assets/aa52c1a2-212d-4e64-bcdf-7122cee49eb6) ![Screenshot_20241121_120018](https://github.com/user-attachments/assets/9eac318c-e381-4ea9-9e2c-3a3f60319e47) --------- Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
* Use user.FullName in Oauth2 id_token response (#32542)Baltazár Radics2024-11-182-21/+2
| | | | This makes `/login/oauth/authorize` behave the same way as the `/login/oauth/userinfo` endpoint.
* Use better name for userinfo structure (#32544)Lunny Xiao2024-11-181-11/+11
|
* Fix oauth2 error handle not return immediately (#32514)Lunny Xiao2024-11-151-0/+2
|
* Fix LFS route mock, realm, middleware names (#32488)wxiaoguang2024-11-131-2/+2
| | | | | | | | | | 1. move "internal-lfs" route mock to "common-lfs" 2. fine tune tests 3. fix "realm" strings, according to RFC: https://datatracker.ietf.org/doc/html/rfc2617: * realm = "realm" "=" realm-value * realm-value = quoted-string 4. clarify some names of the middlewares, rename `ignXxx` to `optXxx` to match `reqXxx`, and rename ambiguous `requireSignIn` to `reqGitSignIn`
* Refactor CSRF token (#32216)wxiaoguang2024-10-102-5/+7
|
* Make oauth2 code clear. Move oauth2 provider code to their own ↵Lunny Xiao2024-10-023-850/+672
| | | | | | packages/files (#32148) Fix #30266 Replace #31533
* Failed authentications are logged to level Warning (#32016)Daniel2024-09-111-4/+4
| | | | | | | PR for issue #31968 Replaces PR #31983 to comply with gitea's error definition Failed authentications are now logged to level `Warning` instead of `Info`.
* Save initial signup information for users to aid in spam prevention (#31852)techknowlogick2024-09-091-1/+5
| | | | | | | | | | | | | | This will allow instance admins to view signup pattern patterns for public instances. It is modelled after discourse, mastodon, and MediaWiki's approaches. Note: This has privacy implications, but as the above-stated open-source projects take this approach, especially MediaWiki, which I have no doubt looked into this thoroughly, it is likely okay for us, too. However, I would be appreciative of any feedback on how this could be improved. --------- Co-authored-by: Giteabot <teabot@gitea.io>
* Remove urls from translations (#31950)Denys Konovalov2024-09-022-3/+3
| | | | | | | Part of #27700 Removes all URLs from translation strings to easy up changing them in the future and to exclude people injecting malicious URLs through translations. First measure as long as #24402 is out of scope.
* add CfTurnstileSitekey context data to all captcha templates (#31874)Rowan Bohde2024-08-192-0/+4
| | | | | | | | In the OpenID flows, the "CfTurnstileSitekey" wasn't populated, which caused those flows to fail if using Turnstile as the Captcha implementation. This adds the missing context variables, allowing Turnstile to be used in the OpenID flows.
* OIDC: case-insensitive comparison for auth scheme `Basic` (#31706)Shivaram Lingamneni2024-07-261-2/+2
| | | | | | | | | | | | | | @kylef pointed out on https://github.com/go-gitea/gitea/pull/31632 that [RFC7617](https://www.rfc-editor.org/rfc/rfc7617.html#section-2) mandates case-insensitive comparison of the scheme field `Basic`. #31632 copied a case-sensitive comparison from https://github.com/go-gitea/gitea/pull/6293. This PR fixes both comparisons. The issue only affects OIDC, since the implementation for normal Gitea endpoints is already correct: https://github.com/go-gitea/gitea/blob/930ca92d7ce80e8b0bdaf92e495026baf2a1d419/services/auth/basic.go#L55-L58
* add `username` to OIDC introspection response (#31688)Shivaram Lingamneni2024-07-251-2/+6
| | | | | | | | | This field is specified as optional here: https://datatracker.ietf.org/doc/html/rfc7662#section-2.2 It's used by some OIDC integrations, e.g. https://emersion.fr/blog/2022/irc-and-oauth2/ Co-authored-by: Giteabot <teabot@gitea.io>
* fix OIDC introspection authentication (#31632)Shivaram Lingamneni2024-07-231-18/+28
| | | | | | | | | | | | | | | | | | | | | See discussion on #31561 for some background. The introspect endpoint was using the OIDC token itself for authentication. This fixes it to use basic authentication with the client ID and secret instead: * Applications with a valid client ID and secret should be able to successfully introspect an invalid token, receiving a 200 response with JSON data that indicates the token is invalid * Requests with an invalid client ID and secret should not be able to introspect, even if the token itself is valid Unlike #31561 (which just future-proofed the current behavior against future changes to `DISABLE_QUERY_AUTH_TOKEN`), this is a potential compatibility break (some introspection requests without valid client IDs that would previously succeed will now fail). Affected deployments must begin sending a valid HTTP basic authentication header with their introspection requests, with the username set to a valid client ID and the password set to the corresponding client secret.
* add skip secondary authorization option for public oauth2 clients (#31454)Denys Konovalov2024-07-191-3/+3
|
* allow synchronizing user status from OAuth2 login providers (#31572)Rowan Bohde2024-07-162-38/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This leverages the existing `sync_external_users` cron job to synchronize the `IsActive` flag on users who use an OAuth2 provider set to synchronize. This synchronization is done by checking for expired access tokens, and using the stored refresh token to request a new access token. If the response back from the OAuth2 provider is the `invalid_grant` error code, the user is marked as inactive. However, the user is able to reactivate their account by logging in the web browser through their OAuth2 flow. Also changed to support this is that a linked `ExternalLoginUser` is always created upon a login or signup via OAuth2. ### Notes on updating permissions Ideally, we would also refresh permissions from the configured OAuth provider (e.g., admin, restricted and group mappings) to match the implementation of LDAP. However, the OAuth library used for this `goth`, doesn't seem to support issuing a session via refresh tokens. The interface provides a [`RefreshToken` method](https://github.com/markbates/goth/blob/master/provider.go#L20), but the returned `oauth.Token` doesn't implement the `goth.Session` we would need to call `FetchUser`. Due to specific implementations, we would need to build a compatibility function for every provider, since they cast to concrete types (e.g. [Azure](https://github.com/markbates/goth/blob/master/providers/azureadv2/azureadv2.go#L132)) --------- Co-authored-by: Kyle D <kdumontnu@gmail.com>
* Add Passkey login support (#31504)Anbraten2024-06-291-0/+99
| | | | | | | | | | | | | | | | closes #22015 After adding a passkey, you can now simply login with it directly by clicking `Sign in with a passkey`. ![Screenshot from 2024-06-26 12-18-17](https://github.com/go-gitea/gitea/assets/6918444/079013c0-ed70-481c-8497-4427344bcdfc) Note for testing. You need to run gitea using `https` to get the full passkeys experience. --------- Co-authored-by: silverwind <me@silverwind.io>
* Refactor names (#31405)wxiaoguang2024-06-192-3/+3
| | | | | | | This PR only does "renaming": * `Route` should be `Router` (and chi router is also called "router") * `Params` should be `PathParam` (to distingush it from URL query param, and to match `FormString`) * Use lower case for private functions to avoid exposing or abusing
* Add missed return after `ctx.ServerError` (#31130)Lunny Xiao2024-05-281-0/+1
|
* use existing oauth grant for public client (#31015)Denys Konovalov2024-05-211-2/+17
| | | | | | | | | | Do not try to create a new authorization grant when one exists already, thus preventing a DB-related authorization issue. Fix https://github.com/go-gitea/gitea/pull/30790#issuecomment-2118812426 --------- Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
* Return `access_denied` error when an OAuth2 request is denied (#30974)Zettat1232024-05-201-0/+10
| | | | | | | | | | | | | | According to [RFC 6749](https://datatracker.ietf.org/doc/html/rfc6749#section-4.1.2.1), when the resource owner or authorization server denied an request, an `access_denied` error should be returned. But currently in this case Gitea does not return any error. For example, if the user clicks "Cancel" here, an `access_denied` error should be returned. <img width="360px" src="https://github.com/go-gitea/gitea/assets/15528715/be31c09b-4c0a-4701-b7a4-f54b8fe3a6c5" />
* Refactor AppURL usage (#30885)wxiaoguang2024-05-071-1/+1
| | | | | | | | Fix #30883 Fix #29591 --------- Co-authored-by: KN4CK3R <admin@oldschoolhack.me>
* Prevent automatic OAuth grants for public clients (#30790)Archer2024-05-021-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | This commit forces the resource owner (user) to always approve OAuth 2.0 authorization requests if the client is public (e.g. native applications). As detailed in [RFC 6749 Section 10.2](https://www.rfc-editor.org/rfc/rfc6749.html#section-10.2), > The authorization server SHOULD NOT process repeated authorization requests automatically (without active resource owner interaction) without authenticating the client or relying on other measures to ensure that the repeated request comes from the original client and not an impersonator. With the implementation prior to this patch, attackers with access to the redirect URI (e.g., the loopback interface for `git-credential-oauth`) can get access to the user account without any user interaction if they can redirect the user to the `/login/oauth/authorize` endpoint somehow (e.g., with `xdg-open` on Linux). Fixes #25061. Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
* Improve oauth2 client "preferred username field" logic and the error ↵wxiaoguang2024-04-254-28/+81
| | | | | | | | | | | | | handling (#30622) Follow #30454 And fix #24957 When using "preferred_username", if no such field, `extractUserNameFromOAuth2` (old `getUserName`) shouldn't return an error. All other USERNAME options do not return such error. And fine tune some logic and error messages, make code more stable and more friendly to end users.
* Allow `preferred_username` as username source for OIDC (#30454)SimonErm2024-04-161-0/+7
| | | | | | This PR adds the preferred_username claim as a possible username source for the oauth2_client. Closes #21518
* Clean up log messages (#30313)wxiaoguang2024-04-071-2/+0
| | | | | | `log.Xxx("%v")` is not ideal, this PR adds necessary context messages. Remove some unnecessary logs. Co-authored-by: Giteabot <teabot@gitea.io>
* Refactor external URL detection (#29973)wxiaoguang2024-03-222-4/+3
| | | | Follow #29960, `IsExternalURL` is not needed anymore. Add some tests for `RedirectToCurrentSite`
* Refactor URL detection (#29960)wxiaoguang2024-03-213-5/+5
| | | "Redirect" functions should only redirect if the target is for current Gitea site.
* Make "/user/login" page redirect if the current user has signed in (#29583)wxiaoguang2024-03-052-10/+63
| | | | Fix #29582 and maybe more. Maybe fix #29116
* remove util.OptionalBool and related functions (#29513)65432024-03-021-4/+4
| | | | | | and migrate affected code _last refactoring bits to replace **util.OptionalBool** with **optional.Option[bool]**_
* Allow to change primary email before account activation (#29412)wxiaoguang2024-02-271-3/+28
|
* Move context from modules to services (#29440)Lunny Xiao2024-02-277-7/+7
| | | | | | | | | | | | | | | Since `modules/context` has to depend on `models` and many other packages, it should be moved from `modules/context` to `services/context` according to design principles. There is no logic code change on this PR, only move packages. - Move `code.gitea.io/gitea/modules/context` to `code.gitea.io/gitea/services/context` - Move `code.gitea.io/gitea/modules/contexttest` to `code.gitea.io/gitea/services/contexttest` because of depending on context - Move `code.gitea.io/gitea/modules/upload` to `code.gitea.io/gitea/services/context/upload` because of depending on context
* Refactor "user/active" related logic (#29390)wxiaoguang2024-02-251-59/+66
| | | | | And add more tests. Remove a lot of fragile "if" blocks. The old logic is kept as-is.
* Revert "Support SAML authentication (#25165)" (#29358)65432024-02-245-237/+39
| | | | | | | | | | This reverts #25165 (5bb8d1924d77c675467694de26697b876d709a17), as there was a chance some important reviews got missed. so after reverting this patch it will be resubmitted for reviewing again https://github.com/go-gitea/gitea/pull/25165#issuecomment-1960670242 temporary Open #5512 again
* Start to migrate from `util.OptionalBool` to `optional.Option[bool]` (#29329)65432024-02-231-1/+1
| | | just create transition helper and migrate two structs
* Support SAML authentication (#25165)techknowlogick2024-02-235-39/+237
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Closes https://github.com/go-gitea/gitea/issues/5512 This PR adds basic SAML support - Adds SAML 2.0 as an auth source - Adds SAML configuration documentation - Adds integration test: - Use bare-bones SAML IdP to test protocol flow and test account is linked successfully (only runs on Postgres by default) - Adds documentation for configuring and running SAML integration test locally Future PRs: - Support group mapping - Support auto-registration (account linking) Co-Authored-By: @jackHay22 --------- Co-authored-by: jackHay22 <jack@allspice.io> Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com> Co-authored-by: KN4CK3R <admin@oldschoolhack.me> Co-authored-by: wxiaoguang <wxiaoguang@gmail.com> Co-authored-by: Jason Song <i@wolfogre.com> Co-authored-by: morphelinho <morphelinho@users.noreply.github.com> Co-authored-by: Zettat123 <zettat123@gmail.com> Co-authored-by: Yarden Shoham <git@yardenshoham.com> Co-authored-by: 6543 <6543@obermui.de> Co-authored-by: silverwind <me@silverwind.io>
* Remove unnecessary "Str2html" modifier from templates (#29319)wxiaoguang2024-02-221-3/+4
| | | Follow #29165
* Do not use `ctx.Doer` when reset password (#29289)Jason Song2024-02-211-1/+1
| | | | | Fix #29278. Caused by a small typo in #28733
* Refactor more code in templates (#29236)wxiaoguang2024-02-181-9/+1
| | | | | | | | Follow #29165. * Introduce JSONTemplate to help to render JSON templates * Introduce JSEscapeSafe for templates. Now only use `{{ ... | JSEscape}}` instead of `{{ ... | JSEscape | Safe}}` * Simplify "UserLocationMapURL" useage
* Refactor locale&string&template related code (#29165)wxiaoguang2024-02-141-1/+1
| | | | | | Clarify when "string" should be used (and be escaped), and when "template.HTML" should be used (no need to escape) And help PRs like #29059 , to render the error messages correctly.
* Unify user update methods (#28733)KN4CK3R2024-02-043-113/+90
| | | | | | | | | | | Fixes #28660 Fixes an admin api bug related to `user.LoginSource` Fixed `/user/emails` response not identical to GitHub api This PR unifies the user update methods. The goal is to keep the logic only at one place (having audit logs in mind). For example, do the password checks only in one method not everywhere a password is updated. After that PR is merged, the user creation should be next.
* Normalize oauth email username (#28561)Kyle D2024-01-033-6/+15
|
* Avoid cycle-redirecting user/login page (#28636)wxiaoguang2023-12-301-5/+5
| | | | Fix #28231, and remove some unused code. The `db.HasEngine` doesn't seem useful because the db engine is always initialized before web route.
* Always enable caches (#28527)Lunny Xiao2023-12-192-15/+9
| | | | | | | | | Nowadays, cache will be used on almost everywhere of Gitea and it cannot be disabled, otherwise some features will become unaviable. Then I think we can just remove the option for cache enable. That means cache cannot be disabled. But of course, we can still use cache configuration to set how should Gitea use the cache.
* Refactor Find Sources and fix bug when view a user who belongs to an ↵Lunny Xiao2023-11-031-8/+4
| | | | | | | | | | | | unactive auth source (#27798) The steps to reproduce it. First, create a new oauth2 source. Then, a user login with this oauth2 source. Disable the oauth2 source. Visit users -> settings -> security, 500 will be displayed. This is because this page only load active Oauth2 sources but not all Oauth2 sources.
* Final round of `db.DefaultContext` refactor (#27587)JakobDev2023-10-143-11/+11
| | | Last part of #27065
* Enhanced auth token / remember me (#27606)KN4CK3R2023-10-144-48/+44
| | | | | | | | | | | | | | | | | Closes #27455 > The mechanism responsible for long-term authentication (the 'remember me' cookie) uses a weak construction technique. It will hash the user's hashed password and the rands value; it will then call the secure cookie code, which will encrypt the user's name with the computed hash. If one were able to dump the database, they could extract those two values to rebuild that cookie and impersonate a user. That vulnerability exists from the date the dump was obtained until a user changed their password. > > To fix this security issue, the cookie could be created and verified using a different technique such as the one explained at https://paragonie.com/blog/2015/04/secure-authentication-php-with-long-term-persistence#secure-remember-me-cookies. The PR removes the now obsolete setting `COOKIE_USERNAME`.
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-15 10:39:17 +0000