Re: git smart http + apache mod_auth_openidc

From: Ralph Ewig <ralph.phd@protonmail.com>
Date: Oct 17, 2019, 14:21 UTC
Message-ID: <8d06b57a-8d02-1d05-fb12-00a01d776200@protonmail.com>
In-Reply-To: <20191017060322.GA10373@sigill.intra.peff.net>

Interesting ... I have not looked at access tokens before, but did find some documentation online that describes how Azure AD Jason Web Tokens can be used to authenticate a headless API (https://docs.microsoft.com/en-us/azure/active-directory/develop/id-tokens),

This seems to be a fit in this scenario, but is admittedly a bit deeper into the weeds than I'm familiar with. I'll keep digging in to see if I can find a solution along that route. Really appreciate the pointer!

Ralph

On 10/16/2019 11:03 PM, Jeff King wrote:

Show 45 quoted lines

> 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