On Mon, Jun 18, 2018 at 08:53:27AM -0700, Junio C Hamano wrote: > > Yeah, that will work for some cases. A few places it might not: > > > > - some people may want to provide this only in response to a 401 > > > > - some tokens may need to be refreshed, which would require interacting > > with a credential helper to do the rest of the oauth conversation > > > > - there's no good way to hide your token in secure storage (versus > > sticking it on the command-line or in a config file). > > And all of these three are what you get for free by building on the > credential helper framework, after extending it a bit so that the > filled credential structure can tell the http code to show it to the > other side as a bearer token, not a password or password hash. The > helper is asked to supply the auth material only after 401, which > covers both the first and the second points, and then keeping the > auth material in-core (e.g. cache--daemon) would be more secure > which covers the third point. Am I following you correctly? Yes, exactly. Even if the credential protocol itself doesn't learn about this feature, even a config option for "treat password as token to send via bearer" would help. The "how" of sending the token isn't secret, just the token itself. So everything else can just pretend it's a password (it's a little funny because I think there isn't a matching username, but you could probably get by with an empty one). That's all just off the top of my head without digging back into the code, nor running any experiments, of course. There may be some gotchas. :) -Peff
