cURL / Mailing Lists / curl-library / Single Mail


Re: OAuth 2.0 support (was Re: I want to close the feature window)

From: Yves Arrouye <>
Date: Mon, 11 Mar 2013 15:47:50 -0700

Please find attached an up to date patch.

> Can you tell us more about what the token is used for and what kind of
that is necessary? Is that token usually stored in a file using a
format? I'm not very knowledgable in oauth magic.

The token is sent by the authorization server and can be stored any way
the user wants. I picked a string/file interface for curl itself because
if a user has a token to interact with a service it is convenient to store
it in a file. Here is a sample token (I picked the JSONB representation
because it's easier to read):

  "access_token": "xuO8ExwBmJ",
  "token_type": "mac",
  "refresh_token": "uAiE3y9g0e",
  "expires_in": 360000,
  "mac_algorithm": "hmac-sha-256",

and here is another one (a bearer token, much simpler):

  "access_token": "JF0uHZ4Zbr",
  "token_type": "bearer",
  "refresh_token": "cnJ7Azbtlu",
  "expires_in": 3600

which can also be represented as:


Curl parses these tokens into a struct oauth2_token in order to set the
CURLOPT_OAUTH2_TOKEN in libcurl. Because there are slight differences
between URL encoded and WWW URL encoded I modified Curl_urlfmtdecode
appropriately. When moving the parsing into src (tool) I need access to
that. The attached patch resolves this by providing
curl_easy_unescape_form() in libcurl which is useful in general. All token
reading functions have been moved out of the library, leaving libcurl
users to do whatever they would like with their tokens.

Learn about GPT services and architectures on Confluence.

On 3/8/13 2:29 PM, "Daniel Stenberg" <> wrote:

>On Thu, 7 Mar 2013, Yves Arrouye wrote:
>please don't top-post!
>> No I didn't post a patch, I sent you a link to the clone I have on
>Can you please post your work as a patch (or patch series) here?
>> So I just moved the token reading code outside of lib. It depends on
>> Curl_urlfmtdecode for reading tokens that are in
>> application/x-www-form-urlencoded format (I modified that function as
>> of my patch to support both URL encoding and the form variant).
>> What would be best in curl?
>> 1. Keep the simple token parsing function as a courtesy to users in the
>> lib (but remove the one that reads from a file)?
>> 2. Have my own decoder in the token parsing code since it's now outside
>> the library? (Seems like a lot of duplication).
>> 3. Some other option I haven't thought about. Maybe add a
>> curl_easy_unescape_form that can be called by anybody, and rely on that?
>> You may deem this more generic and therefore more useful than the token
>> reading function.
>Can you tell us more about what the token is used for and what kind of
>that is necessary? Is that token usually stored in a file using a
>format? I'm not very knowledgable in oauth magic.
> /
>List admin:

List admin:

Received on 2013-03-11