(Re-sending, this time without HTML) Hello! > On 14 Aug 2021, at 11:02 pm, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > > Hi, > > On Fri, 13 Aug 2021, lilinchao@xxxxxxxxxx wrote: > >>> On 8/11/2021 7:00 AM, lilinchao@xxxxxxxxxx wrote: >>>> Many websites support two-factor authentication(2FA) to log in, like Github, I wander if we can support it in application layer. >>>> When client clone something, they need input username and password, it is like a website login process. For security, we can >>>> enable 2FA during this process. >>> >>> Typically, this is handled at the credential helper layer, which >>> is a tool outside of the Git codebase that can more closely work >>> with such 2FA/MFA requirements. For example, GCM Core [1] supports >>> 2FA with GitHub, Azure DevOps, and BitBucket. >>> >>> [1] https://github.com/microsoft/Git-Credential-Manager-Core >>> >>> The mechanism is that Git attempts an operation and gets an error >>> code, so it asks for a credential from the helper. The helper >>> then communicates with the server to do whatever authentication >>> is required, including possibly performing multi-factor auth. >>> All of these details are hidden from Git, which is good. >>> >> Indeed, this is good, I've experienced this tool these days at WSL and Windows, >> but finally I hope these features can be supported by Git itself, and then the user end can easily configure it. > > The problem here is that 2FA is highly provider-specific. And that's why > Git itself refuses to implement it. Hence the credential helper layer. > > Ciao, > Johannes Johannes and Derrick are correct. Sadly, there is no standard “modern" authentication/authorization stack that Git could support in practice. You may think of OAuth2.0 as being a good choice, and you’d be right for the most part! However there are several shortcomings today. Plenty of vendors implement OAuth2 in different ways (technically they’re not following RFC 6749 [1]), or have extensions to the specification that end up being required for most use. At the same time there’s no standard discovery mechanism for the various required endpoints to avoid having the Git project “hardcode” this configuration for each provider - the Git project should be agnostic. OpenID Connect [2] extends OAuth2 with some useful things like endpoint discovery [3], but that is also optional to implement and still requires some server-side registration and administration (that is vendor specific). There’s also the question of user interaction. Often this is tied to specific, opinionated choices like: user agent (browser), operating system integrations, YubiKey or custom multi-factor authentication solutions (SMS? biometrics? OTP apps?). There may be more that Git can do to surface authN/Z challenges to a credential helper (such at Git Credential Manager [4]) that might help in making auth in a post-password world less painful. The project is open to contributions to any vendor or auth stack. [1] https://datatracker.ietf.org/doc/html/rfc6749 [2] https://openid.net/specs/openid-connect-core-1_0.html [3] https://openid.net/specs/openid-connect-discovery-1_0.html [4] https://aka.ms/gcmcore Thanks, Matthew
