Konubinix' opinionated web of thoughts

Backend for Frontend

Fleeting

One of the ways to mitigate the impact of XSS on public client, described in Forget about OAuth 2.0. Here comes OAuth 2.1 - Philippe De Ryck - NDC Oslo 2022.

The backend is a proxy that keeps a session open with the client and stores secretly its client secret and proxies the requests to the resource server.

This only mitigates XSS, because there is no silver bullet and you should definitely focus on XSS. It reduces the impact of XSS attacks, because no access token can leak this way.

The client session with the BFF may be stored in a secured https only cookie that even the javascript side cannot access.

This mitigates the risks linked to XSS, because the XSS cannot steal the cookie. They only can do nasty stuff inside the client session on the user browser.

Note that we can do that here because the cookie is linked to the one-to-one connection between the client and its BFF. We cannot do the same with access token because they are a connection between three parties: the client, the authorization server and the resource server. It would need the authorization server to be able to store a cookie to be send to the resource server. That is currently impossible.

using a service worker (web worker) instead

A web worker has a dedicated local storage. Therefore, you can put the logic of getting the access token in the web worker and use messages to perform connections to the resource server. Like in the BFF this ensures that the access token won’t leak.

This is the advantage that you can focus on putting the minimum amount of code in the web worker to make the XSS attack surface as small as possible.

If you use service workers, you can also make this transparent and catch the connections to the resource server and add the access token on the fly.

This is less secure than a BFF that could stop forwarding the connection in case of a problem, but it is a nice compromise.

Notes linking here