How Google manages users authorization

We can find a user permission/role management in basically every multi-user software platform so it can answer questions like "Is user X allowed to perform operation Y?" or "Is user X allowed to access resource Y?". There is no standard way to manage this control access. Almost every company builds its own ad-hoc authorization system. Google is not an exception.

Google's authorization service is called Zanzibar. This tool allows to configure centralized access lists for every single Google service or product (Calendar, Drive, YouTube, etc...)

Zanzibar is a cross-service and centralized system so it is a critical component in the company. That is the reason why this service is focused on consistency, flexibility and high availability. As a curious fact, Google Zanzibar availability has been 99.999% during last years.

Internally, Google Zanzibar stores access lists of millions of users using an Spanner database: highly scalable and distributed storage system build by the same company.

But, how are those access lists look like? Every relationship between a user and an object is represented by a tuple. The idea is simple, some examples below:

• User 25 is owner of image 31: picture:31#owner@25
• User 13 is member of group devs: group:devs#member@13
• Group devs members are "viewers" of document 982: doc:982#viewer@group:devs#member

Google Zanzibar allows users to create objects and relationships needed according the nature of the application being developed.

Zanzibar consumers can invoke several operations against the system: read tuples, create new tuples, subscribe to changes and check if a tuple exists. Those operations have a minimum response time and really low latency. It must be like that since it's a cross-service system, used by almost every Google service.

If you want to know more about Google Zanzibar, here is the official paper.