You mean all but the access token and authorization code, right? 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:50 PM 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 <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
