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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
