From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-2.5 required=3.0 tests=AWL,BAYES_00,BODY_8BITS, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI,SPF_HELO_NONE,SPF_NONE shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by dcvr.yhbt.net (Postfix) with ESMTP id 2291D1F4C0 for ; Thu, 17 Oct 2019 14:21:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2394967AbfJQOV0 (ORCPT ); Thu, 17 Oct 2019 10:21:26 -0400 Received: from mail2.protonmail.ch ([185.70.40.22]:44801 "EHLO mail2.protonmail.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731664AbfJQOVZ (ORCPT ); Thu, 17 Oct 2019 10:21:25 -0400 Date: Thu, 17 Oct 2019 14:21:17 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1571322082; bh=7yTpdQKIoNR0IPouWBsALqdxef4GHogYr7U099KsX+M=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=hdBsvfIR2ajBc6qxib6NJUToaIt2Y+9PgRewgFq4EnB8hCcm7NKMX6aOxJ35Zl/v6 GifOod2TqTiFOdYNP7HDxbQGz4UUEoE/LLZvBuMrgOx1qSSfxIHYhuxnHcDnTgAACr bE3sAXFwudPDWLdd81Hw55wlIiN5IKODWtmYgvmA= To: Jeff King From: Ralph Ewig Cc: "brian m. carlson" , git@vger.kernel.org Reply-To: Ralph Ewig Subject: Re: git smart http + apache mod_auth_openidc Message-ID: <8d06b57a-8d02-1d05-fb12-00a01d776200@protonmail.com> In-Reply-To: <20191017060322.GA10373@sigill.intra.peff.net> References: <4eb22ffc-77a1-4cd7-2277-bdc57d31186b@protonmail.com> <20191016233319.3rhmekasi5csytyl@camp.crustytoothpaste.net> <1320f616-ddcc-0eed-22f2-e28eb0abf039@protonmail.com> <20191017060322.GA10373@sigill.intra.peff.net> Feedback-ID: JbhSByWnCQwiafGbFv64IeMW95YrXE9PqRMglI51uN_uNsIp7h5EnYZeviw8UgH0DtxilqFslLTcJ61CqL2H5Q==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Interesting ... I have not looked at access tokens=20 before, but did find some documentation online=20 that describes how Azure AD Jason Web Tokens can=20 be used to authenticate a headless API=20 (https://docs.microsoft.com/en-us/azure/active-directory/develop/id-tokens)= ,=20 This seems to be a fit in this scenario, but=C2=A0 is=20 admittedly a bit deeper into the weeds than I'm=20 familiar with. I'll keep digging in to see if I=20 can find a solution along that route. Really=20 appreciate the pointer! Ralph 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. > >>>> =C2=A0=C2=A0=C2=A0 C:\Users\void>git clone --progress -v >>>> "https://git.xxx.xxx/WebApps.git" >>>> =C2=A0=C2=A0=C2=A0 Cloning into 'WebApps'... >>>> =C2=A0=C2=A0=C2=A0 fatal: unable to update url base from >>>> redirection: >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 asked for: >>>> https://git.xxx.xxx/WebApps.git/info/refs?service=3Dgit-upload-pack >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 redirect: >>>> https://login.microsoftonline.com/xxx/oauth2/authorize?response_type= =3Dcode&scope=3Dopenid&client_id=3Dxxx&state=3Dxxx&redirect_uri=3Dhttps%3A%= 2F%2Fgit.xxx.xxx%2Fredirect&nonce=3Dxxx > 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