Yesterday Twitter released ‘Sign-in with Twitter’, the ability to use Twitter as a delegated sign-in provider for third-party websites. The cool thing about this new feature, which is part of their OAuth API beta, is that it is completely standard OAuth. No extensions, not secret sauce, and not another proprietary provider (yes, I’m looking at you Facebook).
It is Open done right.
With this small enhancement of the Twitter OAuth API, Twitter created a product that directly competes with Facebook Connect. The implementation details are significantly different (and there are some technical shortcoming on both sides), but there is little you can do with one and not the other. There is no reason why ‘Sign-in with Twitter‘ cannot be used anywhere Facebook Connect is offered, including blog posts and activity streaming.
The premise of the new feature is simple. Twitter applications depend on Twitter data and services for their operation. They usually extend Twitter’s functionality, or offer an improved aspect of the service (photos, search, recommendations, etc.). These applications exist, more than anything else, within the context of a Twitter account. Since they already depend on their users having a Twitter account, they should not need to force their users to create yet local another account for their service.
When Facebook introduced their Connect product, they offered sites two key features: the ability to use existing Facebook accounts for their own needs, and access Facebook social data to enhance the site. The value of Facebook Connect is to save sites the need to build their own social layer.
What Twitter is doing with ‘Sign-in with Twitter‘ is very different. They are giving sites already tightly integrated with their service, a way to delegate authentication with practically zero cost. In other words, if you implement the new Twitter OAuth API, you get ‘Sign-in with Twitter‘ for free. It is not about yet another layer, but doing more with that you’ve already got.
The new feature is designed to fill in the gap between Twitter’s current API (using plaintext passwords) and their new OAuth API, which no longer lets users enter their password into third party applications. Many Twitter applications such as TwitPic use Twitter’s API as a delegated authentication provider. The way this works is that they ask users for their Twitter username and password, and then use these credentials to make an authenticated API call. If the call is successful, they know the user is really who they claim to be and let them use the service.
‘Sign-in with Twitter‘ offers these sites the ability to do this right. The sites will no longer need to handle Twitter passwords, store them, protect them, and deal with the legal consequences. But they will also get an improved user experience that will explain to users what is going on, and in most cases, will work smoothly with a single click.
Instead of the username and password text boxes, sites will use the new ‘Sign-in with Twitter‘ button:
Is this Another Competitor to OpenID?
While many people will focus on the Facebook vs. Twitter aspects of this new feature, some will surely see this as another problem OpenID will need to deal with. This might sound like a perfect use case for OpenID, but it is not.
OpenID is often described as a single-sign-on solution, or “the last username and password you will ever need”. OpenID is a federated authentication protocol – a protocol where users can use credentials from any compatible provider who can “speak” the OpenID protocol. But in this case, not any account will do. Twitter applications need Twitter accounts.
It is important to understand that there are two different kind of single-sign-on solutions: delegated and federated. All the recent comparisons between OpenID and Facebook Connect failed to appreciate this fundamental difference. Facebook Connect is a delegated authentication service, while OpenID is a federated authentication service. They might offer very similar features, but they are very different.
A delegated solution means that one site is simply outsourcing its authentication needs to another pre-selected site. If your site uses Facebook Connect, you are delegating your authentication facilities to Facebook. Visitors to your site cannot use any other accounts, only accounts from the vendors you have pre-selected.
A federated solution means that visitors to your site can use any account they have, as long as it is compatible. It makes no difference to the site which account is being used, as long as it can interoperate. At its core, OpenID is a federated solution because its most important feature is the ability to use any OpenID account with any OpenID-enabled service.
A good example is stores accepting credit cards. A store that accepts any Visa card is using federated payments – payments from any account that “speaks Visa”. But a store that accepts only credit cards issued by a specific vendor, for example, a department store branded card, use delegated payments. The reason why you no longer see many stores accepting only their own credit cards, is because it is bad for business.
But not every OpenID implementation is federated, and this is the big dilemma OpenID has to resolve.
The question is, can users use any account they want? If a site uses the Yahoo! OpenID service by using the Yahoo! button:
but does not offer the ability to use other vendors, it is really just another delegated solution, even if it is powered by OpenID under the hood. In this case, OpenID becomes just a technical detail of the implementation, not part of its design.
Much of the recent discussion about OpenID usability centers around using brands as a way to make the service more usable. But the problem with this approach is that is takes away most of the federated value out of OpenID, leaving it simply as a common protocol to implement proprietary delegated services. When implemented this way, OpenID adds no real value to services with an OAuth API.
The question which solution to use for sign-in, OpenID or OAuth, is very much application specific. If you are building a brand new site that needs accounts, and want to leverage existing accounts from services such as Google, Yahoo!, and Microsoft, OpenID is a great option that will give your users a lot of flexibility. But if you are extending an existing service, implementing a specific API and building a site that has great dependencies on another service, OAuth gives you everything you need, for very little extra work.
It is all about using the right tool for the job.