We had a discussion about this topic on Twitter https://twitter.com/Apl3b/status/1064854507606208513
Outcome is POST requires a backend to receive the request so it’s not a viable solution for SPAs. > Am 20.11.2018 um 23:29 schrieb John Bradley <[email protected]>: > > Post response works OK for server based clients. I don't think POST works > for single page applications. > > Basically that would be something more like postmessage between two JS apps. > > Postmessage also has security issues passing a access token and leaking. > > Perhaps someone more familiar with SPA can comment on POST. > > John B. > > > > On Tue, Nov 20, 2018, 6:40 PM George Fletcher <[email protected] wrote: > Hi Mike, > > The Form Post Response Mode keeps the access_token out of the URL, but it > doesn't prevent the token from traversing through the browser. So a > man-in-the-browser attack may be able to intercept the values. It should help > with leakage in logs. > > Thanks, > George > > On 11/20/18 4:00 PM, Mike Jones wrote: >> Next question – doesn’t using the Form Post Response Mode >> https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html mitigate >> the threats you’re describing below John? If so, I believe the Security >> Topics draft should say this. >> >> >> >> I believe we owe it to readers to present the complete picture, which is why >> I believe that describing profiles using ID Tokens and the Form Post >> Response Mode are in scope. >> >> >> >> -- Mike >> >> >> >> From: OAuth <[email protected]> On Behalf Of John Bradley >> Sent: Tuesday, November 20, 2018 7:47 AM >> To: [email protected] >> Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization >> code instead of implicit >> >> >> >> Yes the at_hash protects the client from accepting an injected AT. >> >> Unfortunately it doesn't do anything to protect against leakage in logs or >> redirects. >> >> So without the AT using some sort of POP mechanism it is hard to say sending >> it in a redirect is a good security practice. >> >> John B. >> >> On 11/20/2018 4:35 AM, Torsten Lodderstedt wrote: >> >> Hi Mike, >> >> I agree that OIDC hybrid flows offer additional security over the OAuth >> implicit grant and are used in the wild. On my slides and in the initial >> version of the new section, we had included the hybrid OIDC flows because of >> their known token injection countermeasures. >> >> I nevertheless feel very uncomfortable to recommend those flows and any flow >> issuing access tokens in the front channel. In the course of the detailed >> review of the new text we realized two issues: >> >> 1) Since the access token is exposed in the URL, such flows possess a >> significantly higher risk to leak the access token (e.g. through browser >> history, open redirection and even referrer headers) than the code grant. >> 2) There is no viable way to sender constrain access tokens issued in the >> front channel. Given the WG decided to recommend use of sender constraint >> tokens >> (https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2...2), >> it seems contradictory to recommend response types not supporting such an >> approach. >> >> kind regards, >> Torsten. >> >> Am 19.11.2018 um 23:13 schrieb Mike Jones >> <[email protected]>: >> >> 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). (Note that this >> mitigation was described in draft-ietf-oauth-mix-up-mitigation.) >> >> 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 >> (seehttps://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 >> >> >> >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> _______________________________________________ >> OAuth mailing list >> >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
