Use the right documentation.
There’s a lot of outdated docs out there. I frequently find myself at OAuth Core 1.0 Revision A, and it’s such a pretty page and easy on the eyes, but way at the top where you’re likely to miss it is a notice saying it’s obsolete. The notice says to use RFC 5849: The OAuth 1.0 Protocol and, although hideous, it’s up to date and more complete.
How’s the signature algorithm written?
Here’s some pseudo-code:
What’s the format for the timestamp?
It’s just a UNIX timestamp (in seconds).
How do I generate a nonce value?
The OAuth spec just says it’s a random string. I think the Google documentation says something about using a string representation of a 64 bit integer. I had no idea what they were talking about, but somewhere I read you just need to md5 hash a random integer, and it worked for me.
If developing for a Google service, use their OAuth playground.
Their OAuth Playground is a great way to see the process you have to go through and what the requests look like. If trying to authenticate with another provider see if they also have an API test app.
Don’t expect detailed errors.
You’ll be lucky if the response tells you “signature invalid”, but you won’t be told what’s wrong with it. My strategy was to compare my signatures and parameters to those used by the Google Playground; taking values from there that you know are valid and using them to test your code is a good way to debug.
The scope parameter has to EXACTLY match the URLs used in your API calls
In the Google OAuth Playground, selecting “Picasa Web” will input “https://picasaweb.google.com/data/” for the scope. Note the use of https:// for the protocol. If you make API calls using that URL, it will fail since none of the Picasa services are served over https. If you try to make calls using regular http you will get an OAuth error saying invalid scope. In order for it all to work, you have to use “http://picasaweb.google.com/data/” for the scope.