Fine-grained authorization becomes necessary when “admin,” “member,” and “viewer” stop describing how your application actually works. This webinar shows where RBAC begins to buckle, how ReBAC and ABAC handle permissions that depend on resources, relationships, and context, and how to decide whether your architecture needs a more expressive authorization model or whether RBAC still does the job.
.png)
.png)
Everybody, welcome. Thanks for joining us today. If you will give us just a couple of minutes here, we're gonna give folks another little bit of time to wander in. So this is your kinda two-minute warning. Hop up, grab yourself a drink, take a bio break, and we will be right back.
Welcome, welcome, welcome. Thanks for joining us today. I'm gonna give folks just another minute here. A couple of housekeeping notes for you: you can drop questions in the chat as we go. We're going to address most of those at the end, though if a question is really relevant to the discussion we're having at that moment, we may just go ahead and interrupt ourselves and answer it right then. This session is going to be recorded, and we will send it to all of you. Thanks for taking time to be here live today — you'll also have plenty of opportunity to catch up with it later.
I'm Brad McCarty. I'm joined by Dan Moore, senior director of CIAM strategy and identity standards here at FusionAuth. Today we're going to be tackling a topic that many growing engineering teams eventually face: what happens when your authorization model breaks down? One thing up front — this is not a sales pitch. Our goal is to help you determine if fine-grained authorization fits your situation. For a lot of you, standard RBAC is going to be the right answer, and that's fine. So let's figure out which camp you're in.
Let's start with a distinction that seems obvious but has pretty real consequences. Authentication answers the question: who are you? It's the login, the identity verification. Most teams solve this pretty well, either through a provider like FusionAuth or a homegrown system. Authorization answers: what can you do? It's the permissions, the access controls, and it's where things can get messy.
What typically happens is that you invest in solid authentication, then you bolt on authorization as kind of an afterthought. You get a few roles here, some conditional checks there, and it works — right up until it doesn't. The gap between those two widens as your product grows, and authorization complexity tends to grow faster than anyone expects. This is a pattern we see frequently.
I'm going to walk you through how authorization typically evolves, and in this example we're going to look at app authorization logic. Stage one: you start with some simple roles — admin, user, maybe a viewer. It's clean, easy to understand, easy to implement, and your life is pretty good. As your product grows, you start needing more granularity. You add roles like manager or billing admin. Exceptions start showing up — admins can do X, but only except in this case. And now you have permissions scattered across multiple services.
I just want to chime in real quick. The more roles you add, the more exceptions you get — and that's what we call logic creep. It's not a bad thing; there's a good reason for it. But it ends up hard-coded throughout your application. It's brittle. You get admins that can do everything except for this, or for this customer they need to be able to give access to contractors during a certain period of time. And those are modeled in such a way that it's not just that you're scared of changing authorization logic — it's that the same team, over time, has developed different conceptions of how authorization works. Because they don't have a singular view, that leads to security issues and unintended privilege escalation, which is obviously not great.
So it's not a bad thing that the authorization model gets more complex — it's actually a sign of your application succeeding. And then around stage four, something we've seen is that you don't just get creep across different services, you also get inconsistencies. Those are a little scary because they turn into unintended privilege escalation. Different teams or even the same team over time will have different conceptions of authorization, and because they don't have a singular view, that leads to security issues. Just wanted to add that nuance.
Yeah, and I think there are going to be a few opportunities here where you're going to interrupt me, Dan, because a lot of these are more nuanced than what I've put into slides and slide notes. Please do interrupt me and keep me honest.
Alright. Let's talk about logic creep and how it actually costs your organization. First, it costs engineering resources. Your team is going to be spending time maintaining authorization logic instead of shipping features that drive revenue. Every sprint is going to have a little bit of authorization-related work that nobody planned for. The second cost is deployment friction. When permissions live in application code, every change requires a code deployment — and that slows everything down. Then there are compliance headaches. When an auditor asks who can access what and how do you know, you're going to have to dig through application code to answer that. It's expensive and error-prone. And fourth, one I find really interesting, is tribal knowledge. It's usually one or two engineers who understand how the authorization system actually works, and when they leave, you're in trouble. Who can stand in when we don't even know where the authorization code lives? Finally, there's risk from brittle systems. They break. Authorization bugs lead to data exposure and unauthorized access, and the revenue and reputation damage follows.
These aren't hypotheticals — these are stories we've heard from engineering teams far too often. Here's the thing: authorization complexity isn't always, as Dan said, a sign you did something wrong. It's more a sign that your product is succeeding. As you get more customers, you get more permission scenarios.
I just want to add that this is really a series of trade-offs, like any other engineering situation. You want to be very cognizant of the things you'll see in future slides. The complexity will arrive — it will. The question is whether you'll be ready for it when it does. We're here to educate. The architecture decision you make now — whether you lean into it or avoid it — can determine your flexibility later. We want to help you make the right decision for your team, your business, and your applications.
That's what this session is really all about. We want to help you make that decision intentionally instead of reactively.
So at some point, every growing application hits what we like to call a complexity fork, where you have two or three paths forward. Path A: you keep extending your RBAC. You add more roles, more groups, more conditional logic, and it works for a lot of applications — there's nothing wrong with that approach. Path B is moving to relationship-based access control, or ReBAC. That's the foundation of fine-grained authorization. Instead of asking "what role does the user have," you ask "what is the user's relationship with this specific resource." And then there is often a third path: attribute-based access control, or ABAC.
None of these paths is inherently better than the others, but choosing the wrong one for your situation can get expensive. Either you're going to overengineer and add complexity you don't need, or you underengineer and hit a wall when your product scales.
So let's look at when each of these paths makes sense. RBAC works great in specific situations. If your permissions model is flat — admin, member, viewer — and those rules apply globally across your application, RBAC handles that cleanly. If permissions don't depend on relationships between objects, meaning a user's access doesn't change based on the specific document or project they're looking at, then RBAC is sufficient in most cases. If you're single-tenant or your multitenancy is simple, RBAC scales fine. If your permissions rarely change—
I just want to chime in real quick. I think it's worth emphasizing that authorization is always important — you always want to make sure the wrong people don't see the wrong thing. But there are definitely scales to this. As Brad was getting at, there's a difference between a permissions error being a minor inconvenience rather than a data breach. If someone saw a tennis match they shouldn't have seen, that's very different from revealing health information about someone. So those are kind of the two sides of the spectrum.
And obviously we love RBAC. RBAC is great — it's been around for decades, it's well understood, it's easy to reason about. But unfortunately, sometimes it does fall down, and we'll talk more about how shortly.
So fine-grained authorization, FGA, becomes necessary when your permissions model has more depth to its relationships. Multitenant B2B SaaS is a classic case for this. You've got organizations, and within those organizations you have workspaces or teams. Within those teams you have projects. Within those you have resources. A user's permission will often depend on where they sit in that hierarchy.
Object-level permissions are key here — it's not "can this user edit documents?" It's "can this user edit this specific document?" And that answer depends on their relationship to that specific object. Relationship-based logic is the key concept: the user can edit this document because they're an editor on the project that owns this document, and that project belongs to an organization they're a member of. Trying to express something like that cleanly in RBAC is a challenge, to say the least.
Dynamic permissions are another signal. When relationships change — someone joins a team or a project moves to a different organization — permissions should update automatically without you having to change application code. Cross-service authorization needs push here too. If multiple services need to answer the same permissions questions, you probably need a centralized source of truth. And finally, if audit compliance is a serious requirement for you — healthcare, finance, enterprise software, multinational operations — you need authorization that is provable and auditable.
Developer platforms like fintech, collaboration tools, data platforms, enterprise SaaS with deep hierarchies — these are all classic ReBAC candidates. But relationships aren't the only factor that might drive your access decisions, so let's look at another model.
ReBAC handles relationships beautifully. Sometimes access decisions depend on context and not just who's connected to what, and that's where ABAC, attribute-based access control, comes in. ABAC makes decisions based on attributes across four categories. Subject attributes describe the user — their age, their security clearance level, department, job title. These go beyond roles to capture characteristics that matter for access decisions. Resource attributes describe what's being accessed: how sensitive is that data, who owns it, when was it created? A document marked confidential requires different handling than a public file. Action attributes define what the user wants to do — reading is different from writing, and deleting is different from sharing. ABAC can grant read access while denying the delete function. And environmental attributes capture context: what time is it, what's the user's IP address, what device are they using, and where are they located?
Some real-world examples: age-restricted content where users under 18 can't access certain resources; transaction limits at a bank where withdrawal amounts are capped; geo-restricted access based on IP address; time-based permissions that only allow access during business hours. A concrete example from Permify documentation: a banking system where a withdrawal permission checks both the account balance and a maximum withdrawal limit.
Yeah, I just want to add a little more nuance. The attributes mentioned on the slide are numerical, but they can also be Boolean or string comparisons. The whole point is that you're making decisions orthogonal to RBAC. RBAC is like: where do I sit in a hierarchy, where the hierarchy can be defined? ABAC is: what are my attributes — the attributes of the entity, of the request — and can I combine relationship-based and attribute-based logic? You can combine them in the same schema. You're not locked into one approach.
Like, you don't have to pick one or the other. We see a lot of teams that start with RBAC and then layer on ABAC as those special cases show up. We talked earlier about how special cases are actually an indication that your application is succeeding. "This customer wants the executive assistant to have the admin role, but this customer doesn't" — that's something relatively easy to add with ABAC that would be difficult to do with RBAC without running into role explosion.
The fine points are important here. Alright. So here's how you know when you've hit that complexity fork. Listen for these signals from your team: different teams are implementing authorization differently and there is no single source of truth; nobody wants to touch the permissions code because it's fragile and interconnected; you started with clean roles but now you've got 47 of them and it's still not granular enough; the quick fix from two years ago is now a significant maintenance burden.
Two other signals: role explosion, where you keep adding roles to handle edge cases, and authorization logic living in application code rather than its own dedicated system. If you're hearing these things or saying them to yourself as you build, you're at the fork. The question is which path makes sense for your specific situation.
Let's get specific about when FGA is the right investment. First, authorization needs to be a core product capability, not a side concern. If access control is central to your product's value proposition, and you or your customers care deeply about who can see and do what, then FGA is worth the investment. Second, if you have hierarchical concepts in your data model — organizations containing teams, containing projects, containing resources — if your nouns nest inside each other, your permissions probably need to reflect that. Third, if multiple product teams are shipping independently but need consistent authorization, a centralized authorization service lets each team focus on their domain while sharing a common permissions model.
I want to chime in real quick, Brad. FGA stands for fine-grained authorization — I wasn't sure whether we defined that previously, and whenever I see a TLA show up I want to define it. The second thing is that centralized authorization using a tool like FusionAuth — or in this case, powered by Permify — can offer defense-in-depth. You can check at the API gateway layer, at the business logic layer, and at the data access layer, every time, if that's important to you. You aren't just checking at the outside perimeter of your application for authorization decisions, because it's a simple SDK call away. You don't have to worry about logic being replicated and getting out of date — it's all centralized in one service that you can call from whatever layer you want to check authorization at.
Right. Okay. So that being said, there are times when FGA is not a fit. When simple RBAC covers your needs — admin, member, viewer — don't add complexity you don't need. If your permissions model is relatively flat and relationships between objects don't affect access, RBAC handles that. If permissions rarely change after initial configuration, you probably don't need a dynamic system. If authorization is not business-critical, and a permissions bug would be a minor inconvenience rather than a compliance failure, keep it simple. And if you're at the early MVP stage, you don't need to solve tomorrow's problems today. Get product-market fit first. You can add FGA later when you know you actually have a problem or you're approaching one. Honest advice: if RBAC works, use RBAC. FusionAuth's application roles and entities handle this pretty well — don't overengineer your authorization just because the technology is interesting. Save FGA for when you actually need it, and you'll know when you need it.
So once you've decided that fine-grained authorization makes sense, you face another decision: build or buy? Building gives you complete customization and total control, but let's be honest about what that means. You own the requirements gathering, and authorization requirements are deceptively complex — edge cases multiply fast. You own ongoing maintenance, not just bug fixes, but keeping up with evolving security standards and compliance requirements. You own any security vulnerabilities if you get it wrong, and you own feature development and performance optimization forever.
Buying means you offload that maintenance burden to a team that specializes in authorization. You benefit from continuous improvements — new features, performance enhancements, security patches — without consuming your own engineering team's capacity. Someone else is thinking about authorization full time; your team doesn't have to.
The trade-off is that integration work is real regardless of which direction you go. You're going to spend time connecting a bought solution to your systems, the same as you would with a built solution. You may hit customization limits in edge cases. Neither path avoids the work — the question is where you want your team spending their time over the next two or three years.
Whatever you decide, let's set realistic expectations about implementation. Core technical implementation typically takes weeks — not hours or days. That's getting the system running, connecting your application, and handling basic permissions checks. Full adoption is likely going to take months, not because the technology is slow, but because authorization migration is a careful process. You need thorough testing, and authorization bugs are security bugs. You need phased rollouts — you don't flip a switch and migrate everything at once when it comes to authorization. You do a gradual migration across your system, service by service, validating as you go.
I just want to chime in real quick. You did a really good job talking about the integration piece. The piece you don't want to sleep on is the performance piece. Unlike authentication, where you might log in once and get an access token or a JWT that's good for five minutes, with authorization you're calling that service many times during a single page render. Think about it not just in terms of dev, but in terms of making sure your application still continues to perform as you need it to.
Yeah, so I have a demo of a real, live sample application we built out that shows the integration between FusionAuth and Permify. Is it time? I've been waiting for this all webinar, man.
Right. Dan, you've actually got a little demo here for us.
I did — I layered in an integration with Permify, and we have here a sample application. I'm going to walk over the schema real quick. We have a user — a user basically represents a person. We have a bank, which has various roles inside it that can do different things, and we also have these attributes. This is an example of not where we combined ReBAC and ABAC, but where we combined RBAC and ABAC, because we needed this additional functionality.
The critical thing is that each of these actions represents a page in our sample application and who can access it. The account page is available to everybody as long as they have a role in the system. The admin page is only available to tellers and vice presidents. And then the make-change page is accessible to tellers, but only when the bank is open. We're going to define when the bank is open, and we have this rule that, as Brad showed when talking about ABAC, is pulling from context. We're going to provide that context when we actually do the permission check.
So I'm here, I can go to the make-change page, I can make my change. Let's get into the code, and then we'll tweak one thing. So this is the JavaScript code, and this is how easy it is to layer in permissions checks. This is an example of the integration that Brad mentioned you'll have to do to leverage a tool like Permify. Here we're getting the context — we're getting the time that the request is coming in, and here's our permission check.
On line 91, we're saying: check this permission for this entity. What we need to provide here is the type and then an ID. In a real application, the ID would be pulled from a database — this is a sample application. We have this permission, which for the simple application is just the action: view the account page, view the admin page, view the make-change page. Here's where we pull the information from FusionAuth — when we log in, we get a JWT, and then we're going to pull the user ID, which is the sub claim off of that JWT, and pass that into Permify. And here's our context: right now we're just passing the current hour. We could absolutely pass other interesting attributes, like request IP, which is a common one so you can limit access to certain functionality based on where a user is coming from. There are lots of other options as well.
At the end of the day, we have this check result, and that tells us whether or not we can allow the access. Because I don't want to wait twelve hours, I'm going to hard-code it to pretend that it's one in the morning, and then I'm going to try to access the make-change page. With this check, it should fail.
The reason why it fails — let me go back and share the other screen. When I loaded up the data for bank one, I set the open hour to seven and the close hour to seventeen. So between seven and five is the only time a teller can make change. So we're going to log in as the teller again, and if I go to make change, you can see my access is denied.
This is, admittedly, a simple example, but it shows some of the power, especially because it's all centralized. Now if I need to add another attribute to check — maybe it's "open on holidays" because some banks are open on holidays — I could add that field, update which banks have it set to true, and then add that check into my application logic in just one place. Without having my logic anywhere else, I could easily allow access to the make-change action for banks that are open on holidays — only those banks, not all the others.
This is just touching the tip of the surface of the complexities you can model inside Permify, but hopefully gives you a bit of a taste. And the last thing I want to show you is this visualizer, which helps you understand — you have to zoom carefully here — how things relate. The idea is that we have all these relations, and Permify basically walks a tree when you make a request and can determine whether or not something has access to something else. Underneath, there's a vast — essentially a graph database — that they've modeled inside it, and you get to leverage that when you use Permify. That's the end of my demo.
I had not actually seen the visualization before, so that was really cool. Thanks — glad you shared that.
Alright. Let's talk about where we go from here. If RBAC fits your needs, if your permissions model is straightforward and the signals we discussed don't really apply to you, then FusionAuth's application roles handle that pretty neatly. Stick with what works. If you are hitting that complexity fork, though, and you're considering fine-grained authorization, then let's have a conversation. We can help you assess whether FGA is the right fit for your architecture and your timeline — and that may mean Permify, or it might mean a different approach. We want to give you an honest answer there.
If you want to explore Permify directly, it is open source — you can spin it up for free. Try the schema modeling and see if the concepts click for your use cases. Here's our ask: if what we covered today resonated with you and where your product is today or where it's headed, reach out. Drop us a message. We want to help you figure out what the right path forward is.
Alright, we have time for some questions.
So the question is: why would a company choose an authorization solution like Permify instead of building their own permissions system? And I think we touched on some of the nuance there, but let me expand.
A lot of frameworks come with role-based solutions built in. So thinking about the build-versus-buy spectrum, I think of it in three pieces. First is rolling it all yourself — a great educational experience, but probably not the right move for a production application. Second is leveraging a framework or built-in library. There are some out there — Casbin is one I've heard of, and Pundit if you're in the Ruby on Rails world. These still require deploying code to make changes, but they do abstract out the permission structure and get you thinking about things in the right way, especially if you only have one application. Third is standalone systems like Permify. That's a great fit when you need some of that modeling we saw earlier, the tooling, the central location — especially when you start to multiply your authorization logic across multiple applications. Then you want to start thinking about a centralized solution.
So the short answer is: other than for toy applications, I don't think you should build the mechanics yourself. I want to be respectful here — there's always some aspect of building involved, as Brad mentioned. There's always the integration work, the modeling work, and no general-purpose tool will take that away from you. We don't know your application; you do. But building the mechanics — the permission checks, making sure they're performant, making sure you have some kind of abstraction layer or modeling language that helps you understand things — that's stuff I don't think you should ever build yourself anymore. Hopefully that gives some nuance on the question.
Another question that came in that I'm very interested to see the answer to: what are the plans to integrate Permify with FusionAuth in the coming year? Is there a future state where I can run authorization in the same dashboard as my FusionAuth setup?
Yes — whether that's running in our cloud, which is coming very soon, or running in your own data center, which is a good fit in a lot of cases because authorization is so critical to applications. In the next couple of releases, you're going to start to see Permify show up in the admin UI. And yes, long term, the plan is to have control plane integration between Permify and FusionAuth. Some people on the sales team were asking me the other day when, and unfortunately I can't answer with a definitive timeline — whether it's within the next quarter, the next six months, the next year — but we are working toward that.
To be totally blunt, we want to hear from users and customers. The fact that you asked this question is fantastic, because that's another signal that people really want that unified API. I'll say that there is the control plane — where you're managing the schema and loading data — and I think those are things where the unified API makes a lot of sense. The permission check itself, which you want to be super fast, I'm not sure there's value in having that run through FusionAuth. That's an open question in my mind. But the other two — I could definitely see those getting integrated. No timeline yet.
On the question about connecting authorization to API gateways: I haven't seen dedicated connections between a solution like Permify and a gateway. At the gateway level, I see a lot of audience checking and some other things — checking the issuer, the normal validations you'd run on an access token, checking roles conceivably — but full authorization at that layer I haven't seen a specific integration for.
Awesome. You mentioned connecting authorization off of API gateways — can you speak to any of the supported gateways?
For API gateways that would integrate with something like Permify, I think you'd want it to be pretty performant, so it might be like an extension or a plugin. But I'm not familiar enough with that space to answer the question definitively.
On the Google Zanzibar question: Google Zanzibar is a paper that came out — I want to say around 2019 — and it's a framework that Google basically gifted to the world. They'd been running it internally, and the basic premise is that you can push permission structures such that you don't have to constantly check a centralized service. Permify was inspired by that and heavily caches things internally in a way that allows for similar performance. Google came to the Zanzibar framework because they have tools like Google Drive, Google Maps, and Gmail, with very nested permission structures that needed to be responsive in microseconds or milliseconds. We can drop the link to the paper — I confess I haven't read the whole thing, but Google did a great thing by sharing it with the world. And Permify isn't the only implementation of Zanzibar — there are others as well.
Fantastic. I think that's it — we've run out of questions. I really appreciate everybody coming by today and taking time out of your day.
