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]>: > > 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]>: >>>> >>>> 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
