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
