Show HN: Front end-Only-Authorization – A new web standard(foaz.io)
foaz.io
Show HN: Front end-Only-Authorization – A new web standard
https://foaz.io/
23 comments
Yep, checkout the BYOD page: https://foaz.io/use-foaz/byod
Reverse-proxy + Policy-as-Code-Engine + Secrets Vault == FoAz
Seems more of a generic authorization proxy rather than anything frontend related. Useful but "front-end only" doesn't seem to to accurate
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.
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.
So first impression: isn't the FoAz proxy simply the backend? I apologize it that seems like a dumb question, I never used oauth or jwt.
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
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
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.
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 ;-)
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
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
Good catch, I think that built-in data filtering can actually be a good addition to this new standard. I imagine a rego rule in OPA (or any other policy language) can accept the result json and modify it in place before sending the sanitized/filtered response back to the frontend client.
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.
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.
> 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.
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.
If you don't own the authorization backend, how can an application guarantee data safety and ownership?
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.
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.
> Meaning, you don't have to physically be the guard at the door, to know your door is guarded.
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.
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.
: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)
source: https://owasp.org/Top10/A01_2021-Broken_Access_Control/
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/
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.
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.
That sounds more like Authentication (verify identity) than Authorization (decide specifically what they are allowed to do per request), no?
Without identity, how would you decide if a user can access a resource or not?
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 [email protected] (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.
e.g. You are [email protected] (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.
Hi HackerNews, Or from permit.io here, happy to discuss and answer questions here about the concept of FoAz and its RFC.
OAuth can already work without a backend...
Looks like it's some kind of authorization proxy.