Yes, the device flow could be made to work, but isn't the current native app flow more secure? Why fallback to this?
My guess is that most end users will not know what to make of all that explanation and will just click one of the next buttons. But that's just a wild guess (or fear). Marius On Wed, Apr 14, 2010 at 5:06 PM, Allen Tom <[email protected]> wrote: > As a security person, I'm hesitant to bring this up, but perhaps the Device > Flow should just be the flow for native client apps. > > The main security argument against the Device Flow is that users are > vulnerable to the Oauth 1.0 Session Fixation attack, in which an attacker > gets an Authorization URL with the user_code prefilled, and then "phishes" a > victim to approve it. > > The Flickr Uploadr is a native application that uses an auth flow that's > nearly identical to Oauth 1.0, and it does NOT use a verification code, and > it is susceptible to the session fixation issue. > > http://www.flickr.com/tools/ > > The way Flickr deals with this issue is by designing their browser UX to > make it very clear to the user that they should only be seeing this flow if > they were trying to authorize the Flickr Uploadr desktop app. The user > should *not* be seeing the flow if they clicked on a link from IM, email, > twitter, or a web page. > > Perhaps if we had a OAuth2 UX spec, we can standardize on best practices for > the AS approval page for flows which don't have a verification code. > Something similar to what Flickr is doing might be the best compromise. > > For reference, I've attached a screenshot of the Flickr Uploader approval > screen. > > Allen > > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
