It's actually a good question :)
It is the backend - but a generic backend as opposed to a specially tailored open per case.
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
IMHO the best way to do authorization if your application otherwise works completely in the frontend:
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.
Of course you need identity (FoAz uses JWTs from authN solutions - can also be your VM (if it produces a JWT as it's magic link process)) , but Authorization is another step on top.
e.g. You are Dave@customer.io (or some other verified identity), I know you, but how many SMS messages should I allow you to send via Vonage or Twilio when you click the button in the app? Managing that quota is an example of authorization.
That doesn't change the fact that they're separate but related concerns. Authentication is enforcing that someone is who they say they are, and authorisation is checking that that person is allowed to access a secure resource. Looks like FoAz just solves the authorisation problem, allowing you to use another authentication provider.
You are correct (As this is a generic component), but kinda missing the point ;)
In the backend - you don't need this - there are already solutions you can consume for authorization (OPA, AWS Cedar, Permit.io, ...)
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.
In a sense you do own it, you just delegate it, and thanks to JWT and JWKs you control the identity flow.
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.
:D Truly?
So does that mean you won't use any cloud service (e.g. AWS, GCP, Azure) ? And no Authentication services (e.g. Auth0, AWS Cognito, Firebase)? ...
Yeah truly :) I "may" use Postgres on RDB, but won't use a service they offer I don't know the infra of or be certain if I'm the only one who can access. Definitely non of those auth services you mentioned. Why do you think many people are very much anti mysterious "clouds" and there's general push towards self-hosting from people who know how things work.
It's always a valid choice to build your own, just not cost-efficient for some. It's considered safe to use cloud authentication providers like Okta, Auth0, etc as well as cloud billing providers like Stripe, etc.
An authorization proxy is quite the same, and I would argue that for some teams is much safer to use than building your own AuthZ. Broken access control is the top OWASP risk for a reason (i.e: implementation complexity)
This isn't a new idea. This exact proxy pattern already exists with things like AWS API Gateway Lambda Authorizers.
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.
True a gating reverse proxy isn't a new idea- but combining it with frontend only login, policy as code, and secrets injections from a vault to produce authorization you can use seamlessly from the frontend kinda is ;-)
> It sure sounds like it, but no - it works, it's easy, and it's super safe. The "trick" is that it's frontend-only in the same sense that Serverless has no servers. There is a backend component which actually enforces the access, you just don't have to build it - FoAz is a generic backend component leveraging policy as code together with a reverse-proxy, and secrets management services to produce a one size fits all backend authorization.
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.
21 comments
[ 3.5 ms ] story [ 53.2 ms ] threadTo 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
Looks like it's some kind of authorization proxy.
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.
e.g. You are Dave@customer.io (or some other verified identity), I know you, but how many SMS messages should I allow you to send via Vonage or Twilio when you click the button in the app? Managing that quota is an example of authorization.
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.
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.
An authorization proxy is quite the same, and I would argue that for some teams is much safer to use than building your own AuthZ. Broken access control is the top OWASP risk for a reason (i.e: implementation complexity)
source: https://owasp.org/Top10/A01_2021-Broken_Access_Control/
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
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.