Hi Bill, I'm not sure if I have permission to post to the OAuth list. Anyway, if your page that does the OAuth processing includes third party scripts, then those scripts will probably have access to the code, client secret, and access token. I believe this concern is addressed in the security section of RFC 6749.
E. Anwar Reddick Research Scientist Georgia Tech Research Institute ----- Reply message ----- From: "Bill Burke" <bbu...@redhat.com> To: "John Bradley" <ve7...@ve7jtb.com> Cc: "oauth@ietf.org" <oauth@ietf.org> Subject: [OAUTH-WG] Confusion on Implicit Grant flow Date: Mon, Feb 9, 2015 5:33 PM On 2/9/2015 5:03 PM, John Bradley wrote: > OK, I don't know if the WG has discussed the issue of fragments in browser > history. > > So you are trading off several round trips against the possibility of a token > leaking in browser history or bookmark? > Yes, bookmarking tokens is a little scary, IMO, as we've already run into users bookmarking URLs with codes in them. Also, wasn't there additional security vulnerabilities surrounding implicit flow? Maybe these were just the product of incorrect implementations, I don't remember, it was a while ago. > One extension that Connect introduced was a "code id_token" response type > that is fragment encoded. That would let you pass the code directly to the > JS saving two legs. > It looks like OIDC added a "response_mode" parameter where you can specify "query" or "fragment". Thanks for pointing this out! Thanks for all the help. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
