Re: git smart http + apache mod_auth_openidc

[Jeff King <peff@peff.net>]

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.

> >>       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