James Wanga wrote:
>  What Yahoo has
> done works well for the web but it does not address mobile and
> browserless device use cases. 
Using OAuth with browserless devices is challenging, and perhaps it's 
more realistic to provide an API that allows the device to exchange the 
username/password for a scoped credential (Access Token). After 
obtaining the Access Token, the well behaved device should discard the 
password, and only store the Access Token persistently.

Assuming that the application developer wants to do the right thing, 
storing a scoped Access Token that can be revoked is a lot better than 
storing the password. This would allow the SP to build a screen for the 
user to see what devices have been authorized, and give the user  the 
ability to selectively de-authorize devices if necessary.

Also, if the user loses the device (or if it's stolen), the password 
isn't on the device and can't be extracted. The user would still be able 
to login to the SP's site and de-authorize the lost/stolen device.


>  BTW. How do you
> overcome popup blockers?
>   
Popup blockers usually aren't an issue if the popup was opened from 
within the same call stack as the event triggered by the user's mouse click.

Yahoo, Google, and Facebook all use popups for their delegated auth 
flows, and they're usually not a problem.

Glad to hear that you're a fan of granular access control. I think it's 
the main improvement of token based auth over HTTP Basic Auth.

Allen




--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to