Thread by @Auth0Lab

1/ Having analyzed the @github and @googledrive #fgaatscale cases, we'll share our view on the authz market.

We'll go over what is currently being addressed and what the gaps are👇

2/
As we've mentioned before, solving #fgaatscale requires:
1️⃣ Permission modelling flexibility
2️⃣ Auditing capabilities
3️⃣ Correctness: no invalid permissions are granted
4️⃣ Low Latency
5️⃣ High availability

3/ Solving #fgaatscale is becoming a need because:
☝️ Users expect collaboration features in most products they used, and that requires FGA
✌️ Increasing privacy and compliance regulations require companies in different verticals to restrict access as much as possible

4/ As a result, plain old RBAC + Groups and associating those to credentials is no longer viable: auth0.com/blog/on-the-na….

Scopes are the only authz related aspect in #OAuth2.

5/ They are not good for scenarios with:
- Access to specific objects by specific users
- *High change rate*: Keeping the issuer updated when an object access changes is a complex from a scaling and latency PoV.

6/
- *Low value of signed assertions for authz*: Even when an issuer could be kept up to date with the right permissions, emitting a token with the right scopes would be problematic:
- Tokens could be fairly big
- Tokens could get stale fairly fast

7/ On the technical side, the rise of cloud native and SOA/micro-services architectures is resulting in a sprawl of authorization logic across multiple components: a compliance, auditing and enforcement nightmare 🤦‍♀️

8/ Companies offer policy based solutions to "address fine grained authorization" problems. Policies allow decoupling of authz logic and business logic. When combined with solid distribution and approval, they allow companies to fulfill security and compliance requirements.

9/ These products offer:
✍️ Policy authoring using either a (standard or proprietary) policy language or a UI, depending on the target audience (business or devs)
🚛 Policy distribution
🛠 PEP SDKs
📜 Auditing (integrated, log output)
⚙️ Policy execution models: sidecar,…

10/ …separate service.
📡 Some offer the ability to fetch data as part of policy code. In others you have to provide it as execution input
✅ Some offer "what if analysis" and approval flows.

11/ The way we see it, policies provide flexibility, auditing and (partially) correctness. But policy authoring, deployment and enforcement are only half of the problem.

12/ ‼️ What all policy based solutions have in common is that *providing input/context for authz decisions is up to development teams*! Most context is typically stateful, and stateful problems are usually the hardest to solve at scale 👉 a big part of the problem is unsolved.

13/ When talking about data sources a "gray cloud" forms around that area.
- What data do we need?
- Where is it?
- How do we ensure it is available when we need it?
- How can we store authorization data for millions of objects and users?

14/ If low latency, and high availability are requirements to be addressed by at scale FGA solutions, then being able to get data quickly to PEPs/PDPs is a huge part of the problem.

15/ Talking to companies that have to deal with these problems at scale, we are seeing they are all building a centralized authorization system to deal with the 80% in the 80-20% of authorization data and decisions.

16/ 💯 When offering a highly available service, your authorization data needs to be quickly available whenever and wherever you need it.

17/ If you are fetching data from multiple sources
- If any of those are down you can't make authorization decisions
- Your latency depends on your slowest data source

18/ 🌍 Those problems are amplified if your highly available service is deployed across multiple geographical regions for both latency and availability reasons.

19/ It means each of your authorization data sources needs to be geo redundant and provide good guarantees for data replication for consistency reasons.

20/ The missing piece to solve #fgaatscale is a service that allows developers to store all (or most) of the data they need to quickly, securely and reliably make authorization decisions about potentially millions of users and objects.

21/ It's finding the sweet spot between policy management but disregarding state on one end, and a generic geo replicated DBaaS on the other end. And that's what we are building 👷‍♂️