We recently asked all Twitter third party app developers to get rid of asking for user credentials and kindly switch to delegated authentication based on the open OAuth protocol. Today we want to point you to some possible breaking API changes Twitter is going to implement within the next weeks:
As part of our changes for OAuth version 1.0a I have been looking at how this is going to work and there is going to need to be a change that will not be backward compatible. Some of this is already coded and waiting to go, and some of it is in-progress. I expect we will deploy this the end of next week or the beginning of the following one in order to allow you to have a minimum of 7 days to make changes. These only effect desktop applications so the majority of OAuth applications are not affected. (Source: Matt Samford, Engineer at Twitter)
More technical details and a discussion of the topic are available at the Twitter Development Talk Google group.
In case you wonder what this article’s image has to do with its contents? Well, nothing. We thought pimping the somewhat dry topic would make it a bit more enjoyable.
Would be more enjoyable if there was a high res version of that image. :-)
It would have been nice if you would have summarized the Twitter OAuth API changes and their direct implications for both developers and end users in plain English, Ralf.
Basically, as far as I as a non-developer understand the ramifications, the changes only affect the OAuth authentication process carried out by 3rd-party Twitter desktop applications. Developers are advised to not use the application type ‘desktop’ because there’s no solid mechanism to ensure that the requesting application is benign. The actual authentication takes place on the web. Secondly, to prevent abuse, Twitter will implement a PIN code generated during the authentication process. Desktop apps will not be able to use ‘Sign in with Twitter’.
Of course how this all will work out won’t be known until Matt cs push the button.