Better support for scenarios for SPA hosted in WebAPI without JWT tokens in the browser?

Question

At my company, most of our apps (100+) are SPAs using an OpenIDConnect auth server, talking with their APIs with JWT tokens.
They use some javascript oidc library to retrieve the access tokens from the authority.

However, we might want to go away from that model, for 2 main reasons :

• It doesn't work when third party cookies are blocked (which is starting to be popular among companies, using GPOs to enforce it) when using different domains between the app and the oidc authority.
• The OIDC community is pushing refresh tokens out of the browser : A Critical Analysis of Refresh Token Rotation in Single-page Applications and Securing SPAs using the BFF Pattern (once and for all)

One of the solution is using a BFF between the app and the api, however, we would want to avoid that when it is not necessary, because it's simpler to deploy, and cheaper to host.

That means hosting your SPA in the same app than your API, but that scenario isn't what the aspnetcore team seems to recommand (based on answers I read on the github issues), and requires a few hacks to make it work.

Will that type of scenario be better supported in the future or would you recommand a different approche altogether?

Answer 1

See the new reverse proxy made for this case

https://devblogs.microsoft.com/dotnet/announcing-yarp-1-0-release/

Note: I always proxy my spas via the hosting server typically via /api. If using node to host, this is pretty typical.

Answer 2

I've seen YARP's release but I still wonder what would the hosting model be like in that case?
I want to avoid having to host 2 webapp in my cloud provider to avoid paying 2x what I need to.

Are you suggesting this (apologies for the bad drawing) ?

Answer 3

You question concerned issues when the SPA called a webapi which was not the hosting website. The proxy can used in this case. The standard .net SPA template is a webapi hosting the SPA static site.

In general monolithic webapi’s are discouraged, as there tends to be too much coupling and scaling may be effected. But if it’s a small site and costs are a concern than a single site makes sense. But if hosting in AWS or Azure, then lambda or azure functions may be an option as they are low cost.