> Future work > =========== > > In the future we can further expand the protocol to allow credential helpers > decide the best authentication scheme. Today credential helpers are still > only expected to return a username/password pair to Git, meaning the other > authentication schemes that may be offered still need challenge responses > sent via a Basic Authorization header. The changes outlined above still > permit helpers to select and configure an available authentication mode, but > require the remote for example to unpack a bearer token from a basic > challenge. > > More careful consideration is required in the handling of custom > authentication schemes which may not have a username, or may require > arbitrary additional request header values be set. > > For example imagine a new "FooBar" authentication scheme that is surfaced in > the following response: > > HTTP/1.1 401 Unauthorized > WWW-Authenticate: FooBar realm="login.example", algs="ES256 PS256" > > > With support for arbitrary authentication schemes, Git would call credential > helpers with the following over standard input: > > protocol=https > host=example.com > wwwauth[]=FooBar realm="login.example", algs="ES256 PS256", nonce="abc123" > > > And then an enlightened credential helper could return over standard output: > > protocol=https > host=example.com > authtype=FooBar > username=bob@xxxxxxxxxxxxxx > password=<FooBar credential> > header[]=X-FooBar: 12345 > header[]=X-FooBar-Alt: ABCDEF > > > Git would be expected to attach this authorization header to the next > request: > > GET /info/refs?service=git-upload-pack HTTP/1.1 > Host: git.example > Git-Protocol: version=2 > Authorization: FooBar <FooBar credential> > X-FooBar: 12345 > X-FooBar-Alt: ABCDEF Interesting! Can you tell us more about how you hope to use this at GitHub? Could this be used for OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer (DPoP)? https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop (some of the fields in your example look familiar). Challenge responses are typically short lived [1]. What happens if a storage helper is configured before a challenge-response helper? We want to maintain composability of helpers. [credential] helper = storage # eg. cache or osxkeychain helper = challenge-response # eg. oauth-dpop Storage may return an expired challenge response stored earlier. This could be avoided by introducing an expiry attribute to the credential protocol. https://lore.kernel.org/git/pull.1443.git.git.1674914650588.gitgitgadget@xxxxxxxxx/T/#u A monolithic helper configured alone doesn't have this problem -- it knows which parts of its output to store or discard. Declaration of interest: I maintain a credential-generating OAuth helper composable with any storage helper. https://github.com/hickford/git-credential-oauth [1] https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop#section-8
