OAuth 2.0 en toegangstokens
Hoe OAuth 2.0 een applicatie beperkte toegang tot uw account geeft zonder uw wachtwoord, en hoe u het toestemmingsscherm leest.
In 30 seconden
- Waar het gebeurt
- Veel externe applicaties die gebruikers installeren, vragen toestemming om bij hun gegevens te komen en namens hen in te loggen bij andere online applicaties1.
- Wat de aanvaller wil
- U toegang laten geven aan een kwaadaardige applicatie, bijvoorbeeld na een link die u via gerichte phishing ontvangt2.
- De reflex
- Controleer voordat u op "Accepteren" klikt of de gevraagde machtigingen passen bij het doel van de applicatie, en weiger als dat niet zo is1.
- Als het al gebeurd is
- Een beheerder kan de applicatie blokkeren of intrekken1.
Waar gaat het over
OAuth is een open standaard voor authenticatie en autorisatie op basis van tokens. Met OAuth kan een externe dienst de gegevens van een account gebruiken zonder dat het wachtwoord van de accounthouder wordt blootgesteld1.
Neem een applicatie die uw agenda analyseert om u te adviseren over uw planning. De applicatie heeft toegang tot de agenda nodig, maar krijgt in plaats van uw inloggegevens een token, dat wordt aangemaakt wanneer u op een speciale pagina uw toestemming geeft1. Die pagina heet het toestemmingsscherm.
Directe vragen
Wat gebeurt er als ik een toestemmingsscherm accepteer?
De applicatie ontvangt een toegangstoken dat het delen van bepaalde accountgegevens toestaat, en alleen die1. Het wachtwoord blijft bij de aanbieder van het account.
Wat is een toegangstoken?
Het is een bewijs dat bedoeld is voor autorisatie: het geeft toegang tot bepaalde bronnen namens een gebruiker die al is geauthenticeerd. Microsoft vergelijkt het met sleutels die in een gebouw bepaalde deuren openen3. Omdat het toegang geeft, is het gevoelig en vormt het een risico als het slecht wordt beschermd3.
De geldigheidsduur is beperkt. Op het Microsoft-identiteitsplatform wordt de standaardwaarde willekeurig gekozen tussen 60 en 90 minuten, gemiddeld dus 75 minuten3.
Wat is een vernieuwingstoken?
Een vernieuwingstoken dient om een nieuw paar tokens te krijgen wanneer het toegangstoken verloopt. De client ontvangt het tegelijk met het toegangstoken4. Het blijft langer geldig: op het Microsoft-platform standaard 24 uur voor single-page-applicaties en voor applicaties die de authenticatiestroom met een eenmalige code per e-mail gebruiken, en 90 dagen in alle andere situaties4. Zo kan de applicatie op de achtergrond blijven werken zonder bij elk verlopen token opnieuw uw akkoord te vragen.
Waarom zijn deze tokens interessant voor aanvallers?
Met een gestolen token kan iemand handelen met de rechten van het account. MITRE ATT&CK beschrijft aanvallers die gestolen tokens gebruiken in plaats van inloggegevens5. Het vernieuwingstoken maakt het risico groter: als het wordt gestolen, krijgt de aanvaller nieuwe toegangstokens zonder de gebruiker erbij te betrekken2.
Kan de toegang van een applicatie worden ingetrokken?
Ja. Aan de beheerkant kan een applicatie worden geblokkeerd of ingetrokken via de pagina met OAuth-applicaties, en een beleidsregel kan het intrekken automatiseren1. Aan de tokenkant kan de dienst een vernieuwingstoken intrekken voordat het verloopt, bijvoorbeeld na een wachtwoordwijziging of een handeling van de gebruiker of de beheerder4. De gevolgen verschillen per type token en per doorgevoerde wijziging4.
1Hoe het werkt1 min
Er zijn drie partijen. De client is de applicatie die om toegang vraagt. De autorisatieserver geeft de tokens uit nadat hij de eigenaar van de gegevens heeft geauthenticeerd en diens toestemming heeft gekregen. De resourceserver bewaart de gegevens en accepteert verzoeken die vergezeld gaan van een token6.
Het toegangstoken vervangt de verschillende inloggegevens (bijvoorbeeld gebruikersnaam en wachtwoord) door één element dat de resourceserver begrijpt. Daardoor kan het een korte geldigheidsduur hebben6. Met het vernieuwingstoken kan een nieuw toegangstoken worden verkregen, met dezelfde of smallere rechten: een toegangstoken kan een kortere geldigheidsduur en minder machtigingen hebben dan de eigenaar heeft verleend6.
Het meest gebruikte token is het bearer-token: iedereen die het bezit, kan het gebruiken. OWASP raadt daarom aan het bij voorkeur te beperken tot één resourceserver, om de schade bij een lek te beperken6. De applicatie zelf moet het token behandelen als een ondoorzichtige tekenreeks: alleen de beoogde API mag de inhoud lezen3.
2Wat u doet1 min
Bij een toestemmingsscherm volstaan enkele controles.
- Lees het verzoek voordat u het accepteert. Gebruikers klikken vaak op "Accepteren" zonder de details te bekijken, ook de verleende machtigingen1.
- Vergelijk de machtigingen met het doel van de applicatie. Een applicatie zou alleen machtigingen moeten vragen die bij haar doel passen. Microsoft noemt als voorbeeld een klokapplicatie met volledige toegang tot alle mailboxen, wat niet bij haar doel past1.
- Wees op uw hoede voor de zwaarste machtigingen. MITRE ATT&CK wijst erop dat offline toegang en toegang om e-mail te lezen meer argwaan moeten wekken, omdat aanvallers de API's van onlinediensten kunnen gebruiken om daar naar inloggegevens en gevoelige communicatie te zoeken2.
- Kijk naar het omleidingsadres. Als het verkeerd gespeld is of een ingewikkelde reeks woorden rond een verwachte dienst vormt, probeert de site waarschijnlijk een echte dienst na te bootsen2.
- Kies liever voor gangbare applicaties. Hoe meer een applicatie wordt gebruikt, binnen de organisatie en online, hoe groter de kans dat ze veilig is1.
- Weiger een applicatie die u niet herkent. MITRE ATT&CK raadt aan gebruikers te leren onbekende externe applicaties niet toe te staan2.
- Een beheerder kan verdachte applicaties onderzoeken en verwijderen2.
3De valkuilen2 min
Het valse toestemmingsscherm
De aanvaller registreert een applicatie bij de autorisatieserver en stuurt daarna een gerichte phishinglink om het slachtoffer toegang te laten verlenen2. Een voorbeeld van Microsoft: een toestemmingspagina kan voor een gemiddelde gebruiker legitiem lijken, terwijl "Google APIs Explorer" geen enkele reden heeft om bij Google zelf machtigingen te vragen. De applicatie kan dus een phishingpoging zijn die niets met Google te maken heeft1.
Geruststellende namen komen veel voor. MITRE ATT&CK noteert dat de groep APT28 kwaadaardige applicaties gebruikte die zich bij Gmail-gebruikers voordeden als "Google Defender", "Google Email Protection" en "Google Scanner", en bij Yahoo-gebruikers als "Delivery Service" en "McAfee Email Protection"2.
Het token dat blijft werken
Zodra het token is verleend, kan de applicatie mogelijk langdurige toegang krijgen tot de functies van het account2. Met een vernieuwingstoken dat toegang op de achtergrond mogelijk maakt, kan een aanvaller bijvoorbeeld e-mails doorzoeken en contacten opsommen5. Uw wachtwoord wijzigen lost het probleem niet altijd op: volgens de tabel van Microsoft blijven sommige tokens actief na een wachtwoordwijziging door de gebruiker4.
Het token dat wordt gestolen zonder dat u iets wordt gevraagd
Tokendiefstal verloopt niet altijd via een toestemming. MITRE ATT&CK noemt ook tokens die zijn gestolen in containeromgevingen of ontwikkelstraten, waar ze dienen om te authenticeren bij andere diensten2. Het programma Kali365 zou OAuth-toegangs- en vernieuwingstokens hebben verkregen door slachtoffers te misleiden, zodat ze autorisatieverzoeken voor apparaten goedkeurden die de aanvaller had gestart2.
De vergeten applicatie
Een applicatie die ooit is toegestaan, blijft verbonden zolang niemand haar verwijdert. Microsoft raadt aan applicaties op te sporen waarvan de laatste autorisatie niet recent is: ze zijn misschien niet meer nodig1. MITRE ATT&CK vraagt beheerders om een audit van alle OAuth-applicaties en de verleende machtigingen, gevolgd door periodieke audits, met onderzoek naar en verwijdering van verdachte applicaties2. Voor medewerkers komt dit neer op een eenvoudig gebaar: loop af en toe de lijst met applicaties na die aan uw account zijn gekoppeld en meld de applicaties die u niet herkent.
Fiche
- Identificatie
- CP-194
- Vleugel
- 3. Protocollen en verdediging
- Brain-competentie
- Toegang beheersen (control_access)
- Brain-reflex
- cr-026
- Schema
- G3 · Anatomische doorsnede
- Talen
- de, en, es, fr, it, nl
- Bronnen
- 6 bronnen gecontroleerd op 3 november 2026
Bronnen6 bronnen
- Microsoft, “Investigate and remediate risky OAuth apps”. https://learn.microsoft.com/en-us/defender-cloud-apps/investigate-risky-oauth (geraadpleegd op 3 november 2026)
- MITRE ATT&CK, “Steal Application Access Token, Technique T1528 - Enterprise”. https://attack.mitre.org/techniques/T1528/ (geraadpleegd op 3 november 2026)
- Microsoft, “Access tokens in the Microsoft identity platform”. https://learn.microsoft.com/en-us/entra/identity-platform/access-tokens (geraadpleegd op 3 november 2026)
- Microsoft, “Refresh tokens in the Microsoft identity platform”. https://learn.microsoft.com/en-us/entra/identity-platform/refresh-tokens (geraadpleegd op 3 november 2026)
- MITRE ATT&CK, “Use Alternate Authentication Material: Application Access Token, Sub-technique T1550.001 - Enterprise”. https://attack.mitre.org/techniques/T1550/001/ (geraadpleegd op 3 november 2026)
- OWASP, “OAuth2 - OWASP Cheat Sheet Series”. https://cheatsheetseries.owasp.org/cheatsheets/OAuth2_Cheat_Sheet.html (geraadpleegd op 3 november 2026)
Dit artikel citeren
Brain, “OAuth 2.0 en toegangstokens”, Cyberpedia, 2026. https:/
BibTeX
@misc{brain_cp194_nl_2026,
author = {Brain},
title = {OAuth 2.0 en toegangstokens},
year = {2026},
howpublished = {Cyberpedia},
url = {https://startbrain.io/cyberpedia/nl/articles/oauth-2-gedelegeerde-toegang-tokens/},
note = {CC BY 4.0}
}