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 –
Twitter pre-announced a new version for their API last night and developers are predictably miffed about it.
I’ve run TwitBlock for three years and have always known that one day it will stop working and I’ll have to take it offline. However, it’s not clear to me yet whether I’ll have to take it down in six months, so I’m trying to avoid a rant for once (mostly).
I just don’t think the impact is clear enough at this stage. Most points in the announcement are either too grey, or just confirm a general direction we were already well aware of.
By way of composing my own thoughts, this is my reaction to some points in the announcement:
Below is a mock-up of how I’d like to see Twitter implement fine-grained application permissions.
To create this badly photoshopped image for my DevNest talk, I took Facebook’s Connect dialogue and spliced it with Twitter’s new design for their Anywhere platform.
Take in its beauty, and then I’ll explain …
This image is a mock-up – it is not Twitter, or TweetDeck official. (just covering my back, ok?)
Off the back of all the recent Facebook changes I just read the OAuth 2.0 spec – it’s currently in a draft state, and according to this page, Facebook is currently the only implementation in the wild. This new spec attempts to pull together various authentication journeys rather than just the typical web app model. This is a great news – It seems to accommodate many different situations across differing devices with different capabilities, while maintaining a good level of consistency.
You didn’t expect me to have only nice things to say, did you? There are a couple of things I have to question. Continue reading…
I woke up this morning to the apparent viral spread of the TweetCloud app that unoriginally, but very nicely displays your most tweeted words of the year, or month, or .. you get the idea. Here’s mine ->
Two things happened today that inspired me to write this post tonight.
Facebook and Twitter both offer authentication services arguably known as “single sign-on”. Facebook Connect is a proprietary system, and Twitter offers a system based on the OAuth standard. These services do something quite marvellous – They allow you to authenticate with a another website without the third party ever seeing your password. What’s makes it even more handy is that you’re probably already signed in to these popular services, so you may not need to enter your password at all. The problem is when you do.
I noticed some weeks ago that Twitter’s OAuth implementation didn’t appear to be verifying signatures. I knew this because I purposefully set an invalid access token which was accepted unconditionally. I thought this was odd, but as a newbie to OAuth I was just happy that my app was working, so I filed the problem at the back of my mind under “deal with it if it becomes a problem”. Today (the week I release by beloved TwitBlock app) it very suddenly became a problem.