Twitter is updating its authentication system to give users more control over how third-party applications can access their accounts. Applications will now have to explicitly request additional permission from the user during the authentication process in order to send and receive direct messages on behalf of the user.
At first glance, the change seems like a welcome improvement to the Twitter APIs. Support for granular permission tiers is one of the technical advantages of authority delegation systems like OAuth. There are also already a number of other social networking services—particularly Facebook—that use tiered permissions in a similar manner. Despite the potential advantages for the end user, Twitter's approach to implementing the feature comes with some serious problems for third-party client implementors.
A brief explanation of OAuth
The OAuth standard was originally intended to enable server-to-server authentication for limited third-party access to non-public APIs. It is poorly suited for open APIs with an arbitrary number of independent third-party applications. More significantly, it doesn't address the needs of desktop and mobile authentication at all. Despite the significant limitations of the standard, it is being adopted and mandated by a number of social networking services, including Twitter.
The OAuth authentication process must be carried out in a Web browser and involves a series of redirects: a third-party site sends the user to the Twitter website to log in and approve access and then Twitter redirects the user back to the initiating third-party site and appends a token that the third-party site can extract and use to identify the user to Twitter. The advantage of this system is that the third-party site never gets the user's actual password, just a revokeble token.
The obvious problem with this system is that the redirect dance doesn't work for native non-web applications. The OAuth standard defines a separate flow for those situations. Instead of using redirection, the user gets a link to copy and paste into their browser to start the authentication process on Twitter's website. After authentication is completed on the Web, Twitter will spit out a pin number that the user has to manually copy and paste into the application.
The pin system poses some enormous technical and usability challenges for application developers, especially on mobile and embedded systems where multitasking and copy/paste features aren't available. Some developers choose instead to embed an HTML renderer in the application and then scrape the pin out during the authentication process. Even that is problematic on many different levels.
Twitter addressed the issue by implementing xAuth, an OAuth variant for native applications. In the xAuth authentication process, the user simply types in their username and password and then the application relays those to Twitter and gets back a revokeable authentication token. This made it possible to have the same security advantages—because the application does't have to retain the user's login credentials or send it on subsequent requests—but it offers the usability advantages of conventional logins. Twitter individually vets the applications that use xAuth and doesn't make xAuth-enabled keys freely available through an automated system.
Unfortunately, it looks like xAuth—and the Twitter applications that rely on it—are getting thrown under the bus by Twitter as part of the new round of authentication system changes.
How the changes will impact xAuth
The new granular permission system will only work with the Web-based OAuth authorization flow, which means that it won't be accessible to third-party Twitter applications that rely on xAuth. Such applications will have to either be rewritten to use a Web-based authentication flow with exceptionally poor usability or they will have to forgo the use of direct message APIs.
On top of that, every single user of every single third-party Twitter application will have to go through the authentication process again in order to continue using direct messaging functionality. Rather than grandfathering in applications that have access to direct messages today, Twitter is going to universally revoke access to the feature for third-party clients and make users explicitly grant it through the new permission system.
Twitter initially intended to make the transition on June 1—which would have made it impossible for the vast majority of third-party mobile Twitter applications to be updated and go through various mobile app store approval processes. Applications that can't be updated in time would end up showing authentication errors when users try to access their direct messages.
In summary, Twitter is: 1) making the authentication system that it has traditionally endorsed for native applications untenable for use by actual Twitter clients, 2) is going to force all users of third-party Twitter clients to reauthorize the applications they use, and 3) is refusing to give third-party developers enough time to adapt their applications to accommodate these changes.
Unsurprisingly, the response from the third-party developer community has not been positive. Responses range from frustrated confusion to anger. In response to the overwhelmingly negative feedback from developers regarding the June 1 deadline, Twitter has pushed it back out to June 14—which will still probably not be enough in some cases.
Adding insult to injury, Twitter's own first-party client applications will be exempt from the new policy. What this means is that Twitter alone will be able to use xAuth for fully-featured mobile client applications. This move will significantly expand the artificial advantage that Twitter's own client applications have over third-party alternatives.
A few months ago, Twitter issued a statement publicly discouraging third-party developers from building Twitter clients. The company made it clear that it wants complete control over the Twitter client experience and that the longtime supporters who made Twitter accessible on a diverse number of platforms are no longer wanted.
That campaign to disenfranchise third-party developers started shortly after a controversy erupted regarding undesirable user interface changes in Twitter's own native iPhone application. Twitter clearly felt threatened by the ease with which users were able to switch to alternative clients when Twitter tried to inject intrusive ad-like elements in its own application.
The recent changes to the permission system are being touted by Twitter as a security improvement, but it's just an attempt to spin perception and obscure the blatantly anti-competitive and developer-hostile underpinnings of the transition. The current xAuth-enabled applications have been individually vetted by Twiter and are all native programs that users deliberately installed on their devices to use as Twitter clients—with the knowledge that the application would have access to their direct messages. As such, there isn't really any logic to Twitter's handling of these applications from a technical or security perspective.
Many third-party Twitter client developers posted a message in the Twitter developer discussion group to voice objections to the changes, but the following is one that I think best captures the essence of the situation:
"Users do not need protection from their personal mobile Twitter clients any more than they do from their browsers. It's their app running on their device accessing their account at their direction. Requiring separate authentication for DMs for a mobile client app is like requiring separate cars keys for ignition, gas pedal, and brakes. Millions of mobile Twitter users are going to get really ticked off when they can no longer use their favorite apps. So let's be honest. When it comes to Twitter mobile clients, this isn't about user security. It's about pruning client competition from the market."
What happens now?
The bottom line is that Twitter doesn't want to compete with third-party client applications. They created open APIs in order to see what kind of innovations other developers could produce by using Twitter as a platform. Now that they have seen what works and what doesn't, they are going to gradually elbow out the third party developers and take control of the whole ecosystem themselves.
Twitter is probably taking this opportunity to cut the legs out from under xAuth in order to disrupt the growing popularity of some prominent third-party iOS clients, such as TapBot's much-praised Tweetbot.
If Twitter succeeds in bullying all of the third-party client developers out of the market, it is going to be a major loss for users who have benefited from the availability of diverse third-party clients. It is going to be especially problematic on platforms where Twitter doesn't provide its own client.
In the short term, it means that users who don't run Twitter's own applications are going to get a seriously suboptimal authentication user experience after the transition. Applications that can't be updated in time will appear to be broken because they will be unable to access direct message functionality. It's going to be enough of a pain point for some users that it will likely serve to encourage adoption of Twitter's own clients.
reader comments
41