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
4/ In @GiHub's case collaboration is powered by the ability for people to contribute using well-defined permissions for organizations, teams and repositories.

What makes @github qualify for authorization "at scale"?
5/ A quick use of their search feature shows they have:
- 50+ millions of users github.com/search?q=type:…
- 45+ millions of public repositories github.com/search?q=is:pu…

that's a lot 🤯, even without counting private content!
6/ @github has both a B2C (user repositories) and B2B model (org repositories), each with their own permissions.

👩‍💻B2C: User repos gives "owners" certain permissions on repositories they own: docs.github.com/en/free-pro-te… Image
7/ In particular, you can "invite collaborators". A repository collaborator also has certain permissions: docs.github.com/en/free-pro-te…

A visual representation of the permissions of a repository could be (users in yellow, repos in pink): Image
8/ 🏢 B2B: @github supports organizations. Organizations can be owners of repositories, and users can be members of organizations.
9/ Repo permissions have more levels for organizations: docs.github.com/en/free-pro-te…

And you can organize members into (nested) teams docs.github.com/en/free-pro-te…. Image
10/ An example visual representation could be this one (users in yellow, teams in green, orgs in lightblue, repos in pink)

1️⃣ Our first takeaway: a good authorization at scale solution needs to be *flexible*, and allow developers to express different permission models easily. Image
11/ But that's not all there is to it... @github logs all accesses to an organization and allows organization owners to access the audit log: docs.github.com/en/free-pro-te….
12/ They offer UI search and export capabilities, as well as an API to continuously export Audit logs over to other systems.
13/ @github understands our second takeaway:
2️⃣ A key aspect of authorization and security is not just setting up your organization and permissions, but also being able to *audit* activity over time.
14/ On the "not so visible" side of things @github runs on multiple regions for HA and latency reasons: github.blog/2018-10-30-oct…

For them HA and low latency are worth the investment. Authorization decisions are availability critical.
15/ Permission systems must be as available as the rest of their infrastructure, if not more. Furthermore, because of how often permissions decisions have to be made (likely at least once per "request"), it is fundamental to keep authz decision latency low.
16/ Our two final takeaways are:
3️⃣ *High availability* is a cornerstone of any at scale authorization system. Otherwise most of the core service itself becomes unavailable.
17/ 4️⃣ Minimizing *latency* overhead from an authorization system is fundamental to keep latency acceptable for customers at large scale.
18/ Summarizing:

To solve authorization at scale we need a system that has
1️⃣ Flexibility for expressing models
2️⃣ Auditability
3️⃣ High availability
4️⃣ Low latency
19/ There's another key aspect we did not explore in this thread: maintaining *correctness* from a security perspective. We'll be sharing our thoughts on that in a future thread 👋

• • •

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

11 Nov
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
Read 21 tweets
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
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!