Implementing 2-Legged OAuth in Javascript (and CloudTest)
Introduction
If you’re reading this you are probably looking for information on how to implement 2-Legged OAuth in Javascript. I recently had to implement 2-legged OAuth into a CloudTest performance test for one of our customers. Because 2-legged OAuth is not part of the official OAuth spec yet (as of 6/15/2011) there is relatively little information outthere about how to make this all work. Where there is information unfortunately it doesn’t universally work for all implementations since there isn’t a specification for it. I hope this saves you some time… it definitely would have helped me out. You will need a working knowledge of Javascript to find the implementation details in this article useful. Without an understanding of Javascript you may find just the general OAuth overview interesting.
High Level OAuth Overview
OAuth is a way for applications to authenticate with one-another. In essence a client application encrypts a string of values and passes that encrypted string, along with the values it used to encrypt it (except one, your secret key), to theserver. The server then uses the values you sent across to look up your secret key and attempt to generate the sameencrypted string you did. The server then compares the two encrypted stringstogether. If they match, it’s a success. If not, it’s a failure.
The difference between 3-Legged OAuth and 2-Legged OAuth is that in the 3-Legged variant, the client first passes some credentials to the server and gets an access token back if authentication is successful. Then this token is passed along in subsequent requests. This is commonly called ‘the dance’ in OAuth developer circles. When you authenticate with Netflix through various platforms (AppleTV, iPhone, Netflix.com), you do a 3-Legged OAuth dance. This allows for users, applications, and authentication to be abstracted out into separate tiers.
Some other types of applications may be better suited for the authentication and message passing to happen in 1 request and 1 requestonly. This is where 2-legged comes in. In 2-legged OAuth you pass the encrypted string, the values used forencryption, and the message payload in 1 GET or POST. If it is rejected, the message fails. If it’s accepted then the message is processed. This particular app that I was working on testing was a central logging system. Every message was a log event. There was no time (or functional need) for a three-way handshake in this app and also no notion of a maintained state. 2-Legged OAuth cuts out the middleman. If authentication is successful the message is processed, no dancing around.
Recent Comments