The latest guidance from the IETF is that SPA applications which have a back-end should use the Backend for Frontend (BFF) architectural pattern. In this approach, the back-end can help out the front-end with many security related tasks such as protocol flow, token storage, token lifetime management, session management etc... This latest guidance takes advantage of the modern security features in browsers such as SameSite cookies and CORS and delivers on the goal of "no tokens in the browser" which is intended to mitigate the threat of token exfiltration on the front-end. Storing tokens on the server-side and using encrypted/signed HTTP-only cookies for session management makes that threat model easier to manage.
The advantages to the BFF approach include:
- Single trusted application (reduced attack surface)
- Trusted client protected with a secret or certificate
- No access/reference tokens in the browser
- No refresh token in the browser
- Web sockets security improved (SignalR), no access/reference token in the URL
- Backchannel logout, SSO logout possible
- Improved CSP and security headers (better protection against XSS)
- Can use MTLS, OIDC FAPI, client binding for all downstream API calls from trusted UI app
- No architecture requirement for public APIs outside same domain, downstream APIs can be deployed in a private trusted zone.
- Easier to build, deploy
- Reduced maintenance due to reduced complexity
Oqtane uses a Backend for Frontend (BFF) architectural approach - both when running on Blazor WebAssembly and Blazor Server. BFF is a natural fit for Oqtane as it uses the .NET Core Hosted approach so that it can support features such as pre-rendering and dynamic content capabilities as part of the initial page request.
