Backend for Frontend (BFF) Security Framework
"No tokens in the browser" policy
It’s not only your own code that must be XSS-proof. It’s also all the frameworks, libraries, and NPM packages you are pulling in (as well as their dependencies). And even worse, you have to worry about other people’s code running on your domain.
Storing tokens on the server-side and using encrypted/signed HTTP-only cookies for session management makes that threat model considerably easier. This is not to say that this makes the application “auto-magically” secure against content injection, but forcing the attacker through a well-defined interface to the back end gives you way more leverage than being able to make arbitrary API calls with a stolen token.
Browsers are already (and will be even more in the future) restricting the usage of cookies across site boundaries to protect users from privacy invasion techniques. The problem is that legitimate OAuth and OpenID Connect protocol interactions are from a browser’s point of view, indistinguishable from common tracking mechanisms.
To overcome these limitations, we need the help of an application back end to bridge the gap to the authentication system, do more robust server-side token management with refresh tokens, and provide support for more future-proof mechanisms like back-channel logout notifications.
Resilient to changes in browser security models
Simplify front-end code and make use of server-side security features
On the server-side, though (and especially with ASP.NET Core), we have a fully featured and stable OpenID Connect client library that supports all the necessary protocol mechanisms and provides an excellent extensibility model for advanced features like Mutual TLS, Proof-of-Possession, JWT secured authorization requests, and JWT-based client authentication.
Putting your requirements in the center is our motivation.