Understanding access control: Authentication, authorization, and resource management

Access control is one of those topics that seems obvious until you look closely. It is also, year after year, the number one category in the OWASP Top 10 (Broken Access Control), and by far the most common weakness we see, both across the industry and in our own analyses. The good news is that once you have the right questions in mind, the topic becomes a lot simpler.

So what exactly is access control?

Access control is what determines who can do what, on which resource. When an application receives a request, it has to answer three questions, and all three matter.

1. Do I know who the user is? (authentication)

This is the identity step: is the user really who they claim to be? Passwords, MFA, SSO, all of these answer this first question.

2. Is this user allowed to perform this action? (authorization)

Knowing who the user is tells you nothing about what they are allowed to do. An authenticated user is not necessarily a user who is authorized to delete, edit, or administer.

3. Do they have the right to this specific resource? (object-level authorization)

This is the most frequently forgotten question. Having the right to view “one” entry does not mean having the right to view “all” entries. When this check is missing, we call it IDOR (Insecure Direct Object Reference): all it takes is changing an identifier in the request to reach someone else’s data.

Worth remembering: forgetting a single one of these three questions is enough to create a vulnerability. The three form a whole.

The question people forget: where does the check happen?

Answering the three questions correctly is not enough. You also have to ask where those checks are enforced. And this is exactly where the difference is made between a real security measure and a simple interface convention.

Client side

Client-side controls are enforced by the interface: a “Delete” button that is hidden, a greyed-out option, a menu that does not appear. This is useful and perfectly normal. It is what makes an application pleasant to use and steers users away from options that would simply be refused anyway. It is not what prevents the action: when access control is done properly, the server refuses the operation regardless of what the interface shows.

These controls live on the user’s side, and anyone who manipulates the requests directly can bypass them, because the interface is only one door among others to reach the data.

Server side

Server-side controls are enforced by the application itself, where the data lives. They do not depend on the interface being used and cannot be bypassed by crafting a request.

This layer, and only this layer, is what truly protects sensitive data: viewing, editing, deleting, revealing a password, accessing attachments, and so on.

A client-side check is a user experience convention, not a security measure. The rule is simple: any permission that protects sensitive data or a critical flow must be enforced server-side. A client-side check can accompany it, but never replace it.

What this means in practice for your data

Take the example of Remote Desktop Manager (RDM), our desktop application for managing remote connections and credentials. RDM offers a rich experience: permissions, roles, options shown or hidden depending on the user. But where are those permissions actually enforced? The answer depends entirely on the architecture of the workspace it connects to.

• A SQL Server workspace (a direct database connection). In this case, there is no application server between RDM and the database. RDM talks directly to SQL Server. The permissions exist, but they are enforced by the client. In other words, they all live on the client side. The server-side layer, the one that resists direct manipulation, is simply not present.
• A recommended workspace, one backed by an application server. It comes in two flavours: Devolutions Server (DVLS), the self-hosted workspace you deploy on your own infrastructure, and Devolutions Cloud, the fully managed, cloud-hosted workspace. In both cases, RDM is still the client, but it is the server that validates every access: who you are, what you are allowed to do, and on which specific resource. The three questions find their answer where it really counts, server-side.

This is not a question of good intentions or careful configuration. It is a question of architecture. Without an application server, there is no physical place to enforce server-side controls. That is the core reason we recommend pairing RDM with a Devolutions workspace, not as a product preference, but because the architecture demands it.

In summary

• Good access control answers three questions: who (authentication), what (authorization), and on which resource (object-level authorization).
• A client-side check improves the experience, but protects nothing on its own, since it can be bypassed.
• Only a server-side check truly protects sensitive data.
• For that server-side layer to exist, you need a Devolutions workspace behind RDM: Devolutions Server (DVLS) if you want to self-host, or Devolutions Cloud if you prefer a fully managed service.

If RDM currently connects directly to a SQL Server database, it is worth asking yourself: where are my access controls actually enforced? The architecture, not the configuration, will give you the honest answer. You can explore the available workspaces to see which one fits your environment.

And cost is rarely the obstacle people expect: both Devolutions Server and Devolutions Cloud offer a free option to get started. Using Devolutions Server as your backend simply requires an active Remote Desktop Manager Enterprise license, and since connecting RDM to a SQL Server database already requires that same Enterprise license, you most likely already hold everything you need to make the switch. (Reaching the workspace from a web browser, without RDM, uses a separate Client Access License.)