Zachary Voase wrote: > If a malicious user can convince you to authorize an application, > then (he/she/it) can almost certainly get you to put in a callback > nonce as well. Submitting a form is still submitting a form, whatever > extra bits one sticks on top of the process. > > The callback token helps to ensures that the Consumer will associate the Access Token with the browser that passed it the callback token. The attacker doesn't have the callback token.
That being said, you are absolutely correct that if an attacker can convince the victim to click on a link and authorize a token, not much really can be done. The callback token helps protect innocent consumers from associating the attacker's account with the victim's access token. Once this vulnerability is fixed, attackers will need to build their own consumers, and trick victims into authorizing them. The overall user experience for the victim is still mostly the same, however, the attacker's consumer will be displayed on the SP's approval screen, rather than the innocent consumer. We are, of course, assuming that people read the approval screen. 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 -~----------~----~----~----~------~----~------~--~---
