On Wed, Jun 1, 2011 at 7:54 PM, Matias Woloski mati...@gmail.com 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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
