The data in the code snippet at the top shows simple authorization data. Our user object and our admin boolean determine who gets access. But authoriz

The Venn Diagram of Application and Authorization Data

submited by

Style Pass

2023-09-15 17:00:05

The data in the code snippet at the top shows simple authorization data. Our user object and our admin boolean determine who gets access.

But authorization data isn't always this straightforward. First, as your application matures you need different types of authorization data—more granular roles, resource data, and membership data, for instance.

Second, what’s the difference between authorization data and application data? The answer is: there’s overlap. This second issue—the overlap of application and authorization data—complicates our options for handling authorization data.

Some data is only for your core application, some data is only for authorization, but a lot of data that spans both. And this span grows.

You use some data only for the application. The content of this blog post is a good example of data that you won’t use for making an authorization decision. You use some data solely (or primarily) for authorization, like the admin boolean from the beginning.

But in a lot of cases, there’s overlap. You use data for both authorization and non-authorization purposes. Let’s say you have a source control application, GitCloud. You might have organization as the top-level resource, then repositories, then folders and files. Users have roles and memberships, and permissions based on their roles and memberships.