I strongly support the recommendation of using code instead of implicit. I do so based on my own experience in the field [1] and stick to that also after reading the comments and (what I would call) workarounds on this thread.
Hans. [1] https://hanszandbelt.wordpress.com/2017/02/24/openid-connect-for-single-page-applications/ On Thu, Nov 22, 2018 at 5:45 AM Torsten Lodderstedt <[email protected]> wrote: > that’s certainly true, but that might by a web server with static content > only. > > If the server is a real backend, there is even less reasons to use a > implicit or hybrid. No even a performance gain in comparison to code. > > Am 21..11.2018 um 14:24 schrieb George Fletcher <[email protected] > <[email protected]>>: > > An SPA has a backend because it has to be loaded from somewhere :) > > On 11/21/18 3:47 AM, Torsten Lodderstedt wrote: > > 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]> > <[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]> <[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]> > <[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]> <[email protected]> On Behalf Of > Hannes Tschofenig > Sent: Monday, November 19, 2018 2:34 AM > To: oauth <[email protected]> <[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 [email protected]https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing [email protected]https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > [email protected]https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing [email protected]https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > -- [email protected] ZmartZone IAM - www.zmartzone.eu
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
