Authorization (AuthZ)

Authorization (AuthZ) is the process by which a system determines what rights, actions and access an authenticated user has to specific resources, data or functionalities. After successful authentication, authorization verifies that the logged-in user is actually allowed to do what he or she is trying to do. Think of an employee who is allowed to view invoices but not change budgets, or a customer who is only allowed to view their own order history. For SMBs with Web applications, portals or API links, authorization is the key to secure and structured access.

How authorization works in practice

Authorization takes place after authentication. First, a user proves his identity (with password, token or Single Sign-On). Then the system checks which role or rights belong to that identity. This is usually done via roles (such as 'admin', 'editor', 'customer') or via detailed permissions per action ('read', 'write', 'delete'). For example, an ecommerce store allows a customer to access their own orders but not those of others. A CMS lets an editor edit articles but not delete users. This logic is often stored in a database or managed through an Identity Provider. With APIs, authorization is often done through tokens such as JSON Web Tokens, which contain claims about what the user is allowed. The W3C publishes guidelines for secure access control in Web applications.

Why authorization came into being and why it matters now

Vroeger hadden de meeste systemen één inlogniveau: je was binnen of buiten. Zodra organisaties complexere workflows kregen en meerdere gebruikersgroepen tegelijk bedienden, ontstond de behoefte aan gedifferentieerde toegang. Een dealer mag prijzen zien, een eindklant niet. Een accountant mag rapporten exporteren, een stagiair niet. Authorization maakt dat mogelijk zonder voor elke gebruiker een apart systeem te bouwen. Vandaag de dag is het onmisbaar voor compliance met de AVG: je mag alleen persoonsgegevens tonen aan wie daar recht op heeft. Ook bij API-koppelingen tussen systemen is authorization cruciaal om te voorkomen dat externe partijen meer data ophalen dan afgesproken.

What authorization brings to SMEs

Met een doordachte authorization-strategie voorkom je datalekken, bouw je vertrouwen bij klanten en voldoe je aan wettelijke eisen. Een groothandel kan bijvoorbeeld dealers toegang geven tot netto-prijzen terwijl particulieren bruto-prijzen zien, allemaal binnen één platform. Een softwarebedrijf kan klanten alleen toegang geven tot hun eigen omgeving, zonder dat andere klanten data kunnen inzien. Bij webontwikkeling en API-integraties bouwt Monkey Vision authorization in vanaf de basis, zodat je later niet hoeft te herschrijven. Goed geregelde autorisatie bespaart support-tickets, verkleint beveiligingsrisico's en maakt schaalbaarheid mogelijk zonder dat je de controle verliest.

Authorization plays a role in almost any digital environment where multiple users or systems have access to the same data. Below are four concrete applications that occur in Dutch SME practice, plus a decision criterion for when authorization is or is not the right approach.

Role-based access in web applications and portals

A common application is Role-Based Access Control (RBAC) in customer portals, intranets or SaaS platforms. You define roles such as "administrator," "user," "guest" and assign permissions to them. For example, a financial advisor with 8 employees gives only the office manager access to invoicing, while advisors are only allowed to view customer files. In an ecommerce store with B2B module, dealers can see net prices and use wholesale functions, while individuals only see the standard catalog. RBAC makes it easy to quickly give new employees the right permissions without manually configuring per function. The downside: in highly dynamic organizations with changing responsibilities, RBAC can become rigid. Then attribute-based authorization (ABAC) is more flexible, but also more complex to set up.

API security and data exchange between systems

When linking your CMS, CRM, accounting system or external platforms, authorization is indispensable. An API token provides access, but authorization determines which endpoints and data the token may retrieve or modify. For example, a marketing agency that manages campaigns on behalf of clients only gets read access to reporting endpoints, not write access to budgets. A logistics platform may update order statuses but not view customer data. This prevents a hacked integration from draining your entire database. In practice, you use scopes (OAuth 2.0) or claims in JWTs to define what is allowed per token. In API development and automation projects, Monkey Vision builds in these authorization layers by default, so that links are secure and future-proof.

Content management and editorial workflows.

In a CMS like WordPress or a headless solution, you often want editors to be able to edit content, but not publish it without approval. Or that a freelance copywriter can write blogs but not delete pages. Authorization makes those workflows possible. For example, a publishing house with 15 editors can determine who can publish for each section. A multi-vendor ecommerce store allows each vendor access only to its own product catalog. Without proper authorization, you either have to give everyone too many rights (risk of errors) or create a separate environment for everyone (unworkable). The choice moment: if you have fewer than five users with the same rights, a simple admin/non-admin layout is often sufficient. Once you have workflows or external parties in the mix, detailed authorization pays off the investment.

When authorization is the right choice and when it is not

Authorization makes sense as soon as you have multiple user groups with different rights, or as soon as you manage personal or confidential data. It is also necessary when APIs are called by external parties. But if you have a simple website with no login, or an internal tool for one person, authorization adds little and makes the code unnecessarily complex. A common mistake: add authorization only afterwards when there has already been an incident. Build it in from the start, otherwise you have to rewrite all the endpoints and screens later. Another misunderstanding: authorization is the same as authentication. That's not right. Authentication says who you are, authorization says what you are allowed to do. Both are necessary, but configurable separately.