Hi Allan. I'm glad people are actively working on the problem. What Yahoo has done works well for the web but it does not address mobile and browserless device use cases. I've reconsidered most of my argument because consumer-based auth makes granular control futile and thats the coolest thing about OAuth. I maintain that authentication gateways will be a better long term solution. In the intervening time keep up the good fight at Y! and thanks for your input. BTW. How do you overcome popup blockers?
On Sep 29, 8:46 pm, Allen Tom <a...@yahoo-inc.com> wrote: > Hi James, > > Yahoo has been researching ways to improve the redirect UX for both > OAuth and OpenID, and we've found that the "popup" UX is a pretty big > improvement, with a much higher success rate compared to the redirect UX. > > Descriptions and screenshots are > here:http://developer.yahoo.net/blog/archives/2009/06/oauth_update_ux.htmlhttp://developer.yahoo.net/blog/archives/2009/09/yahoo_openid_hybrid.... > > Sites that directly ask the user for their SP password are taking a lot > of risk. Many sites may verbosely log everything, unintentionally > spewing passwords to log files that might not be adequately locked down > and scrubbed. Sites that are compromised expose not only data on their > own site, but potentially expose the stored passwords of their users, > potentially exposing email and other high value services. > > Unless the application needs to have full access to the user's account > on the SP, it's a lot better for everyone involved to have a scoped > credential, that lets the user selectively choose what data the app can > access, and can be revoked independently of changing the password. > > Allen > > > > James Wanga wrote: > > I completely agree that having a single point of authentication is > > ideal. However, security and usability have always been an > > inharmonious pair. When a new pattern offers a significant security > > improvement in exchange for an marginal usability sacrifice, we adopt > > it. The danger of the redirection pattern is that it asks for a > > usability sacrifice in exchange for an imaginary security improvement. > > The only security value is that users MAY, over time, grow skeptical > > of entering their credentials in third party apps. This can be easily > > mitigated by more sophisticated phishing sites. The bottom line is, we > > gain so little from redirection that isn't worth the usability penalty > > no matter how unpalatable it is to enter your creds in a third party > > app. I also argue that redirection also trains users to trust being > > redirected to a site that can easily mask its URL with a few > > characters of JavaScript. In my opinion, this is a much less > > acceptable habit. The best solution I have seen was offered here: > >http://blog.atebits.com/2009/02/fixing-oauth/. Principally, this > > article argues that we should convince OS and browser manufactures to > > create platform level authentication gateways. This way, your consumer > > code triggers a platform based dialog that sends your credentials to > > the provider. Though it is an up hill battle to disseminate a new > > standard, I think this is a win-win. Thanks for responding and I hope > > we can keep this debate alive. > > > On Sep 29, 9:54 am, Breno <breno.demedei...@gmail.com> wrote: > > >> There are several issues with this argument. > > >> It assumes that the provider authenticates the user via password. One of > >> the reasons while this is so prevalent today is because of lack of viable > >> delegation mechanisms such as Oauth. > > >> It is a bad idea to enter your password everywhere even on trusted sites. > >> Sites that host applications in multiple domains often implement single > >> sign-in systems both for usability and security reasons, namely to control > >> which code paths handle credentials > > >> The user may not be prompted for the password at the provider if she has > >> authenticated recently, or the password may be saved for the provider and > >> easily available. > > >> The user may have extensions to Antivirus software that manages passwords > >> and warns against password reuse. > > >> On Sep 29, 2009 8:22 AM, "Blaine Cook" <rom...@gmail.com> wrote: > > >> Yes. Phishing is a problem. OAuth doesn't solve the problem of people > >> providing their login credentials to malicious 3rd parties. I'm pretty > >> sure that's in the Security Considerations section of the spec. > > >> To put a stronger point on it: Phishing isn't a technologically > >> "solvable" problem. Until people learn to properly identify safe sites > >> versus malicious ones (or trusted sites that lose credentials or store > >> them in insecure ways), phishing will be a problem. We can reduce the > >> number of points of contact with credentials, and we can try to make > >> it easier to understand when a site is trust-worthy versus when it is > >> not (via interface design, etc), but we can't stop people from doing > >> stupid things. > > >> Irrespective of OAuth, OpenID, SAML, or one-time tokens, I can put up > >> a "yourbank-noreally.com" site, ask for your birthdate, bank account > >> number, bank card number, verification code, one time password, etc., > >> and if you're really stupid, you'll enter it, and I can walk into a > >> bank with that information and steal your money. Once we stop looking > >> for technological solutions to social problems, we can make real > >> progress on helping people to use the web in safe ways. > > >> b. > > >> 2009/9/29 James Wanga <jwa...@gmail.com>: > > >>>> I'm new to the OAuth pattern, as such, I welcome any criticism of my > > > >> ignorance. As I understan... --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
