Re: [PATCH v7 00/12] Enhance credential helper protocol to include auth headers

[Matthew John Cheetham <mjcheetham@outlook.com>]

On 2023-01-28 06:28, M Hickford wrote:

>> 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@id.example.com
>> 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). 

This would be exactly the sort of thing that this would enable. DPoP is one
example where the correct auth response requires more than just a username/
password pair in the Authorization header. We should also be returning
standard headers like 'Authenticate-Info' on 200 OK responses along side the
'store' calls to helpers; they could contain nonces or other important auth
information.

My end goal here is to extend the credential helper protocol such that that
helpers can see more of the initial request challenge, and then modify the
subsequent request directly, or configure and let curl handle it (the latter
part not present in this iteration).

One thing not called out in this doc is really the need for some capability
advertisement between Git and helpers - for example if the curl version in
use supports CURLOPT_XOAUTH2_BEARER for bearer tokens.

> 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

I think really this sort of thing is where the credential helper protocol
isn't designed for credential-generating helpers in mind, but only simple
storage-only helpers. There is no affinity between get/erase/store commands
meaning one helper may return a credential for another helper to store it.
Not sure if this was ever the intention, over just the need to consult a
list of helpers for a stored credential.

> 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@gmail.com/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