My understanding was that the scope of the discussion was limited to OAuth, and does not cover OpenID Connect ID Tokens. With that in mind, I support the recommendation to use the authorization code instead of the implicit flow.
---- Aaron Parecki aaronparecki.com @aaronpk <http://twitter.com/aaronpk> On Mon, Nov 19, 2018 at 2:13 PM Mike Jones <Michael.Jones= 40microsoft....@dmarc.ietf.org> wrote: > This description of the situation is an oversimplification. OpenID > Connect secures the implicit flow against token injection attacks by > including the at_hash (access token hash) in the ID Token, enabling the > client to validate that the access token was created by the issuer in the > ID Token (which is also the OAuth Issuer, as described in RFC 8414 > <https://tools.ietf.org/html/rfc8414>). (Note that this mitigation was > described in draft-ietf-oauth-mix-up-mitigation > <https://tools.ietf.org/html/draft-ietf-oauth-mix-up-mitigation-01>.) > > > > Given the prevalence of this known-good solution for securing the implicit > flow, I would request that the draft be updated to describe this > mitigation. At the same time, I’m fine with the draft recommending the > code flow over the implicit flow when this mitigation is not used. > > > > Thank you, > > -- Mike > > > > *From:* OAuth <oauth-boun...@ietf.org> *On Behalf Of * Hannes Tschofenig > *Sent:* Monday, November 19, 2018 2:34 AM > *To:* oauth <oauth@ietf.org> > *Subject:* [OAUTH-WG] OAuth Security Topics -- Recommend authorization > code instead of implicit > > > > 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 > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
