as I said, it’s a recommendation for anyone using the implicit now. If there are confidential clients out there using implicit (I don’t think there are), it is applicable to them as well.
> Am 25.11.2018 um 20:55 schrieb Rifaat Shekh-Yusef <rifaat.i...@gmail.com>: > > RFC6749, Section 3.1.2.2, implies that Implicit is not limited to public > clients: > > 3.1.2.2. Registration Requirements > The authorization server MUST require the following clients to > register their redirection endpoint: > o Public clients. > o Confidential clients utilizing the implicit grant type. > > > I do not know if anybody is using Implicit with Confidential clients, but > just in case, you might want to make it clear that your recommendations are > specifically for public clients. > > Regards, > Rifaat > > > > >> On Sun, Nov 25, 2018 at 1:41 PM Torsten Lodderstedt >> <tors...@lodderstedt.net> wrote: >> 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 <rifaat.i...@gmail.com>: >> > >> > 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 >> > <tors...@lodderstedt.net> 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 >> > > <hans.zandb...@zmartzone..eu>: >> > > >> > > 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 >> > > <tors...@lodderstedt.net> 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 <gffle...@aol.com>: >> > > >> > >> 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 <ve7...@ve7jtb.com> >> > >>>> : >> > >>>> >> > >>>> 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> >> > >>>>> 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> >> > >>>>> : >> > >>>>> >> > >>>>> 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> >> > >>>>> On Behalf Of Hannes Tschofenig >> > >>>>> Sent: Monday, November 19, 2018 2:34 AM >> > >>>>> To: oauth >> > >>>>> <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 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 list >> > > OAuth@ietf.org >> > > https://www.ietf.org/mailman/listinfo/oauth >> > > >> > > >> > > -- >> > > hans.zandb...@zmartzone.eu >> > > ZmartZone IAM - www.zmartzone.eu >> > >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth >>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
