Thread by @Auth0Lab

1/ Last time explained why we are exploring fine grained authorization:

https://twitter.com/Auth0Lab/status/1322214832435826688?s=20

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…

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):

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….

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.

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 👋