I support the move away from the implicit flow toward using the authorization code flow (with PKCE and CORS) for JavaScript applications. The limitations and assumptions that surrounded the design of the implicit flow back when we started no longer apply today. It was an optimization for a different time. Technology and platforms have moved forward, and our advice should move them forward as well. Furthermore, the ease of using the implicit flow incorrectly, and the damage that doing so can cause, has driven me to telling people to stop using it.
There are a number of hacks that can patch the implicit flow to be slightly better in various ways — if you tack on the “hybrid” flow from OIDC or JARM plus post messages and a bunch of other stuff, then it can be better. But if you’re doing all of that, I think you really need to ask yourself: why? What do you gain from jumping through all of those hoops when a viable alternative sits there? Is it pride? I don’t see why we cling to it. To me, it’s like saying “hey sure my leg gets cut off when I do this, but I can stitch it back on!”, when you could simply avoid cutting your leg off in the first place. The best cure is prevention, and what’s being argued here is prevention. So many of OAuth’s problems in the wild come from over-use of the front channel, and any place we can move away from that is a good move. — Justin On Nov 19, 2018, at 5:34 AM, Hannes Tschofenig <hannes.tschofe...@arm.com<mailto:hannes.tschofe...@arm.com>> wrote: Hi all, The authors of the OAuth Security Topics draft came to the conclusion that it is not possible to adequately secure the implicit flow against token injection since potential solutions like token binding or JARM are in an early stage of adoption. For this reason, and since CORS allows browser-based apps to send requests to the token endpoint, Torsten suggested to use the authorization code instead of the implicit grant in call cases in his presentation (see https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-ietf-oauth-security-topics-01). A hum in the room at IETF#103 concluded strong support for his recommendations. We would like to confirm the discussion on the list. Please provide a response by December 3rd. Ciao Hannes & Rifaat IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
