oAuth versus Application Keys

I have not spent hours reading standards for interacting with websites.  However I did recently have to integrate with various services across a few projects:  MailChimp, GoToWebinar (citrixonline) and LinkedIn.

The easiest to integrate with from simple C# / .NET code was definitely MailChimp.  Their API has a simple REST interface and they provide application keys in their Admin dashboard that you can create and then use in your integration (this is basically a simple “password” that is tied to your application and you can revoke the key if necessary).  For typical backend plumbing/integration work this is perfect … you authenticate simply from your script or code and then do the work of the integration (adding data, pulling data, whatever).

Now let’s talk about oAuth … so I get it, the user needs to give their permission for your app to act on their behalf.  And here we have the first #fail … GoToWebinar has implemented this model although I am willing to bet the vast majority of their integrations are really just backend plumbing (grab a list of available webinars and show them on our website, etc.)  Using oAuth in this environment is really the wrong fit and is painful – but they provide no alternative.  That said, once you have done all the gyrations for user tokens, at least the actual API calls are just REST and make for simple code.  The biggest problem is that the oAuth access token will expire (after about a year I think per GoToWebinar docs in which case a human has to do the whole process to get things working again … yikes).

Next I got to try out integration with LinkedIn … in this case oAuth did actually make sense for me, since my use case did require permission from the user (not just plumbing work).  Unfortunately the API is just not simple – the description of the authentication process in the LinkedIn docs is confusing and doesn’t really explain all the bits about AccessRequestToken, AccessRequestTokenSecret, OAuthAccessToken, OAuthAccessTokenSecret and OAuthAccessRequestVerifier.  Then the second killer is it just isn’t simple to call the API due to all the signature generation required (nonce, timestamp, etc.)  I used the oAuth code from here which made it easier but still not simple.

It seems like API developers need to be careful about which route they choose (for the typical use case) and how simple these things are to use… 

Whatever happened to “Make it is as simple as possible and no simpler”?

Visit my company, Thycotic on Facebook. Thycotic is also hiring and check out these Thycotic reviews.