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 <gffle...@aol.com 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 <oauth-boun...@ietf.org> <oauth-boun...@ietf.org> *On > Behalf Of * John Bradley > *Sent:* Tuesday, November 20, 2018 7:47 AM > *To:* oauth@ietf.org > *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 > <Michael.Jones=40microsoft....@dmarc.ietf.org> > <Michael.Jones=40microsoft....@dmarc.ietf.org>: > > > > 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 <oauth-boun...@ietf.org> <oauth-boun...@ietf.org> On Behalf Of > Hannes Tschofenig > > Sent: Monday, November 19, 2018 2:34 AM > > To: oauth <oauth@ietf.org> <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 > (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 > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
