You are missing the point. If you use the OAuth authentication method (i.e. that signature business) as a way to deliver credentials in a 2-legged scenario, you benefit from not sending the password on the wire (of course, the other side has to keep a clear copy of your password).
All it is, is an authentication method (the part about how to make requests). It provides a way to prove you control two sets of credentials. How you use it is up to you. EHL > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of JR Conlin > Sent: Sunday, March 08, 2009 10:37 PM > To: [email protected] > Subject: [oauth] Re: Twitter OAuth Direct Access > > > 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 -~----------~----~----~----~------~----~------~--~---
