TL;DR
- Authenticatie vraagt wie je bent door de inloggegevens van een individu te identificeren, of dat nu via een wachtwoord, passkey, multifactor-authenticatieprompt, enz. gebeurt, enkel om hun identiteit te valideren.
- Autorisatie vertelt je wat je kunt doen door te beoordelen welke rol/attribuut/beleid van toepassing is op elke gevalideerde gebruiker/workload. Het bepaalt tot welke resources/acties zij toegang hebben nadat ze zijn geauthenticeerd.
- OpenID Connect (OIDC) wordt gebruikt voor authenticatie, terwijl OAuth 2.0 wordt gebruikt voor op delegatie gebaseerde autorisatie van API's/services.
- Het verwarren van authenticatie en autorisatie kan leiden tot ernstige ontwerpfouten, zoals het verlenen van toestemming aan een geldige login om plotseling alle mogelijke acties uit te voeren (zelfs als dat niet binnen hun rechten valt); het toewijzen van te ruime rollen aan gebruikers; en het vertrouwen op hardcoded controles van machtigingen die moeilijk te volgen, beheren en auditen zijn.
Inleiding
Het internet doet het momenteel niet zo goed en stort in. De cPanel- en WHM-authenticatiebypass CVE-2026-41940 liet ons zien hoeveel hostingproviders nog steeds vastzitten op oudere versies en hoe hun potentiële blast radius er daadwerkelijk uitziet. En deze exploit treft alle versies.
Voor iedereen die gecompromitteerd raakt, is het een goede herinnering om je infrastructuur te beschermen met sterke netwerksegmentatie.
Microsoft kreeg onlangs ook te maken met een enorme meerfasige phishingcampagne die gericht was op meer dan 35k gebruikers in meer dan 13k organisaties. Hackers gebruikten Adversary-in-the-Middle (AiTM)-technieken om MFA te omzeilen en sessiecookies te stelen.
Als dit verwarrend klinkt en je het verschil niet kent tussen authenticatie- en autorisatieaanvallen, lees dan verder. Hieronder leggen we het uit.
Wat is authenticatie?
Authenticatie laat de gebruiker bewijzen wie hij of zij is en beschermt gevoelige gegevens tegen ongeautoriseerde toegang. Het blokkeert illegale toegang en laat de gebruiker inloggegevens zoals gebruikersnaam en wachtwoord verstrekken om in te loggen op systemen.
Voor niet-digitaal gebruik moeten documenten notarieel worden gevalideerd. In preventieve beveiliging wordt authenticatie gebruikt om gevoelige gegevens te beschermen.
Veelvoorkomende authenticatiemethoden
Authenticatie vertrouwt op een of meer van deze factoren om je identiteit te verifiëren:
- Wachtwoorden, pincodes en antwoorden op veelvoorkomende beveiligingsvragen die alleen jij kent
- Smartcards, hardwaretokens en OTP's
- Biometrie zoals vingerafdrukscans, gezichtsherkenning en irisscans.
Typen authenticatieaanvallen
Hier zijn de veelvoorkomende typen authenticatieaanvallen waarvan je op de hoogte moet zijn:
- Credential stuffing en brute force. Het opnieuw gebruiken van gebruikersnaam-/wachtwoordcombinaties uit eerdere datalekken of het bestoken van zwakke logins wanneer rate limiting onvoldoende is.
- Phishing en MFA-moeheid. Gebruikers misleiden om inloggegevens prijs te geven of prompts goed te keuren, vaak via social engineering die vertrouwde merken nabootst.
- Sessiekaping. Tokens stelen uit browsers, apparaten of geheugen zodat een aanvaller het inlogformulier volledig kan overslaan.
- Compromittering van apparaten. De controle overnemen van een vertrouwd apparaat dat controles al heeft doorstaan, en vervolgens misbruik maken van de sessiecontext die daarbij hoorde.
Wat is autorisatie?
Autorisatie is een beveiligingsproces waarbij bij een ingelogde gebruiker wordt gecontroleerd wat die binnen een netwerk of systeem mag doen. Het vertelt je in feite wat je kunt doen of wat je mag doen (binnen aanvaardbare rechten).
Autorisatie vindt alleen plaats na succesvolle authenticatie, niet ervoor. Het evalueert de identiteit van de gebruiker aan de hand van een set regels of beleidsregels en verleent of weigert vervolgens toegang tot specifieke resources.
Typen autorisatiemodellen en protocollen
Hier zijn de veelvoorkomende typen autorisatierollenmodellen waarvan je op de hoogte moet zijn:
- Role-based access controls (RBAC): Machtigingen worden toegekend aan specifieke rollen zoals admins, editors en viewers, in plaats van aan individuele gebruikers. Het is een van de meest gebruikte modellen in bedrijfsomgevingen.
- Attribute-based Access Controls (ABAC): Dit zijn zeer flexibele autorisatiemodellen die attributen gebruiken om beslissingen te nemen. Ze kunnen gebruikers- en afdelingsgegevens, informatie over het resourcetype en omgevingscontexten omvatten (zoals apparaatbeveiliging, locatie, tijdstip van de dag, enz.)
- Discretionary Access Control: De eigenaar van de resource heeft volledige controle over wie toegang heeft tot wat en wie er toegang toe heeft. Het is vergelijkbaar met bestandsdeling op Google drive of Windows-mappen.
- Mandatory Access Control (MAC): Dit is een van de meest restrictieve autorisatiemodellen waarbij toegang is gebaseerd op strikt gedefinieerde beveiligingslabels. Het beheert je geheimen centraal en wordt zeer vaak gebruikt in militaire systemen en overheidsomgevingen met een hoog beveiligingsniveau.
- Relationship-based access control (ReBAC): Je toegang wordt bepaald op basis van de relatie tussen een gebruiker en een resource. Dit is wat persoonlijker en vergelijkbaar met eigenaar zijn van een resource, waarbij het lid deel uitmaakt van de specifieke mappen daarvan.
En voor moderne autorisatietypen en protocollen is dit wat je moet weten:
- OAuth 2.0: Dit is de industriestandaard voor gedelegeerde autorisatie. Het stelt apps van derden in staat om toegang te krijgen tot je gegevens zonder wachtwoorden te zien.
- JSON Web Tokens (JWT): Dit is een compacte, URL-veilige manier om claims tussen twee partijen weer te geven. De server geeft een JWT wanneer iemand inlogt, wat in feite zegt "de gebruiker is geautoriseerd voor X", dat je ook kunt presenteren om andere daaropvolgende verzoeken te bevestigen.
- Access Control Lists (ACLs): Dit is een eenvoudige lijst die aan een resource wordt gekoppeld en waarin je gebruikers en groepen worden genoemd. Ook wordt aangegeven welke machtigingen zij hebben. Het enige nadeel is dat dit op grotere schaal veel moeilijker te beheren wordt naarmate je organisatie groeit.
Kritieke verschillen tussen authenticatie en autorisatie
Je zult het verschil tussen authenticatie en autorisatie vaak in één zin samengevat zien, maar ontwerpwerk vereist meer detail. Hier zijn de gebieden waarop authenticatie en autorisatie uiteenlopen.
1. Volgorde in toegangsflows
Authenticatie vindt plaats vóór autorisatie. Tijdens de authenticatiefase wordt een identiteitscontext gecreëerd. Vervolgens wordt tijdens de autorisatiefase met deze identiteitscontext rekening gehouden bij de beslissing of een bepaalde actie mag plaatsvinden.
Met andere woorden: door deze fasen onafhankelijk te laten verlopen (en ze niet als één enkel proces te behandelen), kun je ervoor zorgen dat je elk van de daaropvolgende stappen op beveiliging valideert, ook al "is de gebruiker al geauthenticeerd". In gezonde systemen verloopt elke gevoelige actie via beide lagen.
2. Gebruikte gegevens
Authenticatie gebruikt wachtwoorden, pincodes, antwoorden op beveiligingsvragen, bezitsfactoren (zoals OTP's via e-mail en sms, serienummers van hardwaretokens, digitale certificaten), inherente factoren (vingerafdruktemplates, geometrische gezichtsscans, irispatronen) en entiteits-ID's (unieke identificatoren zoals e-mailadressen, personeels-ID's en gebruikersnamen).
Autorisatie gebruikt gegevens die verband houden met machtigingsregels, zoals labels die aan identiteiten zijn toegewezen (gebruikersrollen), gebruikers- en resourceattributen (specifieke metadata over personen en objecten waartoe toegang wordt verkregen) en omgevingscontext (IP-adressen, apparaatstatus, tijdstippen en locaties).
3. Faalmodi en foutafhandeling
Fouten bij auth-failures leiden doorgaans tot meldingen over ongeldige inloggegevens of CAPTCHA-/MFA-uitdagingen, terwijl herhaalde pogingen meestal leiden tot vergrendeling van het account van de gebruiker. Aan de andere kant produceren auth-failurefouten forbidden-meldingen, verbergen ze resource-informatie of vragen ze om aanvullende autorisatie voor toegangsbeheerrechten.
Het afhandelen van auth-failurefouten als standaardfouten of silent failure-fouten bemoeilijkt incidentrespons. Correcte logging en differentiatie tussen auth- en authenticatiefouten stellen responders in staat te bepalen of aanvallers de deur hebben bereikt of het pand aan het verkennen zijn.
4. Eigenaarschap en verantwoordelijkheden
Eigenaarschap van authenticatie ligt doorgaans bij het identity-team of de platformteams die zich bezighouden met single sign-on (SSO), MFA en identity providers. Eigenaarschap van autorisatie ligt daarentegen bij het applicatieteam, het securityteam en data-eigenaren die weten wat voor elke actie vereist moet zijn.
Als één team de volledige controle neemt terwijl de business-eigenaren niet zijn geraadpleegd, is er waarschijnlijk sprake van een verschuiving in machtigingen.
Authenticatie versus autorisatie: belangrijkste verschillen
Wil je authenticatie en autorisatie vergelijken of in één oogopslag een overzicht krijgen? Hier is een snelle referentie:
| Kenmerk | Authenticatie | Autorisatie | Voorbeeld |
| Primaire vraag | Verifieert wie de gebruiker of workload is. | Bepaalt waartoe die identiteit toegang heeft. | Een medewerker logt in met MFA, waarna een beleidsregel bepaalt welke HR-records die mag bekijken. |
| Typische gegevens | Inloggegevens, biometrie, apparaat- of workloadidentiteiten. | Rollen, attributen, resourcelabels, risicoscores. | Een API-aanroep bevat een ID-token plus een role-claim en projecttag. |
| Belangrijkste standaarden | OIDC, SAML, platform-inlogprotocollen. | OAuth 2.0, policy engines, ABAC- en RBAC-regels. | OIDC logt een gebruiker in, OAuth-scopes definiëren welke API's die kan aanroepen. |
| Wanneer het wordt uitgevoerd | Voordat toegang wordt verkregen tot een beschermde resource. | Bij elke toegangsbeslissing na authenticatie. | De gebruikerssessie is geldig, maar een overdracht met hoog risico activeert nog steeds een aanvullende controle. |
| Gedrag bij falen | Blokkeert de login of vraagt om meer bewijs. | Weigert specifieke acties, verbergt resources of escaleert voor beoordeling. | Een wachtwoordreset mislukt versus een scherm voor betalingsgoedkeuring waarop “niet toegestaan” staat. |
Veelvoorkomende fouten die ondernemingen maken bij authenticatie versus autorisatie
Hier is een lijst met veelvoorkomende fouten rond authenticatie en autorisatie die elke onderneming moet vermijden:
Login behandelen als de enige poort
Andere teams denken misschien dat als de gebruiker al is ingelogd, alles wat hij binnen de applicatie doet acceptabel is. Processen met een hoog risico, zoals alle gegevens in één keer exporteren, configuraties wijzigen of tokens genereren, worden daardoor afhankelijk gemaakt van slechts dat ene loginproces.
Je kritieke acties moeten worden beschouwd als onafhankelijke controlepoorten die hun eigen controles uitvoeren voor autorisatie, risicobeoordeling en zelfs authenticatie. Dit kan bijvoorbeeld betekenen dat je je MFA-vereisten verhoogt voor bankoverschrijvingen.
Te ruime rollen en machtigingen “voor het geval dat”
Een natuurlijke neiging is om ruime rechten toe te kennen zodat teamleden “snel kunnen handelen” en zaken later kunnen uitzoeken. Onderzoek naar autorisatiefouten laat zien dat dit “later” nooit komt, en na verloop van tijd verzamelen accounts onnodige rechten die een aanvaller kan misbruiken.
Je inspanningen zullen meer succes opleveren door vanaf het begin rollen met een beperkte scope te ontwerpen en ervoor te zorgen dat ze op taken zijn afgestemd. Het beoordelingsproces is een integraal onderdeel van elke inspanning voor hercertificering van toegang, net als het elimineren van onnodige privileges.
Hardcoded controles in applicatiecode
Wanneer de autorisatielogica over verschillende services is verspreid, vormt elke nieuwe productlancering een nieuw risico op regressie van machtigingstoegang. Wanneer ontwikkelaars copy-paste-technieken gebruiken, zoals “if user.is_admin”, betekent dit dat ze sommige edge cases kunnen missen en het auditors moeilijker maken.
Het probleem kan worden beperkt door machtigingslogica te centraliseren in beleidsregels of gespecialiseerde services waartoe security- en complianceteams toegang hebben. De producten bepalen nog steeds welke beleidsregels moeten worden gebruikt, terwijl machtigingen centraal worden beheerd.
Authenticatie vs. autorisatie in Zero Trust en moderne architecturen
Identiteit wordt de nieuwe beveiligingsperimeter in zero-trustarchitecturen. Systemen verifiëren continu je identiteit en apparaatstatus gedurende sessies. Machtigingen zijn niet langer statisch; ze worden op het moment van elk verzoek geëvalueerd op basis van een breed scala aan realtime signalen.
Moderne autorisatie-engines gebruiken Policy Decision Points (PDP's) om deze signalen te evalueren voordat toegang wordt verleend. Ze houden rekening met resourcegevoeligheid, apparaatstatus, gebruikersidentiteit en locatie/netwerken.
In cloud-native omgevingen wordt ook rekening gehouden met Machine-to-Machine (M2M)-beveiliging, aangezien autorisatie niet alleen voor mensen bedoeld is. Service-identiteiten (niet-menselijke gebruikers) worden nu ook geauthenticeerd en geautoriseerd voordat ze moderne protocollen zoals SPIFFE en MTLS mogen gebruiken om te voorkomen dat geautomatiseerde systemen zich lateraal door netwerken verplaatsen, en zo vervolgcompromissen te voorkomen (als er één wordt gecompromitteerd).
Hoe je veiligere authenticatie- en autorisatieflows ontwerpt: best practices voor authenticatie versus autorisatie
De beste ontwerpen voor authenticatie versus autorisatie kijken vooruit. Ze bereiden je organisatie voor op de manier waarop aanvallers identiteiten misbruiken in 2026, niet op verouderde dreigingsmodellen. Dit zijn de beste authenticatie- en autorisatiepraktijken die je kunt gaan toepassen:
- Gebruik OIDC voor inloggen en OAuth voor API-toegang. Houd identiteitsbewijs en gedelegeerde toegang gescheiden, zodat je ID-tokens voor authenticatie en scopes voor autorisatie kunt valideren zonder hun verantwoordelijkheden te vermengen.
- Pas least privilege by design toe, niet als opschoontaak. Bouw rollen en beleidsregels die aansluiten op echte functies, vereis rechtvaardiging voor krachtige rechten en plan regelmatige toegangsbeoordelingen om ongebruikte machtigingen te verwijderen voordat aanvallers ze vinden.
- Geef de voorkeur aan op beleid gebaseerde autorisatie boven verspreide controles. Verplaats toegangsregels naar dedicated policy engines of services en laat applicaties die vervolgens aanroepen voor elke gevoelige actie. Zo blijven audits, wijzigingen en tests op één plek.
- Schakel continue en risicobewuste authenticatie in. Combineer signalen zoals blootstelling van inloggegevens, apparaatstatus, geolocatie en gedragsanalyse, zodat acties met een hoog risico step-up MFA of tokenintrekking activeren in plaats van te vertrouwen op één enkel login-event.
- Verkort tokenlevensduren en gebruik just-in-time-elevatie. Geef kortlevende tokens uit met beperkte scopes en verleen vervolgens alleen tijdelijke admin-toegang wanneer iemand daarom vraagt en extra controles doorstaat. Laat die toegang automatisch verlopen zodra de taak is voltooid.
- Breng identity-logs samen met endpoint- en workloadtelemetrie. Stream authenticatie- en autorisatie-events naar hetzelfde data lake dat EDR- en cloud-workloadsignalen vastlegt, zodat je aanvallen kunt traceren die identiteits-, apparaat- en workloadgrenzen overschrijden.
- Test faalpaden net zo zorgvuldig als succespaden. Voeg geautomatiseerde tests en chaos-achtige oefeningen toe die authenticatie- en autorisatievoorwaarden opzettelijk laten mislukken, zodat je kunt bevestigen dat fouten, waarschuwingen en logging zich gedragen zoals verwacht.
Als je deze praktijken consequent volgt, zul je minder “mystery admin”-accounts zien, duidelijkere attributie bij incidenten hebben en een veel kleiner tijdsvenster waarin een aanvaller een gestolen identiteit kan gebruiken voordat je controles reageren.
Hoe SentinelOne identiteitsbeveiliging versterkt
Het Singularity Platform van SentinelOne wordt aangedreven door Autonomous Security Intelligence (ASI) — het intelligence-weefsel dat in de basis van het platform is ingebouwd en kwaadaardig gedrag identificeert, kritisch werk automatiseert en met machinesnelheid op dreigingen reageert. Waar identity providers beheren wie kan inloggen en waartoe toegang mogelijk is, voegt Singularity Identity de beveiligingshandhavingslaag toe — door misbruik van inloggegevens te detecteren, laterale verplaatsing te stoppen en je authenticatie- en autorisatiebeleid te beschermen tegen dreigingen die standaard toegangscontroles omzeilen.
Je kunt Singularity™ Identity gebruiken om toegangspogingen te monitoren en te blokkeren en te voorkomen dat threat actors gebruikersinloggegevens van endpoints verzamelen.
De conditional access-beleidsregels van Singularity Identity kunnen autonoom step-up-authenticatie activeren — zoals aanvullende MFA-prompts — wanneer verdacht gedrag van gebruikers of apparaten wordt gedetecteerd. Het helpt ook MFA-moeheid te voorkomen en staat bypass-aanvallen niet toe door login-events te correleren met apparaatstatus en gedragssignalen.
Singularity Identity identificeert continu zwakke punten in je authenticatie-infrastructuur — waaronder blootgestelde serviceaccounts, zwakke wachtwoordconfiguraties en Active Directory-misconfiguraties — voordat aanvallers deze kunnen misbruiken. Lees meer op de Singularity Identity-productpagina. Je kunt SentinelOne ook gebruiken om privilege-escalaties te voorkomen en aanvallers te blokkeren die al zijn geauthenticeerd maar admin- of rootrechten proberen te verkrijgen. Dit voorkomt laterale verplaatsingsaanvallen en stopt ze direct.
SentinelOne gebruikt deception technology en lokmiddelen om ongeautoriseerde gebruikers ertoe te verleiden zichzelf te onthullen wanneer ze proberen toegang te krijgen tot gegevens die ze niet zouden mogen zien. In een zero-trustarchitectuur biedt Singularity Identity continue validatie van intentie en kan het met machinesnelheid toegang intrekken wanneer het gedrag van een gebruiker afwijkt van de geautoriseerde functie. Het identificeert ook misconfiguraties in Access Control Lists (ACL's) en kan deze aanpakken.
Krijg realtime identiteitsbescherming en end-to-end zichtbaarheid in hybride omgevingen om blootstellingen te detecteren, misbruik van inloggegevens te stoppen en identiteitsrisico te verminderen.
Conclusie
Authenticatie en autorisatie maken beide deel uit van cloud en cybersecurity. Zolang je met menselijke en niet-menselijke gebruikers werkt, heb je beide nodig. Het is een ontwerpbeslissing die vormgeeft aan hoe elk account, elke service en elke agent zich binnen je omgeving gedraagt. Wanneer je ze als afzonderlijke lagen behandelt en ze koppelt aan workflows voor continue verificatie, worden misbruikte identiteiten veel gemakkelijker te herkennen en in te dammen.
Naarmate identiteitsaanvallen blijven toenemen, geeft het Singularity Platform van SentinelOne — dat identity-, endpoint- en cloud-workloadbescherming omvat — securityteams de uniforme context die ze nodig hebben om zowel menselijke als niet-menselijke identiteiten tijdens runtime te beveiligen. Boek een live demo om het in actie te zien.
Veelgestelde vragen
Nee, autorisatie is niet mogelijk zonder authenticatie. Autorisatie controleert wat een geauthenticeerde identiteit mag doen. Als je niet eerst hebt geverifieerd wie iemand is, is er geen gebruiker waarop je machtigingen kunt toepassen. Sommige sites laten je als gast browsen zonder in te loggen, maar dat is geen echte autorisatie—het is gewoon open, niet-geauthenticeerde toegang. Een goede regel is dat je altijd eerst moet authenticeren voordat je rollen of toegangscontroles afdwingt.
OAuth 2.0 is voor autorisatie. Het geeft apps beperkte toegang tot de gegevens van een gebruiker zonder hun wachtwoord te delen. OIDC is gebouwd op OAuth en verzorgt authenticatie door een ID-token met identiteitsclaims toe te voegen. Dus als je moet verifiëren wie iemand is, gebruik je OIDC. Als je alleen gedelegeerde toegang nodig hebt, is OAuth voldoende. Ze werken samen, maar ze vervullen verschillende taken.
Rollen zijn verzamelingen van machtigingen die je aan gebruikers toewijst, zoals “admin” of “viewer.” Attributen zijn feiten over een gebruiker, apparaat of sessie—zaken zoals afdeling, autorisatieniveau of locatie. Autorisatie kan alleen rollen controleren, of je kunt attributen combineren om fijnmazigere beslissingen te nemen. Je kunt bijvoorbeeld alleen toegang toestaan als de rol manager is en het attribuut department=sales is. Er zijn veel manieren om dit soort beleidsregels op te zetten.
SSO authenticeert je één keer en deelt die identiteit over apps heen, maar elke app voert nog steeds zijn eigen autorisatiecontroles uit. MFA verhoogt hoe sterk je bewijst wie je bent. Je kunt beleidsregels opstellen die MFA vereisen voordat toegang tot gevoelige gegevens wordt geautoriseerd. Als MFA mislukt, krijgt autorisatie nooit de kans om door te gaan. MFA verleent dus niet op zichzelf machtigingen, maar kan ze wel afschermen op basis van de sterkte van de aanmelding.
Verzamel voor authenticatie succesvolle en mislukte aanmeldingen, lock-outs, MFA-prompts en bron-IP's. Verzamel voor autorisatie toegangsweigeringen, machtigingswijzigingen, roltoewijzingen en privilege-escalaties. Je moet deze ophalen uit je identiteitsprovider, apps en beveiligingstools. Als je deze logs hebt, kun je nagaan of een incident begon met gestolen inloggegevens of misbruik van toegekende rechten. Ze helpen je een duidelijke tijdlijn op te bouwen.
