These are all good ways to mitigate the issue, but they don't solve it. If you are running third-party scripts on the redirection URI page, all bets are off as to who is going to end up with the access token, authorization code, etc. It is pretty bad security to run any kind of third party code on your login page, which in many cases, the redirection page is (Facebook connect, etc.).
The callback whitelist doesn't really add any protection against this specific leakage given that no large provider has the resources to scan every redirection URI page for third-party scripts, analyze them, and block such URIs (and do this continuously to monitor changes). What these alternatives do is reduce the likelihood of a leaked credential being abused, but they are still going to be exposed if all you change is the flow, not the redirection URI page. EHL From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Eaton Sent: Wednesday, July 06, 2011 1:42 PM To: Justin Richer Cc: Kushal Dave; oauth@ietf.org Subject: Re: [OAUTH-WG] Concerns about Implicit Grant flow On Wed, Jul 6, 2011 at 1:31 PM, Justin Richer <jric...@mitre.org<mailto:jric...@mitre.org>> wrote: You can still use the access code (web server) flow within a JavaScript application, just without a reliable client secret. The point of the "implicit" flow was to save a roundtrip to the server for light clients with limited lifespans, and it's a tradeoff between security, ease of implementation, and performance. Yep. Two other options. - give out authorization codes via the user-agent flow. We've implemented a variation of this based on HTML5 and window.postMessage. - use a fixed callback URL for the user-agent flow. Make sure that fixed callback URL does not run random bits of script. Then have that fixed callback URL use javascript to convey the token to other pages on the same origin. It's a bad idea to use the user-agent flow without a specific whitelist of callback URLs which can receive the token.
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
