The problem with having the client directly submit the username/password to the SP is that it requires OAuth Service Providers to have passwords for their users, implying that OpenID Relying Parties cannot be OAuth SPs.
For an example of a good mobile browser based OAuth UX, check out the Sparrow iPhone App for Fire Eagle. The Sparrow app opens Safari to the Yahoo Mobile Login screen, and then sends the user to the Fire Eagle OAuth Permissions screen to authorize the OAuth token. The Sparrow App automatically regains focus after the user authorizes the token via a custom protocol handler on the OAuth callback URL. Is the UX demonstrated by the Sparrow iPhone app sufficient for mobile apps? I think it's just as good, if not better, than submitting the username/password directly to the SP. Allen Luke Shepard wrote: > It's still not great. > > For example, take my Gmail app on my Blackberry. I don't have to go to a > website- I can enter my credentials directly. This is great- if I had to go > to a web browser, I would probably never have installed it. > > So, how can we do that with OpenID and OAuth? > > One way could be an extension that allows an OAuth consumer to ping the > provider directly with a username and password, and get a token directly. > Yes, this has issues with trust and security. But my point is that these apps > are being built already, and wouldn't it be cool if they were built using > open standards? > > So I'm just putting it out there. > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
