Hi Rifaat, this is a recommendation to anyone using implicit now. Implicit can only be used with public clients, so one could interpret it that way. I could also envision a SPA to use a backend, which in turn is a confidential client. There were some posts about this topic on the list recently.
Does this answer your question? kind regards, Torsten. > Am 25.11.2018 um 19:22 schrieb Rifaat Shekh-Yusef <[email protected]>: > > Hi Torsten, > > I am assuming that these recommendations are mainly for Public Clients, not > Confidential Clients; is that correct? > > Regards, > Rifaat > > > On Sun, Nov 25, 2018 at 12:33 PM Torsten Lodderstedt > <[email protected]> wrote: > Hi all, > > I would like to state again what the proposal of the authors of the Security > BCP is: > > Here is the respective text from the draft: > > —— > > 2.1.2. Implicit Grant > > The implicit grant (response type "token") and other response types > causing the authorization server to issue access tokens in the > authorization response are vulnerable to access token leakage and > access token replay as described in Section 3.1, Section 3.2, Section 3.3, > and Section 3.6. > > Moreover, no viable mechanism exists to cryptographically bind access > tokens issued in the authorization response to a certain client as it > is recommended in Section 2.2. This makes replay detection for such > access tokens at resource servers impossible. > > In order to avoid these issues, Clients SHOULD NOT use the implicit > grant or any other response type causing the authorization server to > issue an access token in the authorization response. > > Clients SHOULD instead use the response type "code" (aka > authorization code grant type) as specified in Section 2.1.1 or any > other response type that causes the authorization server to issue > access tokens in the token response. This allows the authorization > server to detect replay attempts and generally reduces the attack > surface since access tokens are not exposed in URLs. It also allows > the authorization server to sender-constrain the issued tokens. > —— > > In my observation, discouraging implicit seems to be the less controversial > issue. > > „or any other response type causing the authorization server to issue an > access token in the authorization response.“ in the 3rd paragraph caused > discussions because it suggests to discourage developers from using ANY > response type issuing access tokens in the authorization response. This > includes OIDC’s response types „token id_token“, „code token“ & „code token > id_token“, where at least „token id_token“ is used in the wild to implement > SPAs. > > Why did we come up with this proposal given at least „token id_token“ & „code > token id_token“ protect against injection? > > Two reasons: > > 1) „token id_token“ does not support sender constrained tokens. Also use of > refresh tokens to frequently issue new live-time and privilege restricted > access tokens is not supported. „code token id_token“ seems more complex than > just „code“+pkce for achieving the same goal. > > 2) Protection against token leakage is rather thin and fragile. There is just > a single line of defense (CSP, open redirection prevention, browser history > manipulation) implemented by the client. > > Daniel and I collected some more information and argument at > https://github.com/tlodderstedt/oauth2_spa/blob/master/README.md that you > might like to give a read. > > My conclusion after 2 weeks of intensive discussions with SPA developers > (mostly on twitter): code+pkce is the more secure, simpler, and more > versatile approach to (also) implement SPAs. I prefer to approach developers > with a clean and robust message instead of a lengthy description of what > needs to go right in order to secure a SPA using OAuth. That’s why I think > code+pkce should be the recommendation of our working group. > > So please vote in favor of our proposal. I think that’s a huge improvement > for OAuth. > > kind regards, > Torsten. > > > > Am 25.11.2018 um 12:55 schrieb Hans Zandbelt <[email protected]>: > > > > 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]>: > > > >> 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 > >> > > _______________________________________________ > > 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
