I noticed that there is not much information on the Internet about the OAuth direct implementation, so I decided to write some generalized conclusions that would help beginner developers who plan on diving into this authentication method. I must say right away that OAuth is used in a wide array of web APIs - Netflix, Twitter, Dropbox and even Facebook, therefore for developers who plan on leveraging any of those services in their own application will eventaully have to deal with it.
So here goes.
1. OAuth is confusing. That is known.
None of the services I know has detailed information on how exactly each part of the OAuth flow should be implemented. When experimenting with it, be prepared to have some problems because of the generated signature, an invalid token, misplaced keys and so on. More than that, some services are providing a less than perfect set of methods to perform the authentication itself. For example, Dropbox offers both a request_token and token methods, when only the second one should be used in third-party applications.
2. Avoid using third-party libraries if you want to understand how the process works
As a continuation to my first point, it is easy to give up on learning the idea behind OAuth and just use a third-party library. If you need to quickly build a solution that "just works", that is an acceptable idea, but then again - you will be dependent on the developer when it comes to newer and updated releases of the library. More than that, without knowing the "under the hood" process you won't be able to possibly fix some bugs that may appear in different calls to different services. Try starting from scratch. It is not as hard as it might seem. I just did that for my Dropbox for WP7 client implementation.
3. Different services treat OAuth differently
Even though OAuth in its core is a single standard, it is implemented with small differences in various services. One might require you to specify a nonce that follows specific security requirements, others will return poor response (as in - containing much less error information than you would expect). Be ready to do some research on each separate implementation and don't make blind assumptions that it will work on the first try - usually it won't.
4. Documentation is poor. But there is source code.
Whenever a web service provides an OAuth endpoint, it usually is very limited when it comes to detailed documentation. You might get information on general endpoints (and sometimes, even confusing double endpoints, like in Dropbox) and some example responses, and that's it. Be prepared to experiment with code a lot if you write your own implementation. Then, the third-party library set becomes helpful in the context of looking at how other developers implemented the same thing. Sometimes you might miss one minor part that breaks the entire call, and that part was already mentioned in someone's code. Don't be shy - download those archives and re-compile, modify and analyze them. It will help you in the long run.
5. There are resources that can help you get better at it.
Here are the resources that helped me a lot:
- StackOverflow OAuth-tagged questions - in my opinion, this is the first place you should look for various implementations. Chances are - people already worked on something you are working and you can take a sneek peek at the code. Even if it's in a different programming language, it is fairly easy to catch the idea.
- OAuth Core documentation - as long and boring it might seem, this is the most comprehensive resource on OAuth you will find online at the moment. Contains all the data you need to build an OAuth abstraction layer.
- OAuth signature tester - believe it or not, the OAuth signature is the show-stopper for a lot of developers. Missed parameters, incorrect order and whatnot. This online tool will quickly help you generate the proper signature. That way you can make sure that your own algorithm is correct.