Re: git smart http + apache mod_auth_openidc

[Ralph Ewig <ralph.phd@protonmail.com>]

Quick follow up question: can the git client pass 
a token read from a cookie with a request? That 
would enable users to sign-in via a browser, store 
the cookie, and then use that as the access token 
to authenticate a git request.


On 10/16/2019 11:03 PM, Jeff King wrote:
> 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