I may not be able to send the patch until after New Year's. I did it at
work, and my company has a policy that says it needs to be reviewed
internally. Everybody's off right now, and me too soon.

The patch is basically structured as follows:

- oauth.[hc] defines a structure to hold the known OAuth 2 token types
(bearer and MAC) as well as functions to parse tokens. There is a built in
parser for a token in text/www-url-encoded form, and if configure finds
jsonsl (or if it's under deps on Windows and USE_JSONSL) then tokens in
application/json can also be parsed. The goal is to be able to make a cURL
request to a token endpoint and reuse the response in another cURL call. I
picked jsonsl after looking for a VERY brief time for a simple C json
tokenizer that I could understand in ten minutes or so, but any could

- http_oauth.[hc] provides for generating the Authorization header. It is
inspired by http_digest.[hc].

- I've added a setopt that takes a pointer to a struct curl_oauth2_token
to indicate that one wants to use OAuth 2. I picked the struct rather than
a string to parse so that one could build a token repository wherever one
wants and pass the tokens as needed. It should be easy to expose that
struct to language bindings such as PHP, Python, etc, though I have not
done so. This is a place where I'd need guidance on whether I did right
per cURL's spirit or not.

- When picking auth, libcurl will pick OAuth 2 as an option. It's ranked
above digest and basic but maybe that could be made dependent on the
security of the token too (e.g. Bearer is lowest, but MAC is highest). I
am not sure.

- tool_getparam.c, tool_operate.c, tool_help.c and their friends etc. have
been modified. In the tool, the configuration object takes a string, and
it is then parsed and if successfully parsed it is used in a call to
setopt. I wrote code that either takes a filename (including "-") or, with
a #ifdef, takes the token itself or an @filename like seen in other places
of cURL. I have some reservation about passing the token data (including
the secret) in the clear so that's off for now! A more paranoid
implementation may also balk at the user if the file is group and/or
world-readable, but I don't really like nannying people that way.

- m4/curl-confopts.m4 deals with the --enable-oauth2 option (default is
no) and also looks for JSONSL. In configure.ac I call the new macro and
report on whether OAuth 2 is enabled as well as which token encodings are
supported.

- Similar changes have been made to the winbuild Makefiles, and options
added there are documented in the README.

- docs/curl.1 is updated to document the --oauth2 <file> option as well as
the companion --http-mac-ext <string> (which is how I provide for the
"ext" parameter for HTTP MAC).

That's it in a nutshell.

YA
­­­
Learn about GPT services and architectures on Confluence.
<http://confluence/display/GPT/GPT+Architecture>

On 12/21/12 11:35 AM, "Oscar Koeroo" <okoeroo_at_nikhef.nl> wrote:

>On 21-12-12 19:32, Yves Arrouye wrote:
>> I have so far a full patch off HEAD for OAuth 2 which supports the
>> generation of a proper Authorization: header for OAuth 2 from a token.
>> Bearer (RFC 6750) and the HTTP MAC (draft-ietf-oauth-v2-http-mac-02) are
>> both supported. The patch has been tested on OS X, Linux, Windows using
>> nmake as well as MingW32. We are using it to interact with our newly
>> designed authentication service (so it's also been tested against a
>> different implementation of HTTP MAC), which is why I cared mostly about
>> generating proper authorization headers, and not about three legged etc.
>> But it's a solid start.
>>
>> I was actually going to ask if there was interest in having me
>>contribute
>> this to cURL. The patch does NOT enable OAUth2 by default (but I can
>> change that, and maybe not enable HTTP MAC by default as it's an I-D and
>> not an RFC; all those things can be discussed).
>>
>> If there is interest, then I'D love to discuss some of my decisions
>>(e.g.
>> take a token file on curl's command line rather than the token data
>>itself
>> so as not to expose it on the command line, though I also have #ifdef'ed
>> support for that) as well as make sure some of them are the right way to
>> integrate with cURL and libcurl (e.g. setting the token through libcurl,
>> where a file did not seem appropriate).
>>
>> Refresh tokens are not supported yet because it's something I'D rather
>> discuss with the list before picking some design over some other.
>>
>> YA
>
>This is interesting. Do you have a more detailed write up, or even the
>source code/patch?
>
>
> Oscar
>
>

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2012-12-21