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 <[email protected]> On Behalf Of Hannes Tschofenig
Sent: Monday, November 19, 2018 2:34 AM
To: oauth <[email protected]>
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
[email protected]
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to