I really appreciate your responses. And I definitely understand your point of view now. Paraphrasing:


1.  unrelated to basic, oauth is not difficult to implement.
i agree. while non-trivial on the desktop simply because no one had done it yet (and released it as OSS), i would agree that it was not especially difficult.

2.  passwords can sometime be misused in a cross-site cross-app way.
i agree.  point taken.  especially for the web app world.

3. having twitter included as part of the sign up process feels more integrated. i agree for a web app. and since facebook and flickr do it too, the idiom is well understood. however for a desktop client this is a very abnormal (hopefully just novile?) process -- so i think i would still tend to disagree.

thanks again for posting.

Isaiah

YourHead Software
supp...@yourhead.com
http://www.yourhead.com



On Jul 29, 2009, at 8:42 AM, Amitab wrote:




On Jul 28, 4:16 pm, Isaiah <supp...@yourhead.com> wrote:
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.

I was merely advocating about OAuth here. I didn't play around with
BasicAuth since OAuth was available when I started developing
twaller.com. I wanted to respond to comments which said, OAuth is hard
to code etc., by saying I didn't feel that way, mainly because I used
the library Twitter4J.

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?


I think there is a difference. I find passwords messy because if
someone wants to misuse them, they can potentially misuse them for
other websites beyond twitter. Many people including myself have
similar usernames and exactly the same password in multiple websites.
So if I accidently leak a password, and someone uses that to login a
bank website and make a financial transaction, that will not look very
good.

Oauth token's are limited to Twitter use. At the moment, i am not
encrypting it in my database.


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

I meant the process of going to Twitter for a login makes me feel that
my application is integrated with them. As oppossed to merely saying,
please supply your Twitter name and password to my website.


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

That is a very valuable suggestion. I was thinking of hosting multiple
things on the same host, I will avoid that now.

 >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?!?!   ;-)

Yes.

Thanks for hearing my devil's advocate argument. Don't feel compelled
to respond.  I don't *need* answers, just curious, that's all.

Well, I enjoyed your post.
Isaiah

Reply via email to