The security problem was people only doing host name matching on redirect_uri and attackers finding redirectors to use. That impacted all public clients not just implicit. Implicit took most of the heat because that was what Facebook was using, and they had the largest issue.
Connect has a response_mode that allows the response to be form encoded rather than fragment. I read RFC 5849 as only allowing code to be query encoded. The response_mode was intended for the new response types we defined in http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html The spec for response mode is here http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html We haven't done anything with it recently. I don't know if the OAuth WG wants to take it up. John B. > On Feb 9, 2015, at 7:32 PM, Bill Burke <bbu...@redhat.com> wrote: > > > > 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
