This article has been sitting on my desk for the past week or so, and recent activities around the Twitter/Facebook/LiveJournal/Blogger DDoS attacks have made it even more applicable, so it’s good I waited. The problem centers around the “Open” authentication protocol, OAuth, and how I believe it is keeping companies like Twitter who want to be “Open” from becoming, as they call it, “the pulse of the Internet”. The problem with OAuth is that, while it is indeed an “Open” protocol, it is neither federated, nor decentralized. We need a decentralized authentication protocol that doesn’t rely on just the likes of Twitter or Flickr or Google or Yahoo.
Let’s start by covering a little about what OAuth is. OAuth centers, as the name implies, on Authorization. This is not to be confused with identity, which other decentralized solutions like OpenID focus on. The idea behind OAuth is that any website, or “Service Provider”, will accept a certain set of HTTP requests, handle them, and send them back to the developer, or “Consumer” in exactly the same way as any other OAuth protocol does. OAuth tries to solve the issue of phishing and storage of plain-text usernames and passwords by sending the user from the Consumer website, to the Service Provider’s website to authenticate (through their own means or means such as OpenID), and then authorize. On Twitter this process is done via an “Allow” or “Deny” button the user can choose to enable an application to make API calls on their behalf. Once authorized, the Service Provider sends the user back to the Consumer’s website, which is given a series of tokens to make API calls on behalf of that user.
OAuth’s strengths are that it is easily deployable by any site that wants a central, secure, and understood authorization architecture. Any developer can deploy an OAuth instance to communicate with APIs that provide OAuth architectures because libraries have been built around the architecture for developers’ preferred programming languages, and adapting to a new site implementing OAuth is only a matter of changing a few URLs, tokens, and callback URLs. I’m afraid that’s where OAuth’s strengths end, though.
Let me just put this out there: The User Experience behind OAuth is horrible! From a user’s perspective, having to go to an entirely new website, log in, then go back to another authorization page, and then back to the originating website is quite a process for an e-commerce or web company that is focusing on sales around that user. No e-commerce company in their right mind would put their users through that process, as the sale would be lost with half the users that tried it. Not to mention the fact that (and I don’t know if this has anything to do with the actual OAuth protocol) with most OAuth implementations there is no way to customize the process the user goes through. For example, on Twitter, I can’t specify a message for my users specific to my app when they authorize it. I can’t customize it in any way to my look and feel. I completely lose control when the user leaves my site to authorize and authenticate.
Let’s add to that the problem of the iPhone, desktop apps, and other mobile apps. Sure, you can redirect the user within the app to a website to authorize, but again, you’re taking them away from the app flow during that process. It’s a pain, and headache for users to log in using that method! Not to mention they have to do that EVERY. SINGLE. TIME. they log in through your app since there’s a good chance they were not logged into Twitter or Flickr or other OAuth app in the first place. It’s a huge problem for OAuth developers on these devices, and less-than-ideal.
Now, back to my original point. The biggest problem with OAuth is that it requires a centralized architecture to properly authorize each application. We see this is a problem when entire apps like my own SocialToo.com can’t authenticate users when Twitter gets bombarded by DDoS attack. The need for centralized control of each app on their platform is understandable, in that in the end the companies implementing OAuth still need a way to “turn off” an application if an app gets out of hand. Of course, one solution to this from the developer’s (Consumer’s) perspective is to implement their own authentication and authorization scheme rather than relying on someone like Twitter’s. This is less than ideal though, since most of our users all belong to some other network that already handles this process for us. Why require our users to repeat the “account creation” process to overcome centralization?
I think there is a better solution though. What if a distributed group of “controlling sources” handled this instead, giving each company admin control over their own authorization? What I propose is that a new layer to OAuth be created (or new protocol, either way), enabling trusted “entities” to, on a peer-to-peer (federated) basis, sync authorization pools of users and their distinct permissions between each Consumer app and Service Provider. Companies/Service Providers could then register with these “controlling sources”, and they would have admin access to turn Consumer apps on or off in the event of abuse within their app.
So let’s say you’re Twitter and you want to let your developers authorize with your API. You register on one of these “controlling sources”, they confirm you’re legit (this could possibly be done via technology in some form, perhaps OpenID and FOAF), and let you create your own “domain” on the “controlling source”. Twitter would now have their own key on the “controlling source” to give developers, and the controlling source would divvy out tokens to developers wanting to access Twitter’s API. Twitter’s API could verify with the controlling source on each call that the call is legit. To kill an application, they would just need to log into the controlling source and deny the application. The application would get denied at the controlling source before it even hit Twitter’s API.
What makes this open is that, if this were itself written under an open protocol, anyone could theoretically create one of these “controlling sources”. So long as they operated under the same protocol, they would operate and work exactly the same, no matter who they were. Developers could then pick and choose what “controlling source” they wanted to authorize through. If one went down, they could switch to another. Of course, there are some security issues and authenticity of “controlling source” issues that need to be worked out, but you get the idea. This would essentially completely de-centralize the entire authorization process. Authorization itself would quickly become a federated process.
Now, that still doesn’t solve the User Experience issues I mentioned earlier. To solve those, I think we should look at Facebook and what they’re doing with Facebook Connect. With Facebook Connect, the user never leaves the Consumer’s website to authorize and authenticate. They click a button, a popup comes up, they log in, and a javascript callback notifies the app the user has been authorized and authenticated. It’s essentially a simple, 3-step process that completely leaves the website owner in control. In addition, Facebook has provided Javascript methods allowing the developer to confirm various states of authenticity, without the user having to leave the website. I’d like to see OAuth emulate this model more. Right now I’d rather implement Facebook Connect than OAuth for these reasons.
I think, as both Dave Winer and Rob Diana point out, there are some serious issues being brought up from the recent DDoS attacks against Twitter and other sites. Twitter’s inability to handle the DDoS attacks when compared to the others I think shows we need much more Federation from the site, as well as the “Open” protocols it is trying to build around. Twitter wants to become a utility. There is no way that will ever happen until they Federate, and I think that has to start with a change to the OAuth protocol.
Discover more from Stay N Alive
Subscribe to get the latest posts sent to your email.
I don't think it's an OAuth problem you're describing here. Rather it seems you – and other developers as well – are using OAuth for means it wasn't designed for. OAuth is meant only for authorization of third party apps, so users don't have to provide their passwords to those apps. If the OAuth provider (=Twitter) is down there is no need to make API calls to it because quite simple, the third party can't get any data.
The problem is that third parties use for OAuth for authentication as well. Admittedly, that's even encouraged by Twitter with its Twitter login buttons. However that's not OAuth's purpose. There is OpenID, there is FB Connect.
I still think there is a need to decentralize the OAuth process from the
Providers. The Authorization process and the API calls to the Provider are
completely different layers. In Twitter's case currently, I can make API
calls, but I cannot get my app authorized.
That also does not address the other issues with OAuth I mention.
Regardless, there's still a huge Ux problem with OAuth. Centralization is
only one problem I see.
UX can always be improved. However I still think each protocol should be used the way it was intended to be. The protocol itself can grow and mature over time (OpenID is such an example), of course.
I agree. The main problem that Twitter needed to solve given that they are dependent on the API was that third party apps had to store your password in a plain text or reversible encrypted form, which made it hard to know who had access and how to revoke it. It's something Flickr solved years ago and perhaps never had the problem.
A completely different problem is that users don't like having lots of logins, using Twitter's oAuth for logins helps that, but ultimately it wasn't designed for that and Twitter isn't setup to support that really.
I think the problem with relying on the third party for authentication, be that oAuth, OpenID, FB connect or whatever, is that the third party has to provide a service has to be very very reliable and with a good support system behind it. Twitter is not currently such a company, they are notorious for reliability issues, they are young company with relatively few staff and pretty much all in one location. If you compare that to Google for example, they are an old company with a massive staff, lots of experience and reputation for good uptime. Also, Google have people in several different timezones supporting their core stuff, so if something goes wrong there is always someone who is at work, at their desk, who's job it is to fix it and they are more than qualified to do so.
Jesse,
While I think you're raising a couple of interesting points, I also do feel that you are mixing up some aspects.
1. “We see this is a problem when entire apps like my own SocialToo.com can’t authenticate users when Twitter gets bombarded by DDoS attack.”
As others have already pointed out this is an authentication problem and has almost nothing to do with OAuth itself (it may be related though to the way things work with Twitter, but it is definitely not generic).
2. I fully agree with your UX remarks. And as you probably know already, there have been efforts towards improving the end user experience. Anyways, what might not be immediately obvious is the fact that the more freedom would be allowed to the parties the more the security would be at risk. People have suggested many different approaches but most of them have been proved to be less secure than the current one. And we should not forget the fact that these protocols are intended to general use and not only for tech savvy users.
3. re: decentralization
I am not sure how decentralization would apply for this protocol, because basically OAuth is about saying: please allow application X to access my data in application Y. So any other 3rd party involved will just look weird in this process. Not to mention the fact that the more intermediaries are added the less secure the whole operation is (basically the addition of each intermediary step is just adding another possible man-in-the-middle attack).
Last, but not least, let's say there is a decentralized architecture and you get your app authorized to perform ops using a 3rd party service. But in case the original service is not able to perform the operation (which is what happens during a DoS attack) your application will still not work.
cheers.
Alex, the problem is that once you send the user to the Provider's website,
there is no way to tell beforehand that the provider's website will be down.
Perhaps better ways to error check before hand if the provider is up.
Perhaps the Ux is the biggest bottleneck still.
The goal of the decentralization was to at least authorized so you could
make such API calls and know if the API was up or not. The Ux is probably
the more central issue here though.
This is indeed an interesting scenario and one where UX looks to suck completely.
And to make things even worse, I don't think there is an easy way to get a reliable solution.
What you can probably try is to check the 3rd party service status prior to leading your user to the step involving OAuth. If the 3rd party reports that it is up (indeed, you'll have to be careful on how you check its status) then you'll increase the chances for OAuth to work. If the 3rd party looks down, then you'll have to offer your user an alternative. But as I've already said this is not reliable.
I think this scenario should be presented to the OAuth group and see what others will suggest.
Jesse, I've been thinking about this a bit more and I'm wondering if the first step of OAuth (the Request Token step) cannot be used exactly for this verification? This step occurs before the user is redirected to the service provider for login and so if the service provider fails to return the Request Token then it is a good chance that the consumer app will have to inform the user that the service may be down and they will have to try later.
What do you think?
Alex, that's possible, but the service provider would need to distinguish
what is an invalid request token, and what simply is them flaking out. I
don't think the spec does that currently.
[…] Oh, the Trouble With OAuth | Stay N’ Alive. […]
“We need a decentralized authentication protocol that doesn’t rely on just the likes of Twitter or Flickr or Google or Yahoo.”
It's not just the authentication protocol needing decentralization. The entire social web needs to be decentralized to the point that a user doesn't need to be on any major social platform to have the same experience.
A decentralized platform (basically via specification) would require a decentralized authentication.
Currently, we have blogs, and bloggers have their domains. That should be sufficient for authentication, imo. Of course, those who do not wish to own a domain, may use various services, but it shouldn't matter which service a user actually belongs.
Something will change, or so I hope.
“We need a decentralized authentication protocol that doesn’t rely on just the likes of Twitter or Flickr or Google or Yahoo.”
It's not just the authentication protocol needing decentralization. The entire social web needs to be decentralized to the point that a user doesn't need to be on any major social platform to have the same experience.
A decentralized platform (basically via specification) would require a decentralized authentication.
Currently, we have blogs, and bloggers have their domains. That should be sufficient for authentication, imo. Of course, those who do not wish to own a domain, may use various services, but it shouldn't matter which service a user actually belongs.
Something will change, or so I hope.
“We need a decentralized authentication protocol that doesn’t rely on just the likes of Twitter or Flickr or Google or Yahoo.”
It's not just the authentication protocol needing decentralization. The entire social web needs to be decentralized to the point that a user doesn't need to be on any major social platform to have the same experience.
A decentralized platform (basically via specification) would require a decentralized authentication.
Currently, we have blogs, and bloggers have their domains. That should be sufficient for authentication, imo. Of course, those who do not wish to own a domain, may use various services, but it shouldn't matter which service a user actually belongs.
Something will change, or so I hope.
“We need a decentralized authentication protocol that doesn’t rely on just the likes of Twitter or Flickr or Google or Yahoo.”
It's not just the authentication protocol needing decentralization. The entire social web needs to be decentralized to the point that a user doesn't need to be on any major social platform to have the same experience.
A decentralized platform (basically via specification) would require a decentralized authentication.
Currently, we have blogs, and bloggers have their domains. That should be sufficient for authentication, imo. Of course, those who do not wish to own a domain, may use various services, but it shouldn't matter which service a user actually belongs.
Something will change, or so I hope.
[…] Oh, the Trouble With OAuth | Stay N’ Alive. […]
Jesse, I've been thinking about this a bit more and I'm wondering if the first step of OAuth (the Request Token step) cannot be used exactly for this verification? This step occurs before the user is redirected to the service provider for login and so if the service provider fails to return the Request Token then it is a good chance that the consumer app will have to inform the user that the service may be down and they will have to try later.
What do you think?
I agree. The main problem that Twitter needed to solve given that they are dependent on the API was that third party apps had to store your password in a plain text or reversible encrypted form, which made it hard to know who had access and how to revoke it. It's something Flickr solved years ago and perhaps never had the problem.
A completely different problem is that users don't like having lots of logins, using Twitter's oAuth for logins helps that, but ultimately it wasn't designed for that and Twitter isn't setup to support that really.
I think the problem with relying on the third party for authentication, be that oAuth, OpenID, FB connect or whatever, is that the third party has to provide a service has to be very very reliable and with a good support system behind it. Twitter is not currently such a company, they are notorious for reliability issues, they are young company with relatively few staff and pretty much all in one location. If you compare that to Google for example, they are an old company with a massive staff, lots of experience and reputation for good uptime. Also, Google have people in several different timezones supporting their core stuff, so if something goes wrong there is always someone who is at work, at their desk, who's job it is to fix it and they are more than qualified to do so.
UX can always be improved. However I still think each protocol should be used the way it was intended to be. The protocol itself can grow and mature over time (OpenID is such an example), of course.