Do you eliminate the cookies too? > On 17 Feb 2021, at 19:50, Dominick Baier <dba...@leastprivilege.com> wrote: > > > Well. Maybe it is at least worth while then to at least mention that you > could also take a slightly different approach and eliminate all tokens in the > browser - with the respective trade offs. > > ——— > Dominick Baier > >> On 17. February 2021 at 20:46:42, Warren Parad (wpa...@rhosys.ch) wrote: >> >>> While someone will always say “but this doesn’t solve the XSS problem” - >>> this is absolutely correct. But when there are no tokens in the browser - >>> you can simply eliminate that part of the threat model ;) >> The point was it doesn't eliminate anything, it just changes the >> request/response data that is part of the attack. This doesn't increase >> security, as a matter of fact, with regard to the RFC, we shouldn't talk >> about security at all, since it has zero impact on it. >> >> It is worth talking about that pattern as one possible solution to >> maintaining sessions, but that's it. >> >> >> Warren Parad >> Founder, CTO >> Secure your user data with IAM authorization as a service. Implement >> Authress. >> >> >>> On Wed, Feb 17, 2021 at 8:43 PM Dominick Baier <dba...@leastprivilege.com> >>> wrote: >>> Yes - “no OAuth tokens in the browser” ;) They are all kept server-side and >>> the BFF proxies the API calls if necessary. Also the RT management happens >>> server-side and is transparent to the SPA. >>> >>> I see that in lots of industries - finance, health, cloud providers >>> >>> While someone will always say “but this doesn’t solve the XSS problem” - >>> this is absolutely correct. But when there are no tokens in the browser - >>> you can simply eliminate that part of the threat model ;) >>> >>> ——— >>> Dominick Baier >>> >>>> On 17. February 2021 at 18:30:23, Vittorio Bertocci >>>> (vittorio.berto...@auth0.com) wrote: >>>> >>>> Thanks Dominick, >>>> >>>> It is indeed a very simple spec, but as you can see from the discussion so >>>> far, it doesn’t appear to be trivial- and there might be some >>>> considerations we consider obvious (eg scope escalation) that might not be >>>> super clear otherwise. >>>> >>>> In terms of the guidance, just to make sure I get the scope right- that >>>> means that also code+PKCE+rotating RTs in JS would not be acceptable for >>>> your customers? >>>> >>>> >>>> >>>> From: Dominick Baier <dba...@leastprivilege.com> >>>> Date: Wednesday, February 17, 2021 at 00:27 >>>> To: Brian Campbell <bcampb...@pingidentity.com>, Torsten Lodderstedt >>>> <tors...@lodderstedt.net> >>>> Cc: Vittorio Bertocci <vittorio.berto...@auth0.com>, "oauth@ietf.org" >>>> <oauth@ietf.org> >>>> Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend >>>> For Frontend (TMI BFF) >>>> >>>> >>>> >>>> Hey, >>>> >>>> >>>> >>>> Tbh - I have a bit of a hard time to see why this requires a spec, if that >>>> is all you are aiming at. Wouldn’t that be just an extension to the “OAuth >>>> for web apps BCP?”. >>>> >>>> >>>> >>>> All I can add here is - this approach would not work for any of our >>>> customer. Because their real motivation is to implement a more and more >>>> common security guideline these days - namely: “no JS-accessible tokens in >>>> the browser” - but this document doesn’t cover this. >>>> >>>> >>>> >>>> cheers >>>> >>>> ——— >>>> >>>> Dominick Baier >>>> >>>> >>>> >>>> On 16. February 2021 at 22:01:37, Brian Campbell >>>> (bcampbell=40pingidentity....@dmarc.ietf.org) wrote: >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Mon, Feb 15, 2021 at 9:48 AM Torsten Lodderstedt >>>> <tors...@lodderstedt.net> wrote: >>>> >>>> Thank you again for the explanation. >>>> >>>> I think your assumption about the overall flow should be described in the >>>> draft. >>>> >>>> >>>> >>>> We did attempt to capture the assumptions in the draft but clearly could >>>> have done a better job with it :) >>>> >>>> >>>> >>>> >>>> As I understand it now the core contribution of your proposal is to move >>>> refresh token management from frontend to backend. Is that correct? >>>> >>>> >>>> >>>> Taking that a bit further - the idea is that the backend takes on the >>>> responsibilities of being a confidential client (client creds, token >>>> acquisition, token management/persistence, etc.) to the external AS(s). >>>> And TMI BFF describes a way for that backend to deliver access tokens to >>>> its own frontend. >>>> >>>> >>>> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged >>>> material for the sole use of the intended recipient(s). Any review, use, >>>> distribution or disclosure by others is strictly prohibited. If you have >>>> received this communication in error, please notify the sender immediately >>>> by e-mail and delete the message and any file attachments from your >>>> computer. 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
-- ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
