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👇
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.
- *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 Image
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
📜 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. Image
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? Image
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 👷‍♂️ Image

• • •

Missing some Tweet in this thread? You can try to force a refresh

Keep Current with The Auth0 Lab

The Auth0 Lab Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!


Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @Auth0Lab

10 Nov
1/ Last week we did a deep dive of @github's authorization model and the problems they solve

In this thread we'll focus on another well known product: @googledrive a great example of a collaboration platform.

📊How is gdrive "authorization at scale"?
2/ Well, in 2018 they:
- hit 1B users
- 2 trillion files


🔐 Review their permission model
🔍Go over their "search" story and how authz fits in it
🎯Analyze examples of why "correctness" () is important
3/ Like github, @googledrive has B2C and B2B models. However, @googledrive's sharing model is the same for B2C and B2B. The difference is who you can share files with.
Read 21 tweets
5 Nov
1/ Last time explained why we are exploring fine grained authorization:

In this thread explore we'll the problems of authorization at scale using a real world, well known example
2/ This is a key part of product development, especially when building infrastructure. We want to understand what our customers will eventually build with our service.

Our analysis case is @github.
3/ @github is an interesting example as it’s a *collaboration* platform built on top of git.

We believe collaboration and authorization are two sides of the same coin
Read 19 tweets
30 Oct
1/ On Wed, we posted about why we are doing this and what we expect.

We also promised to unveil this week the problem we want to dive into 🥁...
2/ The area we'd like to explore is: *fine-grained authorization*

Why this? And why now?👇
3/ Large scale fine-grained authorization as a building block is an unsolved problem. Just like authentication was ~8 years ago. We implement it in every app we build, over and over. There is no generic, cross-platform, cross-domain solution.
Read 8 tweets
28 Oct
1/ Kicking off this experiment!

First thing, we want to share *why* we are doing this and set some expectations.

Thread 👇
2/ Building new products is a messy process. There is no manual. But one thing we know is if we focus on learning and iterating, we can get somewhere. Worst case we learn that an idea is not worth it, the best case we find a product. Either case we learn.

3/ This is an experiment 🧪. We've never done this before.

Auth0 has a mature and defined prod dev process. We are a small team focusing on exploring product adjacencies and that gives us room to be more experimental.

Bear with us and embrace experimentation.
Read 9 tweets

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!