Re: git smart http + apache mod_auth_openidc

From: Jeff King <peff@peff.net>
Date: Oct 17, 2019, 06:03 UTC
Message-ID: <20191017060322.GA10373@sigill.intra.peff.net>
In-Reply-To: <1320f616-ddcc-0eed-22f2-e28eb0abf039@protonmail.com>

On Thu, Oct 17, 2019 at 03:00:58AM +0000, Ralph Ewig wrote:

> Thanks for the reply. I was hoping the Git GUI 
> might be able to handle the OpenID authentication 
> flow, but it makes sense that it would be 
> inconsistent with other git clients.

I don't think we'd ever do the full flow, but it might be that it's possible to use a token generated by the flow in a separate browser session. This is easy to do if you can provide the token to the server in place of a password. E.g., if you use 2FA on GitHub, you can generate a limited token that allows you to connect for Git operations.

You can also use time-limited tokens and feed them from a custom credential helper, which does the full authentication flow from a web browser. I think Google does (or did) have such a thing internally, but I don't think any part of it was made public (it was discussed on the list a couple times in the early days of credential helpers).

That would still have to end up with a token "password" to send over basic auth, I think. There was some discussion a while back of letting credential helpers pass back content for HTTP "Authorization" headers, but I don't think anything was ever merged.

Show 9 quoted lines

> >>       C:\Users\void>git clone --progress -v
> >> "https://git.xxx.xxx/WebApps.git"
> >>       Cloning into 'WebApps'...
> >>       fatal: unable to update url base from
> >> redirection:
> >>         asked for:
> >> https://git.xxx.xxx/WebApps.git/info/refs?service=git-upload-pack
> >>          redirect:
> >> https://login.microsoftonline.com/xxx/oauth2/authorize?response_type=code&scope=openid&client_id=xxx&state=xxx&redirect_uri=https%3A%2F%2Fgit.xxx.xxx%2Fredirect&nonce=xxx

You're running into one other complexity here, which is that we don't allow cross-server redirects during the initial conversation. So even if you did have an auth flow where we could somehow provide all the information via Git, we'd still be unhappy about bouncing between multiple servers.

Mostly that's there to avoid leaking credentials. We only have one notion of "the username and password we're using" for a given fetch, so we want to avoid leaking it if we're redirected to another server. But obviously Git _could_ be smarter there, if this was the only blocker remaining (but from my understanding of OpenID, it's not).

-Peff