Longtime fans of Oauth will remember the Session Fixation security issue we had last year.
The Device Flow specified in the OAuth2 draft seems to have the same issue. To illustrate: Imagine that a Photos Hosting Service supports OAuth2, and supports the Device Flow for Internet enabled picture frames. These devices have screens, but no browser, and no keyboard. An Attacker sets up his picture frame, and is instructed to use a browser on a separate device to authorize the picture frame. However, rather than entering oauth_verification_url on his own browser he instead socially engineers a victim to do it. (this is essentially the same thing as phishing) The Attacker IMs or emails the victim the link to the Auth url depending on how the Auth Flow is implemented, the attacker might even be able to construct the auth url with the oauth_user_code appended as a query parameter. If the victim is persuaded to click the link and approve the auth request, the Attacker will then have access to the victim¹s photos. Again, this is social engineering, and the victim has to be persuaded to click on an untrusted link and to click ³approve² on a strange auth screen. That being said, this sort of thing happens pretty often. In Oauth 1.0a and in WRAP, this attack is not possible. In both WRAP and in Oauth 1.0a, the victim¹s browser is issued a verification code which somehow must be passed back to the attacker in order for the attacker to access the victim¹s private data. While the Web Server and Web Client flows both have the verification_code to prevent the session fixation attack, the Device Flow does not. Is this a problem? Allen
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
