We’re excited to announce the availability of Descope Fine-Grained Authorization (FGA) to help customers easily create granular authorization models for their applications. With our SDKs and APIs, organizations can define and assign permissions based on relationships between entities, enabling them to set up authorization systems that can match the nuances of their business.
See the demo video below and check out our documentation to get started with Descope FGA. To learn more about the Why, What, and How, keep on reading.
The role is not enough
Creating and managing access control policies is daunting at the best of times. With business realities and stakeholder requirements only growing in complexity over recent years, authorization becomes more important and more unwieldy.
With the rise of social media, collaboration, and productivity apps, customers now create their own content in these apps and expect to own permissions for this content.
What even is a “customer”? Businesses today interact with a wide range of stakeholders including customers, suppliers, partners, freelancers, and contractors. They need access to different resources across different apps in different contexts.
Authorization plays a pivotal role in pretty much every movement-verging-on-buzzword that has gained popularity in recent years – Zero Trust, remote work, GenAI, microservices, et al.
Two things are clear to us from the 100s of customer conversations we have had.
First, it’s not fair for organizations to build authorization from scratch. Sure, you can technically do it yourself. AirBNB did it. So did Carta. But for the vast majority of organizations, building and rebuilding authorization tooling is just not worth the time and effort.
Second, you can’t rely just on role-based access control (RBAC) as your app grows. A partner with an “admin” role may not have the same set of permissions as an employee with an “admin” role. There may be some in-app content that no one except the content’s owner should see, irrespective of the role. B2B end users of your product that are part of the marketing team may need to see a different dashboard than end users that are part of the sales team.
Using only roles to design authorization systems is an inelegant way to account for scenarios such as the ones mentioned above.
Things may end up being “too open”, which presents bad actors with an easy way to escalate privileges once they take over a victim’s account. Things may also end up being “too restrictive”, needing developers and IT teams to create a cavalcade of roles to take care of every edge case.
Most importantly, RBAC is about what “actions” users can take in the application, but it doesn’t account for what “resources” the actions can be taken on. What if you need a user to be a “viewer” for some resources, an “editor” on others, and an “owner” on others? There will be no end to the number of roles you will need to create if you stick with just RBAC.
We believe combining roles with relationships is a much better way to create authorization models that are flexible to the changing needs of a business and can scale as the business scales.
A note on ReBAC
Relationship-Based Access Control (ReBAC) is an authorization approach where permissions can be defined based on the relationship between entities. These entities can represent your app’s users, in-app resources that users can engage with, groups of users and resources, and so on.
The most famous example of ReBAC is Google’s Zanzibar system that’s used to create authorization at-scale for their products including Calendar, Cloud, Drive, Maps, Photos, and YouTube.
Adding ReBAC to your app can unlock plenty of benefits such as:
Saving time by creating parent-child relationships and hierarchies. For example, a folder can be a parent resource to all the files within that folder.
Empowering end users by creating an ownership relationship. For example, users that own a resource can edit and delete the resource (irrespective of their role).
Assigning bulk permissions by grouping users and resources. For example, all users under the customer success group get access to the customer health check dashboard.
Enabling dynamic permissions as the relationship between two entities changes with time.
Here’s an in-depth overview of ReBAC if you’d like to learn more.
Descope FGA
Descope Fine-Grained Authorization helps organizations easily add ReBAC capabilities (which can also be extended to ABAC) to their applications. With our SDKs and APIs, customers can:
Define a schema listing out the types of entities and the possible relationships that exist within the framework of your app.
Store the schema so that it can be efficiently queried, managed, and updated as relationships evolve.
Build out relationships between specific entities based on your schema.
Add checks within your app that can refer to the defined relationships before making authorization decisions.
With Descope FGA, the interpretation and enforcement of entities and relationships is completely up to your app, letting you retain control over authorization while providing the tools to simplify the actual work.
We currently support SDKs for Java, Node.js, Go, and Python, as well as an API.
Working example
Let’s look at the sample app covered in the video shared earlier in this blog. Here, we have created a notes sharing app where users can create and share notes with one another. With FGA, we are able to:
Roll up users into groups, helping us assign permissions en masse to groups.
Enable end users to share notes with other users or groups.
Govern user actions on notes they created versus notes that other users shared with them.
So if you share a note with someone as a “viewer”, they will be able to see the note but not edit it…
…but if you share a note with someone as an “Editor”, they are able to edit the note.
Explore the sample app and video to go deeper into this example or build your own!
It’s (already) aliiiive!
Although we’re formally announcing FGA today, multiple customers are already using it or see it as the right solution to a pressing problem. Here are a couple of customer use cases (simplified and generalized where appropriate):
Online car marketplace
This customer is a multinational used car marketplace with over 200 branches in 180 cities. The customer engaged with a variety of stakeholders apart from their employees and customers, such as car dealerships and loan fulfillment officers. They wanted to provide flexible access control for all their “customers” while taking into account the resource they were interacting with.
Their authorization model looks something like:
Resources
Car Listing
Car
Loan
Users
Employee
Car Dealer
Loan Officer
From these building blocks, they can define lots of fine-grained rules and relations such as:
Car Dealers can be grouped into Dealerships to assign permissions en-masse.
A Car Listing can be a parent resource for other resources such as Car and Loan.
Car Dealers can only edit and delete the Car Listings that they have created.
A Loan Officer can create, edit, and delete a Loan but not any other part of the Car Listing.
Digital adoption platform
This customer is a leading SaaS platform that helps organizations easily create in-app guidance and walkthroughs to enable self-support for their end users. They wanted to empower end users to create, edit, and share in-product content with other users. They also wanted to control access to resources for different user roles as well as customer support reps.
Their authorization model looks something like:
Resources:
Tenant: An instance of their core product licensed to their customer.
Product: The customer’s different product lines.
Group: A collection of Tenants.
Content: Different types of Content include surveys, pop-ups, and beacons.
Users
Customer Support Rep
Super Admin
Admin
User
This model allows for granular rules and lets users delegate permissions easily. For example:
A Customer Support Rep can see the account health and analytics for all the Groups and Tenants they are managing, but they cannot create or add Content.
A Super Admin can add other Users to Tenants, assign Users to groups,, and share Admin permissions with other Users as well as groups.
By default, Users can only edit and delete Content that they have created.
Users are restricted from creating certain types of Content based on their role (e.g. a User from the HR team can only create surveys and feedback forms).
Granting and restricting access based on relationships helps both these customers provide a seamless experience to disparate sets of end users without needing an endless number of roles.
We do auth (N + Z), you do you
For us, authentication and authorization are two sides of the same “access control” shaped coin. The processes and paradigms governing each might be different, but AuthN and AuthZ are joined at the hip otherwise: You can only authorize someone after authenticating them, and authenticating someone without then authorizing them is moot.
Descope Fine-Grained Authorization is a huge step in our journey to become a complete CIAM platform. Hundreds of organizations already use our no / low code workflows to create and customize their entire user journey (signup, login, MFA, step-up, and so on). With FGA, they can create access control systems that keep up with the changing needs of their business.
Sign up for a Free Forever Descope account and check out our documentation to get started with FGA. Have questions about FGA or our platform? Book time with our auth experts.
