4

I'm using Jon Crosby's open source Objective-C OAuth library http://code.google.com/p/oauthconsumer/ for some basic http authentication that does not deal with tokens, only consumer key and consumer secret. My code works great for GET, GET with parameters in the URL, and POST. When I issue a POST request that has parameters in the URL, though, the request fails authorization. I'm trying to figure out why.

The server is using Apache Commons OAuth, so I'd like to compare my base string with that library. Here's a contrived example and the base string and signature produced by my library. Can anyone see what the problem is?

consumer key:    abcdef
consumer secret: ghijkl
POST request:    http://emptyrandomhost.com/a/uriwith/params?interesting=foo&prolific=bar
my base string:  POST&http%3A%2F%2Femptyrandomhost.com%2Fa%2Furiwith%2Fparams&interesting%3Dfoo%26oauth_consumer_key%3Dabcdef%26oauth_nonce%3D1%26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp%3D2%26oauth_version%3D1.0%26prolific%3Dbar

This data produces the following OAuth header authorization:

Authorization: OAuth oauth_consumer_key="abcdef", 
                     oauth_version="1.0", 
                     oauth_signature_method="HMAC-SHA1", 
                     oauth_timestamp="2", 
                     oauth_nonce="1", 
                     oauth_signature="Z0PVIz5Lo4eB7aZFT8FE3%2FFlbz0%3D"

And apparently my signature is wrong. The problem has to either be in the construction of the base string, in the way that the HMAC-SHA1 function is implemented (using Apple's CCHmac from CommonHMAC.h, so hopefully this isn't it), or with my Base64Transcoder, which is open source c. 2003 by Jonathan Wight/Toxic Software. I primarily suspect the base string, since the requests work for GET and POST and only fail with POST with URL parameters as above.

Can someone with lots of OAuth experience spot the problem above? Something else that would be very useful is the base string that is produced by Apache Commons OAuth in their authentication. Thanks.

Thomson Comer
  • 3,919
  • 3
  • 30
  • 32
  • 1
    Try defining constants for those keys. It will help root out typos and make it easier to change te keys if need be. – Moshe Jan 25 '11 at 01:13

2 Answers2

5

As per RFC 5849 section 3.4.1.2, the OAuth base string URI does not include the query string or fragment. If either the client or the server does not remove the query parameters from the base string URI and add them to the normalized OAuth parameter list, the signatures won't match. Unfortunately, it's hard to tell which side is making this mistake. But it's easy to determine this is the problem: If it always works without query parameters but always fails with query parameters, you can be pretty sure that one side or the other is generating the wrong base string. (Be sure that it always happens though... intermittent errors would be something else. Similarly, if it never works with or without a query string, that would also be something else.) The other possibility is that normalization was done incorrectly — the parameter list must be sorted and percent encoded sequences must be upper-cased. If it's not normalized correctly on both sides, that will also cause a base string mismatch, and thus a signature mismatch.

Community
  • 1
  • 1
Bob Aman
  • 32,839
  • 9
  • 71
  • 95
  • Bob, thanks for pointing me to RFC 5849. Section 3.4.1.1 has a complete example of a base string used in the encryption. I was able to verify that it appears to match my own base string perfectly. This does not bode well... – Thomson Comer Jan 25 '11 at 03:55
  • 2
    This seems to be a common mistake which isn't very clearly stated in the OAuth documentation, that the parameters included in a GET or POST must be -sorted- (like.. a=1&b=2.. b=2&a=1 would give an error instead). – hikari Jun 17 '12 at 01:34
  • Not only that, but you can do both GET and POST parameters as well as the parameters from the Authorization header. These must all be merged and then sorted. – Bob Aman Jun 19 '12 at 13:14
2

you can build and check visually your request at this URL:

http://hueniverse.com/2008/10/beginners-guide-to-oauth-part-iv-signing-requests/

Open the boxes denoted by [+] signs and fill in your values, that way you may be able to see if the problem is at your code, or at the provider side.

luben
  • 2,512
  • 4
  • 30
  • 41
  • 1
    This site helped me track down a problem with my library improprely URLEncoding parameter pairs. I think I'm squared away, thanks! – Thomson Comer Jan 25 '11 at 19:35
  • Interesting. Usually with encoding problems the error is intermittent. Sometimes you'll get a string that doesn't have any special characters, so the escaping ends up being correct even though the code is wrong. – Bob Aman Jan 25 '11 at 23:04
  • I'm sure you're right about that, Bob. I've had to modify the OAuthConsumer library code repeatedly, and now I've moved on to another POST request with many more parameters and the signature is wrong, again. Back to the drawing board. :) – Thomson Comer Feb 03 '11 at 23:52
  • 1
    And this time Lyuben's web app fails me, because it only supports 11 parameters and I have 15, now. :\ – Thomson Comer Feb 03 '11 at 23:57
  • Is there a modern version of the link? Looks like the interactive walkthrough is no longer working. – Mike Meyers Jun 12 '14 at 00:32
  • Dead link. The site no longer exists. – Suncat2000 Sep 13 '21 at 15:36
  • This works: https://web.archive.org/web/20110518150137/http://hueniverse.com/2008/10/beginners-guide-to-oauth-part-iv-signing-requests – Nathan Apr 10 '22 at 18:21