Apr 2, 2013 at 6:07 PM
So I've been approached by some folks interested in using Git-Credential-Winstore to make an OAuth authentication model work with Git. Basically, the flow would be something like the following.
When the helper is given "http://sub.example.com/repo
" as the URL and it doesn't have a cached credential for "sub.example.com", it does the following:
- Performs a GET on "http://sub.example.com/_gitauth" 
- If we get any non-successful result, we continue with the usual password flow
- If the server returns a result, we expect something in this form:
... other auth flows? ...
- Assuming the JSON is well-formed and a supported auth-type can be found, the helper performs that auth flow and caches the necessary credential.
- The JSON blob indicates how the token should be provided to Git, which will perform a standard Basic-auth flow using the token as the username and/or the password (depending on the service).
The auth-type we'd start with is OAuth2 Implicit, which involves popping up a browser and reading data from that browser window containing an Access Token. The JSON blob would indicate how the token is used. If "defaultUsername" is provided (even
if it's empty), then that literal value is used as the user name and the token is used as the password. If "defaultPassword" is provided (even if it's empty), then the token is used as the user name and that literal is used as the password. If neither
are specified, both get the token, if both are specified, we error out.
- Does OAuth for Git make sense? It's definitely interesting that users could revoke access. I think it makes a lot of sense
- Is it OK for the credential helper to be pinging the host on the first time you try to get creds for a particular host? You are doing a pull/push so network traffic would be expected.
- Do we need to allow the host to configure where the token goes? Is it better to just specify where it should go (i.e. always in the user name with a blank password or vice-versa)?
- We'll need to try to detect non-interactive sessions so we can error out instead of trying to pop a browser in some non-interactive session...
We definitely need to be careful here, since we may well be creating a de-facto Git OAuth spec here... I'd appreciate as much feedback as possible so we can get it right.
 Exact name TBD, I'm not sure I like that name, but it's a start.
Apr 2, 2013 at 6:23 PM
Edited Apr 2, 2013 at 6:23 PM
Note: GitHub already supports the UserName/OAuthToken pair. Might be worth standardizing on that as the way the token gets returned by the helper.