OAuth

[Torsten Mueller]

Did anyone go the hard way (like me ...) to access an OAuth server
through boost::asio or another low level HTTP library? This includes
building the requests and signing them by hand.

For Twitter I am successful and my algorithm is very stable. But now I
try to port this to Identi.ca, and this makes me despair. I read tons of
documents in the last days, especially the OAuth spec, again and again,
and fixed indeed several minor inconsistencies but after all this the
result of obtaining a request_token from Identi.ca is still nothing but
"401 Invalid signature". So it seems that this server wants something
else to be signed than me. But what???

Does anyone know wheather the address to obtain the request_token should
contain parameters or not? I mean, the address is normally

https::/api.twitter.com/request_token

Not more. For twitter access I put all the parameters into the
Authorization header only. But I found several references who use
addresses like this

https:://identi.ca/api/request_token?oauth_callback%3Doob%26oauth_consumer_key%3D92...

What's right? Any opinions?

T.M.

 

[Öö Tiib]

Did anyone go the hard way (like me ...) to access an OAuth server
through boost::asio or another low level HTTP library? This includes
building the requests and signing them by hand.

No. If I would do it then I would certainly make some defects.
Then I would first try hard to fix it. If still in trouble then
i would take some existing library like kQOAuth or liboauth and
compare behavior of mine with theirs.

 

[Jorgen Grahn]

Did anyone go the hard way (like me ...) to access an OAuth server
through boost::asio or another low level HTTP library?

I'm pretty sure boost.asio isn't a HTTP library, low- or high-level.

/Jorgen

 

[Torsten Mueller]

I'm pretty sure boost.asio isn't a HTTP library, low- or high-level.

But I'm pretty sure you can send and receive very nice requests to or
from HTTP servers.

T.M.

 

[Torsten Mueller]

i would take some existing library like [...] liboauth and compare
behavior of mine with theirs.

I'll try this and compile one of the examples. Thanks.

At least this lib is documented! The Identi.ca documentation of their
OAuth implementation ist just nothing.

T.M.

 

[Öö Tiib]

This is interesting. I debugged liboauth because liboauth is indeed
sucessful connecting to Identi.ca.

What I found out is that my HMAC-SHA1 algorithm, which is the one from
the Poco lib, produces a completely different signature than the
algorithm used in liboauth (based on the same input data). But Twitter
accepts my signatures!

Does it also accept liboauth signatures?

Can different implementations of HMAC-SHA1 indeed produce different but
correct signatures???

No. Or at least I haven't met a case.

I have seen happening something that has similar symptoms. Often the input data that may have various forms considered equal (like xml) may be automatically converted to some canonical form first before signing it to get morematches.

If a protocol involves signing then some servers may accept both signaturescalculated to canonical and raw form but some may accept only one of two ways. If you develop a client that has to connect to several servers that may behave differently then you have to try one method of signing first and if it fails then another.

 

[Torsten Mueller]

Does it also accept liboauth signatures?

Didn't try until now. I check this at the weekend.

No. Or at least I haven't met a case.

Indeed they do. I tried five different implementations now, including
Poco, liboauth, openssl and two standalone algorithms from the net.
These five produced at least three different signatures on the same
input data, but each signature was reproducible again and again and was
probably usable as a good hash value. 8-/

Because I detected that the liboauth HMAC-SHA1 implementation (which is
hard coded internally) generates the same signatures as the openssl
implementation and I already use openssl I changed my signature
algorithm to openssl. But the Identi.ca server still says my signatures
are "invalid" . From bad to worse: now I can't even connect to Twitter
anymore. I have still to investigate some things to harden this ...

I think I will install also a local HTTP proxy to log the outgoing
requests from liboauth . I'm not really sure but the debug messages from
liboauth tell me that liboauth doesn't use an Authorization header at
all. Instead of this they write the contents of the Authorization header
into the body of the HTTP request for the request_token which would
truely violate the OAuth specification. I can't believe this until now.

If this all is true I must split my OAuth authentication into two
separate paths that are completely different: a Twitter path, which is
exactly according to the OAuth specification and an Identi.ca path which
is something mysterious else.

I also thought about just using liboauth. But my application is highly
portable. If I add a new library I must be sure that it is available on
every platform. And liboauth depends at least on libcurl. I decided to
use boost::asio a long time ago because I use boost a lot all over the
entire code.

Thanks for reading.

T.M.

 

[Torsten Mueller]

Success!

The key to the problem is the filename used in the first line of the
HTTP request, between POST and HTTP/1.1. - While creating a signature
base string you have truely to specify the whole URL including
"https://", server name, absolute path, the requested filename and
parameters:

POST&https%3A%2F%2Fidenti.ca%2Fapi%2Foauth%2Frequest_token&oauth_callb...
^^^^^^:^^/^^/^^^^^^^^^^^/^^^^^/^^^^^^^/^^^^^^^^^^^^^^

But building the HTTP request you may not give him the whole thing, just
the filename with the path and (if needed) the parameters:

POST /api/oauth/request_token HTTP/1.1
^^^^^^^^^^^^^^^^^^^^^^^^

Twitter tolerates a complete URL here, Identi.ca doesn't. If Identi.ca
gets a full URL here the signature becomes invalid. This is the relevant
difference.

All the other things I thought about have less influence. Especially the
concrete signature algorithm does probably not matter. I switched back
to the Poco algorithm and it works very well with Twitter and Identi.ca.

T.M.

 

[syntotic]

(this is a very typical error pattern, you cannot use full paths nor relative paths consistently !* )