The idea behind OAuth has often been described as a "valet key". The kind of authentication provided by the access token in OAuth is different from the user's username and password. During the redirect, the user may choose what kind of access he wants to give, for example whether the consumer application may only read data from the provider or whether write-access is also provided. Asking for the user's credentials does not provide this kind of access.
The second thing about OAuth is that - while of course user's may be tricked - it at least gives the user the opportunity to find out about potential phishing sites by looking at the URL. With asking for the username and password there is no way the user can check whether his credentials are stored by the consumer or not. What you call a "normal authorization flow" has been described as the "password anti pattern". I would agree that this may be a bit unusual to users but they're getting used to it and from security perspective it is better due to the reasons which I described above. Regards, Lukas PS: Although I'm using OAuth for some time, this is my first posting to this mailing list. I hope it's okay ... and welcome everybody ... 2009/9/29 James Wanga <[email protected]> > > I'm new to the OAuth pattern, as such, I welcome any criticism of my > ignorance. As I understand it, Section 6.2.1 of the OAuth 1.0a spec > states that the consumer MUST obtain approval by directing the user to > the service provider at which point the user enters their credentials, > consequently, approving the request token. From what I gather, this > redirection serves two purposes. It keeps the users credentials safe > from a malicious/careless consumers and it prevents anyone snooping > the wire on non-SSL connections from obtaining any useful data. I > think premise that a redirect to the service provider keeps > credentials safe in any reliable way is deeply, deeply flawed. I've > read several arguments issuing caution about the susceptibility of > this pattern to phishing attacks and most just issue the warning then > continue on to explain how to implement it anyway. In my humble > opinion a phishing attack is so trivial with this pattern that > attempting to keep user credentials from the consumer is futile. > > Let me use the canonical scenario. The consumer - printer.example.com > - directs the user to the service provider authorization page - > photos.example.com/authorize - where the user logs in and authorizes > the consumer. The OAuth pattern argues that this keeps the user safe > in the event that printer.example.com is a den of thieves interested > is stealing your credentials. I disagree. If they wanted to steal your > info it would be pitifully trivial to redirect you to > example.printer.com/authorize. The idea that most users will notice > the URL slight of hand is unrealistic. Did you? For that matter, a > malicious consumer could load the authorization page in a browser > window without an address bar and remove the users ability to tell the > difference. The only benefit redirection seems to offer is in keeping > consumers from carelessly storing passwords that can be stolen. If a > consumer wants your password, they'll get it. Easily! > > I argue that it is so easy to trick large numbers of users with a > fake authorization page that the requirement is useless. Though far > from ideal, I propose that it isn't any less safe to allow the > consumer - web or installed - to authorize themselves by prompting for > the users credentials and passing them over SSL. This would still > eliminate the need for the consumer to store credentials on the users > behalf as with basic auth and it would spare users the unfamiliarity > of the OAuth workflow. I realize this does nothing to control > malicious consumers. My only case is that compromising the redirect > workflow is so trivial that at least we can give the user back a > normal authentication experience. > > Once again, it is entirely possible that I'm mis-understanding > something, it wouldn't be the first time. But if I'm not, then we > should really consider whether or not redirection is presenting a > dangerous, false sense of security. > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
