If I may, no, actually, it's not a neat idea. There's a big difference between OAuth credentials and your username and password. OAuth credentials aren't really designed to be completely secure, and you should be able to easily generate a new shared secret should your old one be compromised in some manner. (e.g. you suddenly realize that putting both of these in some Javascript code on your site is a bad idea when you find out your usage goes through the ceiling after someone posts your code to 4chan.)
If your OAuth credentials are your username and password, you kinda lose the ability to reset things should they go horribly wrong. There's also some merit to the idea that when you get credentials for a three legged lookup, the person giving you the credentials should be able to say "Uhm, no, just call me that long string of gobbledy-gook. I don't want you to have my name, email, or anything else." Granted, it's rare, but different people have very different views on what information they want to hand out. I'll be honest. Facebook Connect is certainly easy to implement and use, but it absolutely scares the crap out of me what someone could do with that if they were malicious. Likewise, Twitter has created the really horrible behavior pattern of "Go ahead and give your username and password to whoever asks for it". Oauth is a bit better in that it is a way to have users agree to share information, but as some folks note, it's far from perfect and has it's own behavioral problems. Your credentials, regardless of form, are the keys to that bright, shiny Ferrari that's hopefully in your driveway and not mowing down pedestrians with a full complement of police chasing after it because you left the doors open and the motor running. CA Meijer wrote: > Cool, thanks for the info. It's kind of a pity; it was a good vision > and a neat idea. > > > On Mar 8, 8:39 pm, Eran Hammer-Lahav <[email protected]> wrote: > >> This statement was more 'vision' than 'practice'. I'll adjust it to correct >> this misconception. The idea is that OAuth *could* be used in such a way, >> but as far as I know, no one is applying it like that. >> >> EHL >> >> >>> -----Original Message----- >>> From: [email protected] [mailto:[email protected]] On Behalf >>> Of CA Meijer >>> Sent: Sunday, March 08, 2009 11:01 AM >>> To: OAuth >>> Subject: [oauth] Re: Twitter OAuth Direct Access >>> >>> Thanks for the reply. I think that I understand your point but it >>> seems somewhat at odds with the following sentence in the basic guide: >>> "When OAuth is used as a direct replacement of HTTP 'Basic', the >>> Consumer Key and Consumer Secret should hold the username and >>> password, and the Token and Token Secret should remain empty." >>> >>> If I want to update my status at Twitter, using my username and >>> password in the "consumer parameter" seems (1) consistent with the >>> quote above and (2) an inherently sensible choice. >>> >>> Is it impossible to use "OAuth as a direct replacement of HTTP >>> 'Basic'" at twitter? Or am I missing something completely trivial? >>> >>> On Mar 8, 6:20 pm, Eran Hammer-Lahav <[email protected]> wrote: >>> >>>> It doesn't refer to the idea that you can put your basic-auth >>>> >>> credentials and just stick them into random parameters. The idea of >>> direct access is when the application want to call the service without >>> a user-context. That is, to perform some administrative work related to >>> the service but not on behalf of a user. In the case of Twitter, the >>> only thing you can put in the consumer parameter is something Twitter >>> gives you when you register a new application. >>> >>>> EHL >>>> --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
