Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

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.bertocci@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 <dbaier@leastprivilege.com>
*Date: *Wednesday, February 17, 2021 at 00:27
*To: *Brian Campbell <bcampbell@pingidentity.com>, Torsten Lodderstedt <
torsten@lodderstedt.net>
*Cc: *Vittorio Bertocci <vittorio.bertocci@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.com@dmarc.ietf.org) wrote:

On Mon, Feb 15, 2021 at 9:48 AM Torsten Lodderstedt <torsten@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