In this podcast, Open at Intel host Katherine Druckman and OKTA Product Manager Andres Aguiar discuss OpenFGA, an open source initiative for fine-grained authorization management designed to enhance application security beyond traditional role-based access control. Recently accepted as a Cloud Native Computing Foundation (CNCF) sandbox project, OpenFGA is gaining traction for its ability to simplify the complex task of implementing and maintaining authorization. In this interview recorded at KubeCon Europe, Aguiar acknowledges the challenges in data synchronization and outlines future plans to refine the authorization model and improve search scenarios. He also notes the potential of AI in leveraging OpenFGA's data for security and forensic analysis.
“OpenFGA is helping developers implement authorization in their applications in a way that they can be more fine-grained in the most common ways of implementing authorization, which would be role-based access control, for example. And this is an evolution of that.”—Andres Aguiar
Meet Andres and OpenFGA
Katherine Druckman: Hello, Andres. Thank you so much for joining me in the middle of the bustle that is KubeCon. Tell us who you are and what you do in the world, and what you do with open source.
Andres Aguiar: Perfect. So, I'm based in South America, in Uruguay, and I've been, in most of my career, working on developer tools in different companies. The last project I was involved in is OpenFGA, which is an open source project for managing authorization. FGA is fine-grained authorization. I joined Okta as part of the Auth0 acquisition. It's a company that Okta acquired a few years ago. And at Auth0, I worked mainly as a product manager working on the login flows that Auth0 implements. But my whole career was more on the engineering side, so most of my life I was a software developer, and now, I'm building tools for software developers from the product side. OpenFGA is a step on that path, which is helping developers implement authorization in their applications in a way that they can be more fine-grained in the most common ways of implementing authorization, which would be role-based access control, for example. Right?
Katherine Druckman: Sure.
Andres Aguiar: And that is an evolution that gives you tools to go more fine-grained and implement it in a way that scales, and it's easy for developers to implement and maintain.
Project Maturity and Community
Katherine Druckman: So, how mature is the project?
Andres Aguiar: We open sourced the project two years ago. We got accepted as a CNCF sandbox project in September, and we just applied for incubation. So, it's a young project, but there's a lot of interest in the community around authorization because implementing authorization is difficult for an application.
Katherine Druckman: Sure. It's challenging and important.
Andres Aguiar: Challenging and important. In the Open Worldwide Application Security Project (OWASP), they list the 10 top vulnerabilities for APIs, and three of them are around authorization. The first one is broken fine-grained authorization. So you don't get access to a specific object, and you get that wrong. It's difficult to implement and developers make a lot of mistakes there. It's hard to have it consistent across your application, so you can implement it right in one endpoint but make a mistake in another one because you need to be thinking and reasoning about authorization everywhere.
Katherine Druckman: It's easy to leave the door open, I would say.
Andres Aguiar: Yes.
Katherine Druckman: Absolutely.
Adoption and Use Cases
Andres Aguiar: So, yesterday, I had a lightning talk where I went through how the project is being adopted right now. There's a dashboard for all CNCF projects where you can see the projects ordered by the number of commits, and OpenFGA is number eight, which is awesome.
Katherine Druckman: It's a solid activity.
Andres Aguiar: Yes. Also, there are a lot of companies using it in very different use cases. Canonical, for example, is using it as a part of the stack in the Ubuntu Pro server. If you use Ubuntu Pro in the next version they're going to release in a few months, OpenFGA is going to be embedded in multiple places. And there are companies that are doing software supply chain security that are using OpenFGA for authorizing access to their tooling of who can configure what. There are companies that use OpenFGA to manage who can see metrics or dashboards or traces for specific resources and API gateways that let you manage the different features an API can use depending on the features you pay for in your API gateway product.
And then, there are more B2B products that do analytics for meetings based on AI or cash management. So, you have the whole stack in a software product, from the operating system to the AI app, that can take advantage of authorization because everyone needs authorization. The way OpenFGA approaches it is convenient for developers and makes it way easier not to make those mistakes that end up causing authorization issues.
Contributions and Integrations
Katherine Druckman: Okay. I would guess that you are, like most projects, looking for contributions, right?
Andres Aguiar: Yes, of course. And there are a lot of places where you can contribute to OpenFGA because authorization needs to be integrated into applications. We built a lot of SDKs for different languages, including Java, JavaScript, Python.net, and Golang. There are more languages that we need to build the case for. That would be helpful. We also need to build integrations with different platforms to make it simple to integrate authorization into that specific platform. For example, Java Spring or Xpress or ASP.NET Core; that's another tier where we can welcome contributions—people who want to simplify how to integrate authorization in a specific platform. Then, you can implement authorization at the API gateway level. We would love to have integrations with Istio or other API gateways so that you can simplify how to insert OpenFGA into the API gateway. So, all those things are places where it's relatively simple to contribute, because those are not very difficult projects. If you know how to build an Istio connector or plug-in, it should be easy to build one for OpenFGA.
Understanding Relationship-Based Access Control
And then, something that is now coming up more for how OpenFGA works is if you think about role-based access control, you end up having three entities, including the user, the role, and the user group that you end up relating to in certain ways. So, this user belongs to this group, this group belongs to this role, and things like that. And what OpenFGA does is, it's based on a concept called relationship-based access control that is an evolution of role-based access control. In addition to defining those entities like rules and groups, things like that, you can start defining the entities that are related to what your application is about. So, if I'm building document-managed applications, I will create folders and documents in my model. In the same way I relate users and groups, I can relate users to folders or groups to folders.
Then, when I define permissions, I can say things like, "If you are a viewer of the folder, you are also a viewer of the document that is inside that folder. If you are the owner of the document, then you can edit the document." You can start defining permissions based on the relationships that you have between different sets of users and different sets of resources. And you also can define hierarchies between them. If I'm an admin of an organization, I can edit all the folders in that organization and edit all the documents, and I can express that in the policies that you define in OpenFGA. So, that is the main difference between what you can do with role-based access control and the approach that OpenFGA takes.
In the same way, in role-based access control, you need to define that this user belongs to this role, this group is linked to this role, or something like that; you need to provide that same data for the rest of the resources to OpenFGA. Like, for example, this group can edit this folder, or this document is a child or is inside this folder, or things like that. So, all the data that is generated when your application executes based on user actions and whatever, needs to be replicated to a certain extent to OpenFGA. Like, for example, you'll say, "The folder ID number one is the parent of document ID number two." And then, when you want to know if a user can edit a folder, you will ask, "Can user number five edit folder number two?" And based on the data you have in OpenFGA and the relationship you define in your policy, we will say yes or no.
And that's the core difference between the most common ways of implementing authorization and the relationship-based access control way. But to do that, you need to provide more data to the authorization engine than what you need in role-based access because you need all that data that is application-specific. Building those integrations to get data from your system and synchronize that to OpenFGA is one of the areas where the complexity of implementing OpenFGA lives, how you start getting data from your applications to OpenFGA, so OpenFGA can evaluate those policies having all the data it needs to do that. So, that's another area where contributors can help by building things that enable you, for example, to ingest changes from a Kafka stream, use Debezium after a database change, change data capture logs, or things like that to make it simpler to connect different systems to OpenFGA so you can get that data into OpenFGA.
Katherine Druckman: So, you kind of hinted at something I was going to ask, and that is, with robustness comes complexity, and sometimes that can also mean difficulty in usability. So, I wondered how you tackle those challenges.
Andres Aguiar: Yes. So, as I mentioned, the area where you have more complexity in integrating OpenFGA is the data synchronization part, and there are different things that we can do there. Part of the data about, for example, roles, groups, and things like that, might live in other systems, for example, your user directory. And we are building tools to synchronize from user directories to OpenFGA. I work for Okta, so the first ones that are easy to build are Okta on Auth0, but if we do, we build it through a scheme, where a scheme is a standard that lets you connect any user directory and subscribe to changes. So, you can put that data into OpenFGA using standards. And then, there are other connectors that we can build to simplify that. But at the end of the day, if you have a very custom app, in your custom app, you will need to figure it out that way.
In general, depending on how your app is built, there might be different strategies. One is subscribing to database change logs like streams, like when a record is reported to be stable, I get notified. That's one way. If your system is built in a way that every change that you make in the system is posted to an event or something like that, you can subscribe to those events and then write to OpenFGA. So, those are some strategies that you can follow to implement something in OpenFGA if you have a lot of data to synchronize with the system.
Katherine Druckman: I wonder, so with a young project like this, what are the biggest challenges and hurdles that you find in growing your adoption? Again, the robustness angle is always a bit of a challenge, right? Because it solves a lot of problems for a lot of people, I'm sure, but if it's perceived as overcomplicating some of the problems, that can be a little bit of a barrier, I think.
Andres Aguiar: Yes. And I think it's more like, if you have the authorization problem, and then you understand how complex it is to define it in a way that is robust from an authorization perspective, the trade-off that you need to make might be good for you. So, this idea of how the project is designed is based on a research paper that Google published a few years ago where they described a system that they call Google Zanzibar, which is the way they solved this problem internally. And basically, they had this idea of a relationship-based control and having all the data you need to make authorization decisions in a single place.
And what we did is, we took some of those ideas and packaged them in a way that is simple for any developer to integrate. And if you think about the way authorization is implemented in general, it's you have role-based access control, and then if you want to say, for example, "Can I approve a specific expense report?" you might have a role that is you can approve expense reports, but it's not that you can approve any expense report, right?
Katherine Druckman: Sure.
Andres Aguiar: You are approving expense reports from your direct reports or something like that. To do that, you will need to query your database to know who is the user that is approving the expense report, the manager of the person who submitted that expense report. So that implies that you need to go and fetch data before making the authorization decision. And you need to do that in every API. In every API, you need to query different data and then you make a decision. So, in the OpenFGA approach, instead of you going to your databases in each API endpoint, you just go to OpenFGA in that endpoint and we have all the data. But the trade-off is you need to write the data to OpenFGA in the background while that data changes. So, you don't go to find it, and the moment you're making authorization decision, you provide it to us as it's changing.
And given that, usually, rights and checks are way more common. Checking for permissions is way more common than changing permissions; it implies that you are not dealing with querying your own data all the time, and you can just delegate that to OpenFGA. There was a post from Figma a few weeks ago where they described how they implemented their own authorization system without OpenFGA. They're doing their own thing, and one of the reasons they mentioned is that 20% of the traffic they have in their databases was to serve authorization requests.
Katherine Druckman: Wow.
Andres Aguiar: And that's a lot of requests.
Katherine Druckman: That is a lot. It's a burden.
Andres Aguiar: And databases are hard to scale up easily, right?
Katherine Druckman: Yeah.
Andres Aguiar: So, there's a moment when it's very difficult, very expensive to be higher. So, by putting it in another place, they've reduced a lot of all the database queries they need to make these decisions.
Katherine Druckman: That makes a lot of sense. I wonder if you could tell us a little bit more about what you see as ideal use cases, but are you also seeing unexpected ones?
Andres Aguiar: OpenFGA, and this is inspired by those ideas by Google in general, when we built it was more for applications. So, when you have a lot of data, and there are a lot of changes in permissions because users are the ones sharing the document and changing permissions very frequently. But now we are seeing that, for example, it's being used in an operating system in places where it solves the problem because this way of expressing policies and permissions is more powerful and simpler than what you could do in other ways. But it's not what we were thinking of when we were designing the product. So, we were thinking more in the higher levels of the stack and we see it implemented everywhere in the stack.
Katherine Druckman: It's interesting. I always like to hear about those kinds of unexpected results of projects because, when you go into a project, you're solving a problem, you go in to solve a specific problem that you had in mind and then, someone out there, and this is the beauty of open source, someone will discover your project and find something you hadn't even thought of and then it solves that problem too. And I think that's fantastic.
Andres Aguiar: Yes. And that is very exciting when you see someone building internal tools on top of your project, doing things that you haven't thought there could be a need for, and then you get inspired by how you can improve your project based on those ideas. So, there are a lot of great things that happen in open source, and that enrich the product a lot.
Future Roadmap and AI Potential
Katherine Druckman: So what can you tell us about the roadmap? What does the next year look like in your project?
Andres Aguiar: So, there are a few things. One of the things that is important is that authorization is application-specific. So, and given that OpenFGA gives you a way to express the different entities per application, you want that each application in a company can iterate their models independently. Let's assume you are Atlassian and you have Confluence and Jira and other products. You want the Jira team to work with the authorization model, which will be about projects and tickets, and Confluence will be about pages and spaces. So, we are building tools to make that simpler. Today, there's a single model, which makes it difficult for multiple teams to collaborate on that. So, we're building tools to modularize that authorization model so each team can manage their own piece and then combine them in a single thing because there are certain things that everyone needs, right?
User groups, organizations, and maybe sometimes you need to reference a Confluence space from a Jira ticket, you want those links, but there are authorization policies for each project that need to be managed by each team. So, we're working a lot of angles to solve that, to make that problem simpler. And the other part is, another challenge of having a system like this is that, when you want to list data, let's say I want to list all the documents that a user can view that were modified in the last week and have this string in the title.
That implies doing a query on your database that filters by the document name and orders by date. And also, ask OpenFGA who can view that document, because I need to only list the documents that you can view. So, we have APIs that let you do things like, "Give me all the documents that I can view and I’ll give you all the IDs." But if you are building Google docs, and I have a million documents that I can view, me giving you a million document IDs is not going to be very helpful, right?
Katherine Druckman: No.
Andres Aguiar: So, you need to put that in a sequence. In a statement, it wouldn't work. So, we're finding and working on other ways to let customers simplify or adopters simplify that problem of search that today implies that they need to have certain logic of authorization in their apps for those more extreme scenarios. And we want customers to centralize all the authorization logic only in OpenFGA and be able to use it also for search scenarios. If you think, in certain scenarios, if you have role-based access control, what you end up doing is, in every query, you end up adding authorization logic there, right?
Katherine Druckman: Right. It's a —
Andres Aguiar: Which is where the owner is the user who is viewing or belongs to a group that has access. So, instead of —
Katherine Druckman: Quite a payload.
Andres Aguiar: Yeah. So, we want to, instead of you replicating the logic in every query, help you launch the authorization in OpenFGA and then reuse it for your queries. But that is a challenging problem and we have more work to do there.
Katherine Druckman: Okay. Well, that's fantastic. I feel like I have to put this out there. Everyone's very excited about AI. How do you feel about the potential for AI to solve a lot of problems in terms of, in this case, maybe security vulnerabilities caused by improper use of access control?
Andres Aguiar: Another benefit of a centralized authorization system is that you have a log of every time someone changed their permission and every time someone tried to access a specific document or a resource. That's a lot of data. That is very interesting.
Katherine Druckman: And AI is great for processing it, right?
Andres Aguiar: Right. You can find anomalies like, I don't know, something is going on here that a lot of people are trying to access a document and failing. There's a user that is trying to access a document that they shouldn't, access a document at a time that they shouldn't be. So, you can use that to get a lot of information for security and also for forensics. So, something happened, let's see what they accessed, having a centralized place to have all that data is very useful. And I think AI can help a lot there.
Katherine Druckman: Cool. That's a great answer. I like to remain optimistic about the potential of using these kinds of tools to, again, crunch a ton of data that we don't really want to do in another way, because it's a lot faster. Well, cool. Thank you so much. I really appreciate you coming and sharing your project with us.
Andres Aguiar: My pleasure. Thank you very much for hosting me and good luck with the rest of the week.
Katherine Druckman: Cool. Thank you so much.
You've been listening to Open at Intel. Be sure to follow us for more on LinkedIn and X. We hope you join us again next time to geek out about open source.
About the Guest
Andres Aguiar has spent his 20+ year career building tools for developers, wearing different hats. He’s been working on the identity space for the last six years and is currently the product manager for OpenFGA.
About the Author
Katherine Druckman, an Intel open source evangelist, hosts the podcasts Open at Intel, Reality 2.0, and FLOSS Weekly. A security and privacy advocate, software engineer, and former digital director of Linux Journal, she's a long-time champion of open source and open standards. She is a software engineer and content creator with over a decade of experience in engineering, content strategy, product management, user experience, and technology evangelism.