You Don't Know Who Your Users Are.
You might actually do know - but I like provocative headlines. Bear with me.
Hello again folks! Daniel here again with another digest 💌
This week, let’s talk about the biggest threat to every developer and their sanity.
No, not product managers. Why would you think that?
I’m talking about users
Users (hopefully) use your app. While doing so, they also experience experiences. The thing is, users are usually allowed to see and do different things in apps based on the level of access we want to grant them. So far, so good.
But what if I told you that when I say users, I’m probably not referring to the same entities you're thinking about? Let me convince you.
Who Uses Our Application?
The question “Who Uses Our Application?” can be a lot less straightforward than you might think. It obviously depends on the individual thing that you are building, but let’s look at just one example:
End Users
Ok, these are easy, and they are the ones you were probably thinking about. End users are the primary group interacting with your application to utilize its services. Something to think about is that their interaction spans multiple areas, which all must be considered when designing our authorization layer:
Frontend—We need to control what users can see in the application. Not all users should have access to every feature. Think about payment/subscription status as an example: paying users might have access to premium features that non-paying users cannot see.
Backend—We obviously need to manage what actions users can perform. The simplest example comes from the solution side of things: In a Role-Based Access Control (RBAC) system, users with an Editor role will have different permissions than those with a Viewer role.
DB—We must also regulate which data users can access, whether it's stored in local or external databases.
“Users”, by the way, aren’t just humans - especially with LLMs and AI on the rise. End users can include automated systems or bots that interact with the application.
Internal Users
Taking this one step deeper, we have users who are members of our organization who need access to the application. Take a banking app - end users are the bank’s customers, while internal users include tellers and account managers. These internal users often require different levels of access, and some may need to manage and delegate access to end-users.
An account manager, for instance, might need to approve loan requests from clients. As these are not technical users, they need to be provided with an interface (And hopefully a simple one they can use without opening R&D tickets for every permission request) that allows them to easily manage and make changes to the end-user authorization layer within strict, pre-defined limits.
Organizational Stakeholders
So we have end users and internal users. We’ll get to the developers themselves. But what about DevOps? RevOps? AppSec? These folks also might need access to specific parts of the application and perhaps even the ability to manage user roles and delegate access management to internal users. You see where I’m going with this?
Developers
The app developers themselves are in charge (albeit reluctantly) of building and implementing the application's security features. Including authorization. They need a level of user permissions management that allows them to create and handle new policies, requests, and processes, and these impact all other levels. This obviously doesn't mean their access is unlimited, and it requires monitoring and management as well.
Authorization Administrators (Overseers)
The cherry on top of this pie is the fact that someone needs to decide what can the developers themselves access and what level of control they have over our application's authorization layer.
More often than not, a specific poor soul (person or group) will be directly in charge of managing the application’s user and role management. These “Authorization Administrators” (Or, as I decided to call them here after watching the new Fallout series - Overseers) decide what access developers have and control the authorization system's management.
They create access request flows and ensure a secure management structure. To avoid creating a centralized root user, they obviously do not have the ability to manage individual authorization policies fully.
That’s So Many Users!
It is. Different kinds, with different requirements, technical knowledge, and required responsibility.
The prospect of creating all-powerful superusers is alluring to many developers. I mean, what can be more secure than directly calling all the shots yourself? And while that’s true to some extent, this approach backfires very quickly. If you, as a developer, are the person directly in charge of all user roles and permission management in your organization, you will very quickly realize the strain this will have on you and the entire R&D team as you turn into a bottleneck for the entire business operation.
Only one person/group can manage authorization for every user of your application? Great - it’s their full-time job now.
The opposite approach, delegating all power away from developers to other stakeholders, is often equally dangerous. It creates a slow-moving, inefficient bureaucracy (I’m looking at you, security and compliance) or an unstable, risk-filled environment (hi, sales and product).
At the end of the day, it’s a question of balance—one that varies for every company and application. So what can we do about it? Here are some ideas -
Building a Cascading Authorization Model
A Cascading System of Trust and Permissions By creating a cascading system of permissions and trust, you can ensure that the right permissions are granted to the right users at the right time. Often, developers and security become the main part of this waterfall, but it can’t solely depend on them. Design your flow to gradually delegate access in a balanced amount between the different levels, with each level empowering the ones below it.
Assign an owner To avoid conflicts, such as two admins being able to remove each other, always have a primary admin, or “owner,” who takes precedence to avoid conflict. Owners often cannot be removed without transferring the title first.
Identify bottlenecks early on Identify potential bottlenecks in permissions that are hard to delegate or manage, and have a plan and interfaces to mitigate these issues in advance - before friction piles up.
Use classic policy models for your ‘high-level’ authorization policies (e.g. RBAC, ABAC) Just like with your regular permissions, there’s no need to reinvent the wheel. When handling the higher levels of your user waterfall (Organizational Stakeholders, Developers, and Overseers), start with a common policy model first. It’s even better if you can use the same policy model across the different levels, if applicable. This can help ensure consistency and ease of understanding across the system, lowering the cognitive load on system managers and users.
Generate audit logs across the entire authorization system The information on who changed permissions at every level of this waterfall is crucial - especially at its higher levels. Make sure to log and track these changes.
Build on top of existing cascading authorization solutions Some tools (Like Permit.io WINK WINK) provide a cascading system of authorization from the get-go, so you don’t have to design one from scratch. This could be useful to save time and effort and help build a more secure system.
That’s a Lot to Consider! What’s Next?
First of all, if you've survived this newsletter so far, the first step to building a secure authorization system for your application is already behind you. How so? Because you care enough to learn new things while I try to spice them up with memes. If you want to read more on this subject, I suggest you check out one of our latest blogs:
“Best Practices for Effective User Permissions and Access Delegation”. It covers a lot of the things we discussed here but goes into more detail.
If Frontend is your realm, we're hosting a live stream later this month titled “Frontend Authorization - Building Personalized, Secure Frontend Experiences.” We’d be glad to see you there!
Finally, any chance you’re planning to attend Render Atlanta next week? If you are - Come say hi!
We have some really cool stuff prepared for that.
As always, it’s been a pleasure. I invite you to join our Slack Community for more discussions, and don’t forget to subscribe to this Substack if you haven’t already! ❤️
Happy Pride Month Y’all 🌈
Daniel