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 <https://authress.io/>. 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
