Or from Permit.io here :) - we support OPA, Cedar, as well as Amazon Verified Permissions, and we'll be coming out with more soon.
Both in Permit.io and in OPAL 1
Graham from OSO (gneray) - just didn't see the recent news, I guess we'd need to speed up OSO support as well ;-)
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 ;-)
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)
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.
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.
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
I agree with you re:"I wouldn't say Cedar is directly competitive as SpiceDB" - I think Zanzibar and SpiceDB in particular can work well together with Cedar / OPA. By syncing SpiceDB via OPAL[0] into edge nodes with Cedar-agents[1].
Hi Dang, apologize- we didn't plan anything here - simply a few friends / supporters in our community that were a little too eager to help.
If we do post again, I'll figure a way to calm the enthusiasm.
Also sorry fro the late reply - different timezones.
Graham from OSO (gneray) - just didn't see the recent news, I guess we'd need to speed up OSO support as well ;-)
1 - https://docs.opal.ac/tutorials/cedar