On Tue, Nov 20, 2018, 6:25 AM <oauth-requ...@ietf.org wrote:
> Send OAuth mailing list submissions to > oauth@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/oauth > or, via email, send a message with subject or body 'help' to > oauth-requ...@ietf.org > > You can reach the person managing the list at > oauth-ow...@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OAuth digest..." > Today's Topics: > > 1. Re: draft-parecki-oauth-browser-based-apps-00 (Aaron Parecki) > 2. Re: OAuth Security Topics -- Recommend authorization code > instead of implicit (Torsten Lodderstedt) > 3. Dynamic Client Registration - client_secret_expires_at > (Filip Skokan) > 4. Re: OAuth Security Topics -- Recommend authorization code > instead of implicit (Neil Madden) > > > > ---------- Forwarded message ---------- > From: Aaron Parecki <aa...@parecki.com> > To: OAuth WG <oauth@ietf.org> > Cc: > Bcc: > Date: Mon, 19 Nov 2018 18:09:03 -0800 > Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00 > On Wed, Nov 7, 2018 at 7:20 AM Joseph Heenan <jos...@authlete.com> wrote: > > >> It may be worth slightly rewording 7..2 as it may encourage a growing >> misconception that all native apps must be public clients. With many >> devices now having embedded HSMs, we’ve seen increasing interest in mobile >> apps being dynamically (per-install) registered oauth2 private clients, and >> that model has a lot of advantages. (I’m not sure if we might see a similar >> model evolving for web apps.) >> > > That's a great point, thanks. I've removed the reference to native apps > being public clients since it doesn't really add anything to this spec if I > have to caveat the description. > > On Thu, Nov 15, 2018 at 12:58 PM Torsten Lodderstedt < > tors...@lodderstedt.net> wrote: > > > > First of all the AS decides whether it issues refresh tokens or not. >> Having the ability does not mean the AS must do it. If you feel it’s safer >> to not do it. Fine. >> > Sure, and this should be mentioned then somewhere (either in the >> threats doc or in this proposed best practice doc). Not all end developers >> using these protocols fully understand the ramifications. >> @Aaron: I suggest this goes to the SPA BCP since this is client specific.. > > > Thanks, I agree that this document should include some recommendations > around refresh token handling. Looking at the discussion in this thread, it > seems there are a few different strategies folks are taking. Since it seems > like there isn't a strong consensus, it sounds like this would be better > suited for the "Security Considerations" section, and to not make > MUST/SHOULD recommendations, but rather just point out the issues. Any > thoughts on that before I take a stab at writing something? > > I've incorporated some of the other feedback here and published an updated > version: > > https://tools.ietf.org/html/draft-parecki-oauth-browser-based-apps-01 > > Thanks for the feedback so far. > > --- > Aaron Parecki > https://aaronparecki.com > > > > ---------- Forwarded message ---------- > From: Torsten Lodderstedt <tors...@lodderstedt.net> > To: Mike Jones <Michael.Jones=40microsoft....@dmarc.ietf.org> > Cc: Hannes Tschofenig <hannes.tschofe...@arm.com>, oauth <oauth@ietf.org> > Bcc: > Date: Tue, 20 Nov 2018 08:35:17 +0100 > Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization > code instead of implicit > 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 > > > > > ---------- Forwarded message ---------- > From: Filip Skokan <panva...@gmail.com> > To: oauth <oauth@ietf.org> > Cc: > Bcc: > Date: Tue, 20 Nov 2018 12:44:50 +0100 > Subject: [OAUTH-WG] Dynamic Client Registration - client_secret_expires_at > Hi all, > > a recent query about expiring client credentials (secrets) got me thinking > about client_secret_expires_at client metadata from RFC 7591 used also in > 7592 as well as OpenID Connect Dynamic Client Registration 1.0 > > *What does expired client secret (in the sense of client_secret_expires_at > with a non 0 value) mean beyond obviously not processing secret-based > client authentication (basic, post and client_secret_jwt) after the given > timestamp?* *Fingers Crossed* I'm hoping for your comments and experience > from existing deployments on the topic to shed some light on this for me > and maybe others too. Also that this doesn't get lost between the current > BCP/implicit discussions. > > This is my best shot at an implementable policy when it comes to clients > with expired client secrets: *"all operations requiring a secret will be > rejected when an expired one is presented"* > > - it is not valid for client secret based endpoint auth (basic, post, > client secret jwt), the AS will reject with 401 invalid_client in those > cases > - it will not be used for validating symmetrically signed request > object (JAR), the AS will reject the authorization request with ...? > - it will not be used by the AS to symmetrically sign id tokens, > userinfo, introspection or authorization responses (JARM), the AS will > reject the requests with ...? > - anything else? > > > > I feel this is reasonable interpretation and if so, are there appropriate > errors to return to clients (both front and back-channel) when an expired > secret is encountered during one of the operations that need it? > > Thank you very much for your thoughts and comments. > > Best, > Filip > > > > ---------- Forwarded message ---------- > From: Neil Madden <neil.mad...@forgerock.com> > To: Torsten Lodderstedt <tors...@lodderstedt.net> > Cc: Mike Jones <Michael.Jones=40microsoft....@dmarc.ietf.org>, oauth < > oauth@ietf.org> > Bcc: > Date: Tue, 20 Nov 2018 12:24:55 +0000 > Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization > code instead of implicit > I think the draft should elaborate more on what it means by “token replay” > in section 2.2 and how the proposal to use sender-constrained tokens > prevents it. As far as I can tell, of the 4 methods presented in section > 3.8.1.2, only jpop signed requests actually includes any specific > countermeasure for replay (in the form of negotiated nonces). > > If we are discussing this in the context of client-side web apps/SPAs, > then surely the threat model includes malicious 3rd party scripts - for > which neither token binding nor mTLS constrained tokens are very effective > as those scripts run in the same TLS context as the legitimate client? > > — Neil > > > On 20 Nov 2018, at 07:35, Torsten Lodderstedt <tors...@lodderstedt.net> > 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
