Discussing the usage of localStorage/sessionStorage for session management

[randomstuff]

The BFF and the Token Mediating pattern assume that cookies are used for user session tracking:

The BFF relies on traditional browser cookies to keep track of the user's session, which is used to access the user's tokens.

Similar to the BFF, the token-mediating backend relies on traditional browser cookies to keep track of the user's session.

Some applications (SPAs) might want to rely on storing a session token in localStorage/sessionStorage and use Authorization: Bearer for passing the session token to the backend. Should some wording discussing this be included?

This is only discussed in the context of the storage of the access/refresh tokens in the browser (for the token mediating backed and browser-based OAuth 2.0 client patterns).

[philippederyck]

Only by using cookies as discussed in the document can you get the security guarantees offered by the BFF. Making the BFF session data accessible to JavaScript would negate the majority of the security benefits of the BFF. There would also be little to no technical reason to do this, since cookies are universally supported by browsers and do not require any code.

[randomstuff]

Only by using cookies as discussed in the document can you get the security guarantees offered by the BFF.

The BFF interacts with the authorization server as a confidential OAuth client

The client credentials are still not exposed to the user agent and the client.

The BFF manages OAuth access and refresh tokens in the context of a cookie-based session, avoiding the direct exposure of any tokens to the JavaScript application

You still wouldn't expose the OAuth access/refresh tokens which would otherwise be visible by the frontend (i.e. by the frontend code and by the actual end user).

There would also be little to no technical reason to do this, since cookies are universally supported by browsers and do not require any code.

HttpOnly cookies are isolated from frontend JavaScript and therefore protected from exfiltration through XSS. However, they are are (still) not origin-bound which makes them vulnerable from cross-origin/same-domain injection (such as session fixation).

• You can use __Host- cookies to protect against cross-origin/same-domain cookie injection but this is very rarely used in practice and would not work if the frontend and the backend are in different origins.
• You can use __Secure- cookies to protect against cookie injection from non-secured origins in the same domain.

localStorage is origin-bound and is inherently protected from these things.

I'm not sure that this would really negate the majority of the security benefits of the BFF.

[philippederyck]

The client credentials are still not exposed to the user agent and the client.

You still wouldn't expose the OAuth access/refresh tokens which would otherwise be visible by the frontend (i.e. by the frontend code and by the actual end user).

Yes, that's true, but the security properties are still worse than having a cookie-based BFF solution. As described in the spec, the BFF reduces the attack surface to a client hijacking attack (in an online fashion, where the attack only works as long as the application is active). By having the session accessible to the frontend (and thus malicious JS), you would enable a scenario that is best described as offline client hijacking. The attacker would be able to steal the BFF's session data and abuse it for as long as the session is active, even after the user has closed the application (but not logged out).

I would even say that the security properties of this setup are worse than using the Token Mediating Backend, since the BFF session is likely longer-lived than the access tokens in a Token Mediating Backend solution.

Concretely, I don't think this pattern improves anything or warrants a recommendation.

There would also be little to no technical reason to do this, since cookies are universally supported by browsers and do not require any code.

HttpOnly cookies are isolated from frontend JavaScript and therefore protected from exfiltration through XSS. However, they are are (still) not origin-bound which makes them vulnerable from cross-origin/same-domain injection (such as session fixation).

• You can use __Host- cookies to protect against cross-origin/same-domain cookie injection but this is very rarely used in practice ~and would not work if the frontend and the backend are in different origins~.
• You can use __Secure- cookies to protect against cookie injection from non-secured origins in the same domain.

localStorage is origin-bound and is inherently protected from these things.

I'm not sure that this would really negate the majority of the security benefits of the BFF.

I don't think these statements help prove your point. I will list a couple of reasons below:

• The __Host- prefix is explicitly recommended by the spec. The fact that it is not often used does not impact its security properties.
• The __Host- prefix explicitly prevents setting a cookie from a different domain (i.e., it neutralizes the Domain attribute and effectively prevents subdomain-based session fixation)
• Nothing prevents the use of the __Host- prefix from being used between two different origins or even domains. The SameSite flag can affect this, and so does third-party cookie blocking, but not the __Host- prefix.
• A cookie configured with __Host- also requires the Secure flag, making them mostly origin-bound (to be precise: ports are part of the origin and are not taken into account with this prefix, but most real-world deployments rely on default ports anyway)

If you are not convinced that I am right, I encourage you to try this out in an actual deployment, to help you understand the precise browser behavior.

[randomstuff]

Concretely, I don't think this pattern improves anything or warrants a recommendation.

Note that stating this explicitly would actually count as "discussing the usage of localStorage/sessionStorage for session management" :) I mean, people will wonder about this and will want to try to implement these patterns using localStorage instead of cookies. It might be a good idea to mention these arguments in a short paragraph (?).

If you are not convinced that I am right, I encourage you to try this out in an actual deployment, to help you understand the precise browser behavior.

Yes agreed.