Introducing ‘Sign-in with Twitter’, OAuth-Style “Connect”

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).

Sign in with Twitter

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:

Sign in with Twitter

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:

Sign In with a Yahoo! ID

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.

19 thoughts on “Introducing ‘Sign-in with Twitter’, OAuth-Style “Connect”

  1. Eran-great write-up, as usual. I think this is a very clever and innovative use of OAuth–kudos to Twitter! However, it’s still not as useful as the OpenID checkid_immediate flow, and here’s why: most sites like Twitpic would like to emulate “single sign-on” from twitter. With OpenID, they can cookie the user when they show up, and then when they return, they do checkid_immediate to the OP, which will *always* redirect back invisibly whether or not the user is signed in. If the user is still signed in, no need to prompt the user for anything, it just looks like SSO. But if the user is not logged in, then they can prompt the user to log in again. But as I understand Twitter’s implementation, you have no choice but to either a) always ask them to log in every time (which may end up then just redirecting back after the user clicks to sign in), or b) always force-redirect to twitter, which may end up showing them login UI (which might be jarring). Maybe that’s no worse than sites that force you to a signin page if you try to access them and you’re not already logged in, but it still seems like it’s not quite as tight a UX as is possible with OpenID. Thoughts? I suppose a remedy would be to make an “immediate mode” for the authenticate endpoint…

  2. Sure, you need to use the right tool for the right job and if Twitter is mainly looking to support their existing group of developers then what they’re doing makes sense. If they were to implement the OpenID + OAuth Hybrid then Twitter users would be able to use their Twitter account to sign in to any site which supports OpenID plus those sites building Twitter specific interactions would be able to ask for the same API access via OAuth.

  3. I’m always for support open standards. I think this move of Twitter is definitely what we have been waiting for.
    I for one had shy away from many of the 3rd party Twitter sites/services that requires me to provide my login credentials; with one exception, TwitPic. When Twitter released the OAuth beta I was very happy to see this and was encouraging every 3rd party Twitter site developers I meet to switch to use Twitter’s OAuth.
    Now with this new Sign-in With Twitter feature, it will make this adoption of Twitter OAuth even easier for 3rd party Twitter sites and services.
    Now we just need this feature to be opened up to all site owners quickly. Although, I understand Twitter’s reluctance to do it too quickly, given its past performance difficulties; frequent Failed Whale, when the service gain mass acceptance and celebrity usage.

  4. A noob question from someone just learning OAuth:
    My assumption is this “sign in with Twitter” will Authenticate you, but will not grant you access to call other Twitter API’s on behalf of the user. Is that correct?
    If so, do you get access to the Twitter users username via the redirect?

  5. That’s not exactly right. Twitter has a very well defined behavior based on the user’s status. If the user is signed-into Twitter and already approved the application, the flow is truly single-click. And the site implement a cookie method locally to not even require the button.

  6. Twitter’s support for OpenID is a completely different question and if they were to support it, anyone using Sign-in with Twitter will become a relaying party for free. The hybrid protocol adds very little value here because the API itself is not standard.

  7. Please forgive me if this is a stupid question, I’m new to OAuth, and am working on Twitter integration with an iPhone app, but I looked at the TwitPic site and viewing the source HTML I see a form where TwitPic is directly collecting my Twitter credentials. I thought this wasn’t how OAuth worked and that they would be required to load a form directly from Twitter through an iframe or something and then do the token communication in the background, never directly handling my login and password. Could someone explain to me what is going on here and how this example works? I’d like to use this method in the app I’m working on so I’m not limited to opening a web view of the Twitter login form.


  8. Ignore my last post – did more digging and TwitPic is not currently using OAuth. Found a post somewhere from someone at TwitPic a couple months ago saying they’re working on it. Maybe it’s just me but this article misled me a bit about this.

  9. Is there any way for the application to keep the user logged in with Twitter, not only the application? does that, but I don’t actually know how they do it.

  10. Is another spin when an OpenId enabled site makes a decision to provide OpenId as an identity service, like Yahoo and Google both do but refuse to accept OpenId sign in. How would you describe that? Pseudo Federated?

    Why would this matter, well I like the control that some of the more mature OpenID providers give me, and would like to use their features when signing onto my Social and Search home pages.

    Seems like an easy win, accepting OpenID sign in as well as providing OpenIDs would be a way of demonstrating a clear buy in to Open Standards.

    • The main problem in OpenID adoption by Relaying Parties (accepting OpenIDs) is usability. No one has figured out how to make this login process with an OpenID as easy as typing in a username and password, or clicking on a Facebook Connect button. The problem with the buttons is that sooner or later, you are going to have a lot of them.

  11. I think the move to OAuth is an unfortunate step since it requires the display of a webpage to sign-in. This will effectively prevent many applications such as games from using the service. I’ve been investigating the integration of Twitter and Facebook into games, but the requirement of going to an external webpage is not going to make it possible.

    If I’m wrong, then please correct me. I’m hoping I’m wrong.

  12. Even though it was written two years ago, this is the best explanation of the Twitter application of Oauth I have seen.

Comments are closed.