Twitter has announced application level authentication for their API using OAuth 2.

For the uninitiated, this means a simpler way to make authenticated Twitter API calls, and doing so on behalf of your app, not on behalf of a Twitter user.

I went straight ahead and added support in my Node library (mostly just so I could try the new stuff out) but I’m struggling to see much advantage in this feature.

Here’s a quick brain dump  –

Rate limits

 
I was hoping that app-level auth would mean much higher rate limits. This is a big problem now for apps that do a lot of crunching; enough to force them to shut down.

App-level rate limiting is quite similar to user-level rate limiting with a lot of API calls restricted to one per minute. Some methods do have a higher rate for applications (but not much higher) and some are actually lower. For example, you can search more tweets and pull more timelines, but you can look up less users and get less list subscribers. Full tariffs for comparison here.

It’s a lottery and will probably fluctuate anyway, so don’t bank on any of it!

Simpler

 
By this point you’re probably using a library that does all the OAuth signing for you anyway, so this extra simplicity doesn’t really impact your coding tasks very much. If anything, having two auth methods just complicates matters.

If you’re distributing an app that, say – displays a user’s latest tweets – then you can cut out the part where the administrator connects the app to Twitter using one of their accounts.  I suppose that’s useful – ish. It certainly saves two clicks of your mouse.

More useful is that you’ll double your rate limit for refreshing the tweets by doing this. I can take or leave the simplicity gains.

Security

 
In some aspects app-level auth is more secure than user-level auth, because you can’t ‘accidentally’ tweet on behalf of a user. It also means if someone were to steal your auth credentials, they won’t have access to anyone’s Twitter account. That can only be a good thing.

However, people are bound to abuse the oauth2 methods to fix their soon-to-be broken and useless front end libraries.

Mandatory authentication has killed a lot of the simpler Twitter apps that made unauthenticated calls, especially the ones running in purely front end code like JavaScript-powered widgets. These cannot be upgraded easily and cannot be upgraded at all without publishing your OAuth consumer secret.

OAuth2 bearer tokens provide an easy fix for the first of those problems, but not the latter. These security models assume you are sensible and don’t publish your private credentials into the visible code of your site, but whether out of ignorance, laziness or stupidity – people will do this.

This begs the question, how big a risk would that be? Assuming an app is read-only, the worst thing that could happen is that hackers would be able to siphon off your rate limit allowance. At least I think that’s the biggest risk. Let me know in the comments if you can think of another scenario.

That’s a risk a lot of people will be willing to take if it quickly gets their broken apps working again, or gets their boss off their back.