Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Preconfigure Git Credential Manager as instance-wide OAuth application #25189

Closed
shyim opened this issue Jun 10, 2023 · 11 comments
Closed

Preconfigure Git Credential Manager as instance-wide OAuth application #25189

shyim opened this issue Jun 10, 2023 · 11 comments
Labels
proposal/accepted We have reviewed the proposal and agree that it should be implemented like that/at all. type/feature Completely new functionality. Can only be merged if feature freeze is not active. type/proposal The new feature has not been accepted yet but needs to be discussed first.
Milestone
1.21.0

Comments

@shyim
Copy link
Contributor

shyim commented Jun 10, 2023

Feature Description

It would be really nice if there would be a instance-wide OAuth application only for the purpose of using it with the Git Credential Manager or git-credential-oauth. This would allow Git authentication just work without passwords, personal access tokens or SSH keys.

The OAuth client details for both helpers are redirect URI http://127.0.0.1/, only the client-id needs to be same between all instances.

There is also a similar request to Gitlab: https://gitlab.com/gitlab-org/gitlab/-/issues/374172

Screenshots

No response
@shyim shyim added type/feature Completely new functionality. Can only be merged if feature freeze is not active. type/proposal The new feature has not been accepted yet but needs to be discussed first. labels Jun 10, 2023
@denyskon
Copy link
Member

denyskon commented Jul 2, 2023

@hickford You seem to be the author of git-credential-oauth. If we tried to integrate it into Gitea, would a pre-registered OAuth application be enough for it to work? Would we need to implement something else?

@hickford
Copy link
Contributor

hickford commented Jul 2, 2023 •
edited

@denyskon Two changes are necessary:

  1. In a migration (pseudocode), insert an OAuth2Application record for git-credential-oauth. The client id must be the same on all instances.
  2. So that git-credential-oauth can identify Gitea instances and select the appropriate configuration, change the 401 Unauthorized http header from Www-Authenticate: Basic realm="." to something like Www-Authenticate: Basic realm="Gitea"

@denyskon denyskon added the proposal/accepted We have reviewed the proposal and agree that it should be implemented like that/at all. label Jul 3, 2023
@hickford hickford mentioned this issue Jul 3, 2023
Closed
@hickford
Copy link
Contributor

hickford commented Jul 3, 2023 •
edited

@shyim @denyskon I sketched an implementation in #25653 but it has a problem: the OAuth2Application isn't created on first time install. Maybe there's a better alternative to using a migration. If you have any ideas how to fix, please have a go.

@denyskon
Copy link
Member

denyskon commented Jul 3, 2023

Thanks, I'll take a look tomorrow.

@hickford
Copy link
Contributor

hickford commented Jul 8, 2023 •
edited

An alternative approach could be to hard code the application in GetOAuth2ApplicationByClientID without database records. #25774

@hickford hickford mentioned this issue Jul 8, 2023
Closed
@hickford
Copy link
Contributor

hickford commented Jul 9, 2023

@shyim @denyskon #25653 working, ready for review

@hickford
Copy link
Contributor

hickford commented Jul 10, 2023 •
edited

Security wise, it would be prudent to fix #25061 and #25813 , because these would protect the preconfigured OAuth client from client impersonation, and limit its scope.

@denyskon denyskon mentioned this issue Aug 2, 2023
Merged
@hickford hickford mentioned this issue Aug 5, 2023
Closed
KN4CK3R pushed a commit that referenced this issue Aug 9, 2023
@denyskon @hickford @wxiaoguang
Pre-register OAuth2 applications for git credential helpers (#26291)
63ab92d 
This PR is an extended implementation of #25189 and builds upon the
proposal by @hickford in #25653, utilizing some ideas proposed
internally by @wxiaoguang.

Mainly, this PR consists of a mechanism to pre-register OAuth2
applications on startup, which can be enabled or disabled by modifying
the `[oauth2].DEFAULT_APPLICATIONS` parameter in app.ini. The OAuth2
applications registered this way are being marked as "locked" and
neither be deleted nor edited over UI to prevent confusing/unexpected
behavior. Instead, they're being removed if no longer enabled in config.


![grafik](https://github.com/go-gitea/gitea/assets/47871822/81a78b1c-4b68-40a7-9e99-c272ebb8f62e)

The implemented mechanism can also be used to pre-register other OAuth2
applications in the future, if wanted.

Co-authored-by: hickford <mirth.hickford@gmail.com>
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>

---------

Co-authored-by: M Hickford <mirth.hickford@gmail.com>
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
@lunny
Copy link
Member

lunny commented Aug 10, 2023

This has been resolved by #26291

@lunny lunny closed this as completed Aug 10, 2023
@lunny lunny added this to the 1.21.0 milestone Aug 10, 2023
@hickford
Copy link
Contributor

hickford commented Aug 10, 2023 •
edited

Released https://github.com/hickford/git-credential-oauth/releases/tag/v0.10.0 with universal Gitea support

Tested with https://try.gitea.io/

Requires both:

  • Gitea 1.21 or greater
  • Git 2.41 or greater

@denyskon
Copy link
Member

@hickford Thanks for that quick implementation! Is anything needed from Gitea's side to also make it happen for Git Credential Manager?

@hickford
Copy link
Contributor

Is anything needed from Gitea's side to also make it happen for Git Credential Manager?

@denyskon I don't think so. The implementation would be similar to hickford/git-credential-oauth@79a00fb

@aotongarcia aotongarcia mentioned this issue Sep 10, 2023
Open
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 25, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
proposal/accepted We have reviewed the proposal and agree that it should be implemented like that/at all. type/feature Completely new functionality. Can only be merged if feature freeze is not active. type/proposal The new feature has not been accepted yet but needs to be discussed first.
Projects
None yet
Milestone
1.21.0
4 participants
@lunny @hickford @shyim @denyskon