DISQUS

Carsten Pötter · 4 months ago

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.

Jesse Stay · 4 months ago

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.

Alex Popescu · 4 months ago

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.

Jesse Stay · 4 months ago

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.

Alex Popescu · 4 months ago

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.

Alex Popescu · 4 months ago

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?

Jesse Stay · 4 months ago

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.

Richard Cunningham · 4 months ago

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.

Carsten Pötter · 4 months ago

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.

Ryan Altman · 3 months ago

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