On Wed, Jun 1, 2011 at 7:54 PM, Matias Woloski <[email protected]> wrote: > I've read the latest spec and some of the discussions around the user-agent > flow and native apps. I've read about the different options to get the authz > code (copy-paste, polling the title of the window, custom scheme, etc). > I might be missing something but my question is: why can't we send a nonce > in the initial request to the authz server and have the client app polling > an endpoint until the authz code is generated and associated to that nonce? > Why that is not a possible approach to get the authz code in the native > client? Is it because the authz server might get several requests during the > app polling? Or I am missing some security issue (assuming this all goes > through TLS)?
There is device profile extension and it works similar to what you describe above: http://tools.ietf.org/html/draft-recordon-oauth-v2-device-00 The device profile can be used by native apps as well, but the profile as a security issue similar to OAuth 1.0 vs OAuth 1.0a. An attacker can start the flow then save the link that takes the browser to the authorization page and trick another user in following it. When the victim approves, the attacker through polling can bind to his/her account. With the core flows this is much harder since the result cannot be obtained through polling, the browser is redirected to a pre-registered redirect URI (or one matching it). An open redirector must be exploited for similar results. Marius _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
