OAuth-app-toestemmingen controleren en intrekken in Microsoft 365 en Google Workspace

Op vrijdagmiddag stonden er veertien app-toestemmingen in je tenant die niemand kon plaatsen. Je trok ze alle veertien in. Maandagochtend loopt de urenkoppeling niet meer, staat de mailarchivering stil en haalt de nieuwsbrieftool geen adressen op. Opruimen was de juiste beweging. De volgorde was fout.

Dat die lijst moet worden opgeruimd, staat buiten kijf: een goedgekeurde OAuth-app behoudt zijn toegang ook nadat de gebruiker zijn wachtwoord reset of je MFA afdwingt. Deze gids blijft strikt bij die ene klus. Je vindt de toegekende app-toestemmingen in Microsoft 365 (Entra ID) en Google Workspace terug, je weegt ze, en je trekt in wat weg moet, in een volgorde die je legitieme koppelingen heel laat. De inlog zelf valt buiten deze scope: die pak je aan met een gefaseerde overstap van sms-MFA naar passkeys in Entra ID, een aparte klus met zijn eigen deadline.

Een OAuth-app-toestemming is een verleende machtiging waarmee een externe applicatie namens één gebruiker of namens je hele organisatie bij je data mag. De app werkt daarna op eigen tokens, los van het wachtwoord en de tweede factor van die gebruiker. De machtiging blijft geldig tot iemand haar bewust intrekt.

Wat je nodig hebt

Deze klus kost geen euro aan tools. Hij kost je wel de juiste rechten, en een half uur voorbereiding die je later een storing scheelt. De vereisten die mensen onderschatten zijn de PowerShell-module (want een deel van het werk kan de portal simpelweg niet) en de eigenaarslijst (want zonder eigenaar is elke intrekking een gok).

Een licentiedetail dat de planning bepaalt: de sign-in-rapporten waarmee je meet of een app nog leeft, vragen Entra ID P1 of P2, en de minst-bevoorrechte rol daarvoor is Reports Reader. Zit je op een plan zonder P1, dan verschuift stap 3 naar handwerk: de eigenaar bellen. Dat werkt ook, het duurt alleen langer.

De veilige volgorde

Het verschil tussen een opruimactie en een storing zit niet in de knop, maar in de reeks. Eerst weten wat er staat, dan wegen, dan meten of het nog leeft, dan smal intrekken, dan de herconsent dichtzetten, en pas daarna breed doorpakken. Wie stap 3 overslaat, sloopt op maandag iets dat op vrijdag nog werkte. Wie stap 5 overslaat, ziet dezelfde app twee weken later terugstaan.

1. Trek de volledige lijst uit je tenant. In het Microsoft Entra-beheercentrum vind je hem via Entra ID, Enterprise apps, All applications; je selecteert een app en opent Permissions. Daar staan twee tabbladen: Admin consent voor wat er tenantbreed geldt, en User consent voor wat individuele gebruikers zelf goedkeurden. Per app klikken is onbegonnen werk. Microsoft verwijst in zijn eigen aanpak naar het script Get-AzureADPSPermissions.ps1, dat alle consent-grants van je hele tenant in één CSV zet:

.\Get-AzureADPSPermissions.ps1 | Export-csv -Path "Permissions.csv" -NoTypeInformation

In de kolom ConsentType staat AllPrincipals bij de grants die voor iedereen gelden; alle andere rijen zijn toestemmingen van één gebruiker. Dat onderscheid is de kern van de rest van deze gids, want consent phishing landt vrijwel altijd in die tweede categorie. Wil je één persoon nalopen, dan kan dat ook zonder script: Entra ID, Users, All users, de gebruiker, dan Applications.

In Google Workspace zit de lijst in het beheerpaneel onder Security, Access and data control, API controls, Manage Third-Party App Access. Je ziet per app de naam, het type, het ID, of de uitgever is geverifieerd, en de kolom Access met de stand Trusted, Limited of Blocked. Per gebruiker kijk je in Directory, Users, de gebruiker, Security, Connected applications: daar staat per app welk toegangsniveau is gegeven en op welke datum.

2. Weeg de scopes, niet de naam. De naam is het zwakste signaal dat je hebt. Microsoft gebruikt als voorbeeld een toestemmingsscherm van "Google APIs Explorer" dat rechten vraagt aan Google zelf, wat nergens op klopt en toch geloofwaardig oogt. Kijk dus naar wat er precies gevraagd wordt.

Bij Google is dat onderscheid formeel vastgelegd. De scope https://mail.google.com/ geldt als restricted en geeft toegang tot alle mail, inclusief definitief verwijderen, terwijl drive.file niet-gevoelig is omdat hij alleen bij de bestanden komt die de app zelf aanraakte. Vraagt een leverancier om drive terwijl drive.file volstaat, dan is dat een gesprek, geen gegeven.

Twee filters versnellen het wegen enorm. Heb je Defender for Cloud Apps, dan kun je op de pagina OAuth apps filteren op Permission level high severity in combinatie met Community use not common en zo de brede rechten met een kleine gebruikersbasis bovenaan krijgen. Heb je die licentie niet, dan doe je hetzelfde in je CSV: sorteer op de kolom met permissies en begin bij alles waar ReadWrite, .All of mail.google.com in staat.

3. Meet of de app nog leeft, vóór je hem aanraakt. Dit is de stap die de meeste handleidingen overslaan, en precies de stap die maandagochtend bepaalt. In het Entra-beheercentrum ga je naar Entra ID, Monitoring & health, Usage & insights. Het rapport Service principal sign-in activity geeft per service principal de laatste activiteitsdatum, en of de app werd gebruikt als client of als resource, in een app-only of gedelegeerde context. Het rapport Microsoft Entra application activity toont de aanmeldpogingen per app over een periode die je zelf kiest.

Behandel "geen activiteit" als een hypothese, niet als een oordeel. Het rapport staat nog in preview en is niet volledig betrouwbaar; in de tenant van een praktijkbeheerder hadden 578 van de 668 service principals activiteit in het afgelopen jaar en 90 langer niet, waarbij een deel van de activiteitsrecords niet aan een bestaande service principal te koppelen was. Er is nog een reden om voorzichtig te zijn: de activiteitsgrafiek per applicatie rekent met interactieve gebruikersaanmeldingen. Een achtergronddienst die met een certificaat of clientsleutel inlogt, lijkt daar dus dood terwijl hij elke nacht draait. Voor die apps kijk je in hetzelfde menu naar Application credential activity, dat per certificaat of sleutel de laatst gebruikte datum geeft.

In Google Workspace doe je dit via Reporting, Audit and investigation, OAuth log events. Daar zoek je op de gebruiker, de applicatienaam of het attribuut Scope, en zie je de gebeurtenissen waarmee toegang is toegekend of ingetrokken. Let op de vertraging: de lijst met gebruikte apps wordt pas 48 uur na het geven of intrekken van een token bijgewerkt. Voor een verse toestemming van vandaag is het logboek dus je bron, niet de lijst.

4. Trek smal in, en per gebruiker vóór tenantbreed. In Entra ID gaat het intrekken van een tenantbrede toestemming via de app, Permissions, tabblad Admin consent, het menu met de drie puntjes achter de regel, en dan Revoke permission. Voor het tabblad User consent bestaat die knop niet: toestemmingen die gebruikers zelf gaven kun je niet via de portal intrekken, alleen via Microsoft Graph. Het object-ID van de app vind je op het Overview-tabblad.

Connect-MgGraph -Scopes "Application.ReadWrite.All","DelegatedPermissionGrant.ReadWrite.All"

$sp = Get-MgServicePrincipal -ServicePrincipalId "<object-id-van-de-app>"
$grants = Get-MgServicePrincipalOauth2PermissionGrant -ServicePrincipalId $sp.Id -All

$grants | Where-Object { $_.ConsentType -ne "AllPrincipals" } | ForEach-Object {   # alleen gebruikers-grants
    Remove-MgOauth2PermissionGrant -OAuth2PermissionGrantId $_.Id
}

Wil je het bij één persoon houden, dan kan dat volledig in de portal: Entra ID, Users, de gebruiker, Applications, de app, en dan Remove op de toewijzing. Dat is de ingang die je gebruikt zodra je vermoedt dat één medewerker een frauduleuze app goedkeurde, bijvoorbeeld na een telefoontje zoals in de campagne waarin ShinyHunters medewerkers een nep-versie van de Salesforce Data Loader laat koppelen.

Belangrijk: intrekken stopt de al afgegeven tokens niet. Die blijven geldig tot ze verlopen. Bij een app die je echt verdenkt, zet je daarom ook het inloggen van de app uit (op het Properties-tabblad van de enterprise-applicatie, Enabled for users to sign-in op No) en trek je de sessies van de betrokken gebruikers in. Alleen de toestemming weghalen is bij een verdachte app te weinig.

In Google Workspace trek je per gebruiker in via Directory, Users, de gebruiker, Security, Connected applications, en dan het verwijderpictogram achter de app. Tenantbreed zet je de app op Blocked via API controls, Manage Third-Party App Access, Change access. De zware variant is een dienst zelf op Restricted zetten: dan stoppen eerder geïnstalleerde apps die je niet hebt vertrouwd, en worden hun tokens ingetrokken. Dat is een effectieve maar botte hamer. Markeer eerst je blijvers als Trusted, dan pas de dienst op Restricted.

5. Blokkeer de herconsent, anders staat het er volgende maand weer. Dit is het deel dat opruimacties zinloos maakt als je het overslaat. Een ingetrokken toestemming houdt de gebruiker niet tegen om dezelfde app morgen opnieuw goed te keuren. In Entra ID zet je dat vast onder Entra ID, Enterprise apps, Consent and permissions, User consent settings. De middenstand daar, "Allow user consent for apps from verified publishers, for selected permissions", is voor de meeste bedrijven de juiste: gebruikers mogen nog wel iets goedkeuren, maar alleen bij apps van een geverifieerde uitgever en alleen voor permissies die jij als laag-impact hebt geclassificeerd onder Permission classifications. De minimale set voor gewoon inloggen bestaat uit openid, profile, email en offline_access; daar hoort je laag-impactlijst mee te beginnen.

Zet meteen de goedkeuringsaanvraag aan (de admin consent workflow), zodat een medewerker die een app nodig heeft een verzoek kan indienen in plaats van vast te lopen. Zonder die route gaan mensen het buiten je tenant om regelen, en ben je zichtbaarheid kwijt in plaats van rijker.

Twee dingen om niet door elkaar te halen: een wijziging van de consent-instelling geldt alleen voor toekomstige toestemmingen, bestaande grants blijven ongewijzigd. Stap 4 en stap 5 vervangen elkaar dus niet, je hebt ze allebei nodig.

In Google Workspace zit dezelfde valstrik. Toegang voor een app weghalen verhindert niet dat de gebruiker hem later opnieuw gebruikt, en bij de volgende keer inloggen wordt de toegang hersteld. Je zet daarom in API controls, de kaart Settings, bij Unconfigured third-party apps de stand op "Don't allow users to access any third-party apps", of op de variant die alleen inloggen met een Google-account toestaat. Alles wat je wél wil, markeer je expliciet als Trusted.

6. Houd de terugrolstap klaar, niet in je hoofd. Voordat je een golf intrekt, weet je hoe je hem terugdraait. In Entra ID kan dat maar op één manier: terugzetten van ingetrokken permissies gaat alleen via Microsoft Graph PowerShell, niet in het beheercentrum. Microsoft publiceert daarvoor twee scripts die je auditlog uitlezen op de gebeurtenissen "Remove delegated permission grant" en "Remove app role assignment from service principal", en de gevonden grants opnieuw aanmaken. Draai ze eerst met $ForceGrantUpdate = $false om te zien wat ze vinden, en zet hem pas daarna op $true.

Twee details bepalen je planning. Het zoekvenster in die scripts staat standaard op de laatste zeven dagen, dus een storing die pas na drie weken wordt gemeld valt buiten je makkelijke herstelpad. En de snelle route via de knop Grant admin consent op de Permissions-pagina zet de standaardset terug die de ontwikkelaar in de app definieerde, waarbij eerder toegekende permissies die daar niet in zitten juist verdwijnen. Dat is een bot herstel, geen exacte. Je eigen Permissions.csv uit stap 1 is daarom je echte terugrolpunt.

In Google is terugrollen eenvoudiger: zet de app weer op Trusted en laat de gebruiker opnieuw inloggen, dan komt de toegang terug. Dat gemak is precies de reden dat je de blokkade uit stap 5 nodig hebt.

7. Zet de hercontrole in de agenda, niet in je hoofd. Voor organisaties met veel geregistreerde apps en veel gebruikers is het wekelijks nalopen van de consent-grants de aanbevolen praktijk. Voor een bedrijf van dertig man is dat overdreven op de lijst en te zeldzaam op het signaal. Een werkbare cadans: één keer per maand de volledige lijst opnieuw exporteren en vergelijken met vorige maand, en wekelijks alleen naar de nieuwe toestemmingen kijken.

Waar je die nieuwe toestemmingen vindt: in het Microsoft Defender-portaal zoek je in de auditlog op de activiteit Consent to application en controleer je bij elke treffer of IsAdminConsent op True staat. Reken op vertraging, want het duurt 30 minuten tot 24 uur voordat zo'n regel in de zoekresultaten opduikt. In Google gebruik je OAuth log events, met een rapportageregel op de autorisatie-gebeurtenissen (op het attribuut Scope kun je geen regel bouwen, dus filter je op de app of de gebruiker). Heb je Defender for Cloud Apps, dan kun je een beleid maken dat afgaat zodra een app met hoge permissies door meer dan een afgesproken aantal gebruikers wordt goedgekeurd.

Valkuilen

De schade zit zelden in een verkeerde klik. Hij zit in vijf aannames die logisch klinken.

• Alles in één keer intrekken, en het liefst op vrijdag. Trek in golven in, vijf tot tien apps per keer, met een week tussenruimte en een aangekondigd moment. Zo weet je bij een klacht welke golf hem veroorzaakte, en heb je nog tijd binnen het herstelvenster van zeven dagen.
• Denken dat intrekken de toegang meteen stopt. De al afgegeven tokens blijven geldig tot ze verlopen. Bij een verdachte app hoort daarom drie handelingen bij elkaar: de toestemming intrekken, het inloggen van de app uitzetten, en de sessies van de betrokken gebruikers intrekken. Loop daarna hun postbusregels na, want doorstuurregels blijven staan als de app die aanmaakte al weg is.
• De consent-instelling wijzigen en denken dat je klaar bent. Die instelling raakt alleen nieuwe toestemmingen. Alles wat er al staat, blijft staan tot je het intrekt.
• Alleen naar de tenantbrede lijst kijken. Consent phishing landt bij één medewerker, en juist die grants zijn in de portal niet in te trekken. Zonder de PowerShell-route of de gebruikerspagina mis je de categorie waar het misgaat.
• De Google-vertraging van 48 uur negeren. De lijst met gebruikte apps loopt achter op de werkelijkheid. Voor een toestemming van vandaag kijk je in OAuth log events, niet in het overzicht.
• Geen eigenaar per koppeling. Zonder naam achter een app is elke beslissing een gok, en gokken kost je op maandag een storing of laat een aanvaller staan. Twee kolommen in een spreadsheet zijn genoeg: wie hem gebruikt, en wat er stopt als hij weg is.

Intrekken, blokkeren of laten staan

De afweging draait om drie dingen: heeft de app een eigenaar, leest hij inhoud of alleen je identiteit, en wordt hij nog gebruikt. Dat geeft vier uitkomsten, en drie ervan zijn geen "intrekken".

Onbekende app met leesrechten op mail, bestanden of de directory. Intrekken, inloggen uitzetten, sessies intrekken, postbusregels controleren. Hier hoort geen wachttijd bij; dit is het scenario waarvoor je de lijst opende.

Bekende leverancier met een brede scope, aantoonbaar in gebruik. Laten staan. Zet de eigenaar vast op dezelfde plek waar je je goedgekeurde tools en de gebruiksregels eromheen vastlegt, verplaats de toestemming van losse gebruikers naar één tenantbrede admin consent zodat je hem op één plek beheert, en vraag de leverancier om de smalste scope die werkt. Dat gesprek levert vaker resultaat dan je denkt.

Bekende app zonder activiteit in negentig dagen. Intrekken, in golven, met het terugrolpunt klaar. Kun je de activiteit niet meten omdat de app met een certificaat inlogt, controleer dan eerst Application credential activity.

App met alleen inlog-scopes. Laten staan. Dit is de ruis in je lijst, niet je risico, en elke minuut die je hier besteedt gaat af van de eerste categorie.

Kant-en-klaar of maatwerk? Het auditwerk is volledig kant-en-klaar. De schermen zitten in de licentie die je al hebt, het exportscript is gratis, en de consent-instelling is één keer klikken. Voor één tenant met een paar tientallen apps is dat genoeg, en een externe tool erbij kopen is verspilling. Het maatwerk zit niet in het auditen maar in het kijken: de terugkerende export uit beide omgevingen, het verschil met vorige maand, en een signaal dat bij iemand aankomt. Dat is dezelfde les als bij de vijf beveiligingslagen die je zonder eigen securityafdeling zelf kunt nalopen: de maatregel treffen is het makkelijke deel, hem in stand houden het echte werk.

Waar de twee omgevingen verschillen

Een uitgewerkt voorbeeld

Een ingenieursbureau met 42 medewerkers op Microsoft 365 Business Premium. De IT-verantwoordelijke is de operationeel manager, met twee dagen per week voor alles wat met techniek te maken heeft.

Week 1, dinsdagochtend. Het exportscript levert 96 regels over 31 apps. Veertien apps blijken alleen openid, profile, email en User.Read te vragen: die gaan meteen naar de "laten staan"-stapel. Negen apps hebben AllPrincipals in de kolom ConsentType, allemaal met een bekende naam en een leverancier op de factuur. Dan de rest: drie apps met Mail.Read en offline_access, elk goedgekeurd door één medewerker, en één regel die eruit springt. Een app zonder geverifieerde uitgever, met Files.ReadWrite.All en Mail.Read, goedgekeurd in maart door iemand van de administratie. Niemand kent hem.

Die ene wordt niet in een golf meegenomen. Nog diezelfde ochtend: toestemming ingetrokken via de gebruikerspagina, inloggen van de app uitgezet, de sessies van de medewerker ingetrokken, en haar postbusregels nagelopen. Er stond geen doorstuurregel. Dat was geluk, niet beleid.

Week 1, middag. Het rapport Service principal sign-in activity wijst elf apps aan zonder activiteit in het afgelopen jaar. Voor negen daarvan is een eigenaar te vinden die bevestigt dat de app niet meer gebruikt wordt. Twee blijven onduidelijk.

Week 2. Golf één: vijf intrekkingen, een dag eerder aangekondigd in het Teams-kanaal van kantoor. Niets valt om. Week 3, golf twee: de resterende zes. Op donderdag blijkt de mailarchivering niet meer te draaien. Die app stond in de dode lijst omdat hij met een clientsleutel inlogt en dus geen interactieve aanmeldingen produceert. In Application credential activity was zijn laatste gebruik twee dagen oud geweest, als iemand daar had gekeken. Het herstelscript vindt de verwijderde grant terug in de auditlog van diezelfde week en zet hem terug, binnen twintig minuten.

Week 3, vrijdag. De consent-instelling gaat naar "Allow user consent for apps from verified publishers, for selected permissions", met vier permissies als laag-impact geclassificeerd. De goedkeuringsaanvraag staat aan met twee beoordelaars. In de agenda staat een maandelijkse herhaling van een half uur, met het exportscript en de vorige CSV ernaast.

Totaal: ongeveer zes uur werk, verspreid over drie weken, één storing van twintig minuten, en 31 apps terug naar 16 waarvan iedereen weet waarom ze er staan. Het duurste onderdeel was de vergadering waarin werd besloten dat de operationeel manager de eigenaar van die lijst is. Zonder die afspraak was dit een eenmalige opruimactie geweest en had de lijst binnen een jaar weer op 31 gestaan.

De lijst is niet het probleem, het eigenaarschap is het

Deze klus voelt als beheerwerk en is dat maar half. Wat je aan het eind van drie weken hebt opgeleverd is geen kortere lijst, maar een regel: elke app die toegang heeft tot je mail en je bestanden, heeft een naam achter zich die zegt waarom.

Die regel is wat de aanval duur maakt. Een frauduleuze toestemming is niet moeilijk te geven en niet moeilijk te verbergen; wat een aanvaller nekt is een omgeving waarin een onbekende app binnen vier weken opvalt omdat iemand de vorige stand nog heeft. De knop Revoke permission werkt in tien seconden. De gewoonte om te kijken is het enige dat langer meegaat.