cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: Implementing OAuth support into curl?

From: Mischa Salle <mischa.salle_at_gmail.com>
Date: Sun, 23 Dec 2012 10:59:11 +0100

Hi Yves,

this is dertainly very interesting. Please keep us informed! For me in the
new year is fine...

Best regards,
Mischa

On Fri, Dec 21, 2012 at 9:30 PM, Yves Arrouye <yarrouye_at_expedia.com> wrote:

> 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
>

-- 
Maasstraat 162-III
1079 BK Amsterdam
The Netherlands
Tel. (+31/0)20-4043782

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