Maybe I am not getting it properly, but what I gathered was that the model was:
User -> UA -> Client -> Twitter and what Fajar was worried was that the Client would modify the tweet. By first writing through the Client and then redirecting the UA to the Twitter server for direct "commit" by the User/UA, then the user would be able to find if the Client has tampered. Essentially, this is an man-in-the-middle mitigation. I did not quite understand how a one time scope encoding the message into it would help. I would appreciate it very much if you can explain it in more detail. > Shane. 2014-05-22 15:52 GMT+09:00 Shane Weeden <[email protected]>: > Isn't that logically the same as requesting the authorize url for every > API call with a unique scope encoding all details of the desired operation > then having the oauth server issue a code (and later token) that a resource > server enforces single use on? > > What I'm suggesting is that perhaps the use case could be satisfied with > existing spec flows and bespoke use of scope fields, with single use access > tokens. > > > ----- Reply message ----- > From: "Nat Sakimura" <[email protected]> > To: "[email protected]" <[email protected]> > Subject: [oauth] Preventing OAuth client from maliciously modifying user's > request > Date: Thu, May 22, 2014 11:55 AM > > > That can be interesting. > > > 2014-05-22 10:47 GMT+09:00 Fajar Ardian <[email protected]>: > > > Thanks, Nat. > > > > I am thinking of adding a new flow to OAuth 2.0 protocol. After the web > > application sends the tweet to twitter, twitter returns a response saying > > that it will process the request only after the user approves. This > > response carry something called RequestToBeApprovedID. The web > application > > then redirects the user to twitter, carrying RequestToBeApprovedID. > Twitter > > displays the operation that corresponds to RequestToBeApprovedID, and > asks > > for user's approval. The page looks something like: > > > > Do you really want to send the tweet "Hello World!"? > > > > After the user approves, twitter redirects the user back to the web > > application. The web application then informs twitter that the user has > > approved the request, and asks twiter to process it. > > > > - Fajar Ardian > > > > On Thu, May 22, 2014 at 9:09 AM, Nat Sakimura <[email protected]> > wrote: > > > >> No. > >> > >> This is equally true for an App as well. The App may modify your tweet. > >> This is a kind of things which should more effectively dealt with ToS > >> etc. > >> Not everything needs to be solved technically. > >> > >> > >> 2014-05-21 19:41 GMT+09:00 Fajar Ardian <[email protected]>: > >> > >> I have one question regarding OAuth Client. > >>> > >>> I use a web application developed by some company to manage my social > >>> information. This web application integrates various social sites (like > >>> twitter, facebook, google+) into one. Using this application I can send > >>> tweets, read emails, and create friend requests. > >>> > >>> The web application uses OAuth 2.0 protocol to get access to my data in > >>> these social sites. After I login to this web application, I am > redirected > >>> to twitter page, and then shown a page that says that the web > application > >>> needs to be able to send tweets, etc, and ask for my approval. Once I > >>> approve, I can send tweets using this web application. > >>> > >>> To send a tweet, I type the tweet, and then click a button in the web > >>> application. At the back, the web application sends a request to > twitter > >>> using OAuth access token. > >>> > >>> What I am worried here is that the web application may modify my tweet. > >>> Is there a way in OAuth 2.0 protocol to guarantee that the web > application > >>> does not modify the tweet? > >>> > >>> - Fajar Ardian > >>> > >>> -- > >>> You received this message because you are subscribed to the Google > >>> Groups "OAuth" group. > >>> To unsubscribe from this group and stop receiving emails from it, send > >>> an email to [email protected]. > >>> For more options, visit https://groups.google.com/d/optout. > >>> > >> > >> > >> > >> -- > >> Nat Sakimura (=nat) > >> Chairman, OpenID Foundation > >> http://nat.sakimura.org/ > >> @_nat_en > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups > >> "OAuth" group. > >> To unsubscribe from this group and stop receiving emails from it, send > an > >> email to [email protected]. > >> For more options, visit https://groups.google.com/d/optout. > >> > > > > -- > > You received this message because you are subscribed to the Google Groups > > "OAuth" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to [email protected]. > > For more options, visit https://groups.google.com/d/optout. > > > > > > -- > Nat Sakimura (=nat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > -- > You received this message because you are subscribed to the Google Groups > "OAuth" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "OAuth" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en -- You received this message because you are subscribed to the Google Groups "OAuth" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
