I publish an open source example of using a OAuth in a standalone mac app -- so I'm bought in to the OAuth idea. But it wasn't easy, I had to fight to make it appear even somewhat integrated, and the lack of security around my apps private keys really freaks me out. On the other hand I see a lot of posts like this where I tilt my head and say, "what are you talking about?" Because I just don't get where you're coming from. It's like there's some hidden assumption someone forgot to tell me.
So, please don't take offense, I'd just like to play devil's advocate and ask you to back up these reasons with some more info. I'll try to be specific about what seems odd, or at least odd to me:
I really loved OAuth because: (1) Ease of coding. I could get OAuth working within a couple of days.
You're saying that OAuth was easier to implement than basic auth? How so? Basic auth just places the authorization info into the request -- oauth requires the entire token request, token exchange, token inclusion dance. At best I could see someone arguing that it's roughly the same because you can use a nice library either way, but saying OAuth is actually easier seems a bit far fetched.
Saves me any password maintenance, encryption etc.
But how do you maintain the user's auth tokens? Since they're basically as powerful as a password (so long as the user has not turned them off) they need to be given the same care, right? In my implementation I save them just like passwords. Are other developers not doing this? If not why not?
(2) Integration with Twitter Branding. With the OAuth scheme, I believe my website is more integrated with Twitter. It would also be nicer if Twitter would maintain their own list of websites they trust with Oauth, just to give users the added confidence that Twitter trusts me.
I'm sure if Twitter decided that tomorrow that OAuth was out, and that PAuth or QAuth were the new black, then those would be "more integrated." My point being that this is not an advantage intrinsic to OAuth, just an advantage of using the currently blessed standard. I'll give you that one, if you also agree if that if tomorrow Twitter decided Basic Auth was the way forward, Basic Auth would then be more integrated than OAuth.
(3) Saves me worrying about SSL. A lot of people are finicky about HTTPS/SSL. This was I can just ytell them that if Twitter wants Oauth that way in future, we will simple provide it.
But doesn't that mean that people sniffing on the network where you host your app could potentially grab the authentication tokens of your users as they fly by? Or even just your application tokens if they were interested in spoofing you? I don't mean to be paranoid, but my rather tiny little site was attacked and compromised once a week by evil folks in June -- 4 different attacks by four separate security holes (note to self, don't run a wiki on the same host as my web store). These jerks are everywhere now, and they're the real deal. They have a lot of cash and a lot of patience to think of new ways to exploit your resources to their own end.
The part I hate about OAuth is that the OAUth page is extremely slow to load and sometimes does not load at all. I see this issue with the Twitter website in general as well, sometime postst from the web just don't go through. I would much appreciate if people at Twitter can address scalability problems to OAUTH, because that I believe is the biggest user turnoff.
I've noticed this too. From an outsider layperson's point of view is seems as though we're pushing every authorization request through a single doorway. My hope is that it's more a lack of my understanding, than anything else. Right? Right?!?! ;-)
Thanks for hearing my devil's advocate argument. Don't feel compelled to respond. I don't *need* answers, just curious, that's all.
Isaiah
