This is still quite a useful architecture as it allows the backend to be implemented without concern for authentication or authorization. You just have to make absolutely sure that nobody can reach the backend except via the proxy.
The one downside is that it limits authorization to simple yes/no. The user may proceed with this API call, or they may not. There are occasions where you may want to allow the API call, but alter the results based on authorization.
For example, a user wants to list objects, which you want to allow, but you only want the list to contain objects the user is permitted to view. In this case you can't completely avoid implementing authorization on the backend. The proxy has to tell the backend the user's identity, and the backend has to implement some logic based on that.
As asafc mentions, and as noted in the RFC (https://foaz.io/standard/RFC#foaz-service-reshapes-requests-...) - " Optionally the policy itself could be used to reshape the request." - the policy engine can be used to adjust the api call
This is not very performance efficient though - maybe if the source api supports it, the proxy can inject filters (via headers / query params) to the modified request based on the authorization policy.
Meaning, you don't have to physically be the guard at the door, to know your door is guarded. And you can use passports and well formed policies (ideally as code) to communicate to your guards who to let in, when, and how.
This doesn't translate well to a web app, to guard your data you have to physically have it somewhere where you and only you can access it.
Rent a tiny VM for $5/month and set up a small "enter your email, you'll get a magic link" application you write in Python or PHP.
And proxy whatever API access you want to restrict to authorized users through a simple Python or PHP script which can just be a few lines of code. It looks up the cookie set by the magic link, checks if it is allowed to access the endpoint and if yes proxies the request.
Looks like it's some kind of authorization proxy.
But in the frontend there is nothing you can use, that's what FoAz aims to solve - shift security left to the frontend, reducing dependency on backend engineering.
To clarify - FoAz is frontend only - like Serverless has no servers :D
The idea is that as a FE developer you can consume this as a generic service once and for all, without constantly going back to backend and devops to set up glue code routes.
Feel free to follow up with more questions, especially if I wasn't clear enough
Phew. I was about to blow a gasket.
So, this approach works, but generally either you build a lot of knowledge of apps' resources (URI local-parts and q-params semantics) or you have very coarse-grained authz or you restructure your applications so that a minimal authz language can represent a lot of what you're doing using only URI local-parts.
