Hoe OAuth-toestemming MFA omzeilt

In februari 2026 ging een phishing-as-a-service (PhaaS)-platform genaamd EvilTokens live. Binnen vijf weken had het meer dan 340 Microsoft 365-organisaties in vijf landen in gevaar gebracht.

De doelwitten van het platform ontvingen een bericht waarin hen werd gevraagd een korte code in te voeren op microsoft.com/devicelogin en hun normale MFA-uitdaging te voltooien, en liepen vervolgens weg in de overtuiging dat ze een routinematige aanmelding hadden geverifieerd. Ze hadden de operator feitelijk een geldig vernieuwingstoken gegeven dat betrekking had op hun mailbox, schijf, agenda en contacten, met de levensduur van een tenantbeleid in plaats van een sessie.

De operator had nooit een wachtwoord nodig, activeerde nooit een MFA-prompt en produceerde nooit een aanmeldingsgebeurtenis die op een inbraak leek. De aanval slaagde omdat het OAuth-toestemmingsscherm een ​​instinctieve klik is geworden en de bedieningselementen die zijn gebouwd om phishing van inloggegevens te stoppen niet naar de toestemmingslaag kijken.

Beveiligingsonderzoekers noemen de resulterende voorwaarde toestemmingsphishing of OAuth-subsidiemisbruik. De phishing-klik die er de afgelopen tien jaar toe deed, was het overhandigen van een wachtwoord. De phishing-klik die er toe doet, levert nu een vernieuwingstoken op, en deze bevindt zich structureel onder de identiteitscontroles die de meeste organisaties nog steeds als de perimeter beschouwen.

Waarom MFA een OAuth-toekenning niet kan zien

Bij een credential-phish wordt een gebruikersnaam en wachtwoord overhandigd die ergens opnieuw moeten worden afgespeeld, en de meeste identiteitsstapels vereisen nu een tweede factor bij het opnieuw afspelen. Zelfs AiTM-kits (adversary-in-the-middle) produceren een sessiecookie die is gekoppeld aan een aanmeldingsgebeurtenis en die de SIEM correleert met geografie, apparaat- en reispatronen.

Een OAuth-toekenning levert geen opnieuw afgespeelde inloggegevens op. De gebruiker authenticeert zich bij de legitieme identiteitsprovider, voltooit de MFA-uitdaging op het legitieme domein en klikt op Accepteren. Het teken waarmee de aanvaller wegloopt, is dat het systeem werkt zoals ontworpen. Het is ondertekend door de identiteitsprovider, beperkt tot alles waarmee de gebruiker heeft ingestemd, en kan worden vernieuwd. MFA kan het niet blokkeren omdat MFA al heeft plaatsgevonden.

Het andere probleem is dat vernieuwingstokens vervolgens het venster verlengen. De tokens die EvilTokens uitgeven, overleefden wachtwoordresets en bleven weken of maanden geldig, afhankelijk van de tenantconfiguratie. Het roteren van het wachtwoord heeft de toekenning niet ongeldig gemaakt. Alleen een expliciete intrekking, of een beleid voor voorwaardelijke toegang dat hernieuwde toestemming eiste, kon het afsluiten.

Hoe toestemming werd genormaliseerd

Deze aanvalsvector bestaat al sinds OAuth standaard werd. Wat er is veranderd, is de omgeving waarin het opereert. Gebruikers zijn getraind om door toestemmingsschermen te klikken met de snelheid waarmee ze ooit door cookiebanners klikten. Elke AI-agent installeert Surface One. Elke productiviteitsintegratie brengt er één met zich mee. Elke browserextensie die een SaaS-account raakt, komt er één tegen. De hoeveelheid legitieme toestemming die een kenniswerker in een maand ziet, overtreft alles wat bestond toen de oorspronkelijke OAuth-bedreigingsmodellen werden geschreven.

De scopes zelf gebruiken taal die niet duidelijk in verband staat met risico’s. Een reikwijdte genaamd “Lees uw e-mail” klinkt beperkt, maar in de praktijk omvat het elk bericht, bijlage en gedeelde discussie waartoe de gebruiker toegang heeft. Een bereik genaamd “Toegang tot bestanden wanneer u niet aanwezig bent” betekent een token met een lange levensduur dat wordt uitgegeven zonder dat de gebruiker voor een scherm staat om het in te trekken. De kloof tussen toestemmingstaal en operationeel bereik is precies waar aanvallers opereren.

Toxische combinaties worden weergegeven onder de eigenaar van de applicatie

Eén enkele OAuth-toestemming geeft een aanvaller toegang tot één applicatie. Het diepere risico ontstaat wanneer deze steunpunten een brug slaan.

Een financiële gebruiker verleent een AI-vergaderingssamenvatting toegang tot zijn/haar agenda en mailbox. Dezelfde gebruiker verleent later een productiviteitsassistent toegang tot de gedeelde Drive van het bedrijf. Een derde subsidie ​​koppelt een CRM-verrijkingstool aan de klantendatabase. Ze werden allemaal één voor één goedgekeurd. Geen enkele applicatie-eigenaar heeft de combinatie goedgekeurd. Het risicooppervlak bestaat nu uit drie reikwijdten die elkaar doorkruisen door één menselijke identiteit, waarbij het compromis van de samenvatter van de vergadering via dezelfde persoon contractconcepten en klantendossiers kan bereiken.

Dit wordt een toxische combinatie genoemd. Het bestaat uit een verdeling van de rechten over applicaties, overbrugd door een OAuth-subsidie, een integratie of een AI-agent, die geen enkele applicatie-eigenaar ooit heeft geautoriseerd als zijn eigen risicooppervlak. Het kan niet worden gezien door het auditlogboek van een bepaalde toepassing, omdat de brug buiten alle toepassingen bestaat.

De MCP-installatie, de OAuth-toestemmingsklik en de toekenning van de browserextensie: elk is een brug die wordt uitgegeven met de snelheid van een enkele klik. Model Context Protocol (MCP)-servers zijn in opkomst als het volgende aanvalsoppervlak in OAuth-stijl, waardoor agenten een bereik kunnen verwerven via hetzelfde trust-once-mechanisme dat toestemmingsschermen al gebruiken.

Het Salesloft-Drift-incident uit 2025 liet zien hoe dit er op grote schaal uitziet. Een gecompromitteerde downstream-connector verspreidde zich over meer dan 700 Salesforce-tenants via OAuth-tokens die de klanten legitiem hadden goedgekeurd. Elke klant heeft de integratie geautoriseerd. Niemand gaf toestemming voor de cascade.

Wat te controleren

Om deze kloof te dichten, moet OAuth-toestemming op dezelfde manier worden behandeld als het beveiligingsprogramma authenticatie al behandelt. Een kleine reeks vragen laat zien waar de echte kloof ligt.

Gebied om te beoordelen	Hoe het er in de praktijk uitziet
OAuth-applicatie-inventaris	Elke app van derden die vernieuwingstokens in de tenant bevat, wordt continu vernieuwd in plaats van tijdens de audit.
Verleen leeftijd en geef opnieuw toestemming	Tokens die meer dan 30 dagen geleden zijn uitgegeven zonder hernieuwde toestemming, zijn in de wachtrij verschenen.
Identiteiten tussen verschillende applicaties	Identiteiten met subsidies voor drie of meer SaaS-applicaties, gemarkeerd voor beoordeling.
Agent- en integratiebruggen	AI-agents en integraties die twee systemen overbruggen die geen enkele applicatie-eigenaar samen heeft bestraft.
Voorwaardelijke toegang op basis van toestemming	Beleid dat opnieuw wordt geactiveerd bij toestemmingsgebeurtenissen, niet alleen bij aanmeldingsgebeurtenissen.
Intrekking op tokenniveau	Een draaiboek dat één OAuth-token intrekt in plaats van de gebruiker op te schorten.

Procedurele discipline is slechts tot nu toe schaalbaar. De bruggen leven in een grafiek die geen enkele applicatie bezit, en ze worden gemaakt met de snelheid van een MCP-installatie of een OAuth-toestemmingsklik. Om die grafiek continu te zien, is een platform nodig dat is gebouwd om de runtime-laag te bekijken waar de bruggen zich daadwerkelijk vormen.

Waar AI-beveiligingsplatforms passen

Een nieuwe klasse platforms verwerkt veel hiervan automatisch. Ze brengen elke OAuth-subsidie, AI-agent en integratie van derden in de identiteitsgrafiek in kaart op het moment dat deze wordt uitgegeven, in plaats van te wachten op de volgende audit, en brengen vervolgens de bruggen, ongebruikte tokens en beleidsafwijkingen naar boven als een continue operationele wachtrij.

Een toonaangevend voorbeeld is Reco. Het brengt de beveiliging van AI-agenten, identiteitsbeheer en detectie van bedreigingen in één controlevlak. De Identity Knowledge Graph verbindt menselijke en niet-menselijke identiteiten met de applicaties, OAuth-subsidies en integraties waartoe ze toegang hebben in het hele SaaS-domein.

Het platform ontdekt voortdurend AI-agents en OAuth-subsidies zodra ze verschijnen, wijst elk bereik terug aan de identiteit die het heeft goedgekeurd, controleert het gedrag op beleidsafwijkingen en trekt de toegang in op tokenniveau in plaats van op het gebruikersaccount. Dat geeft beveiligingsteams inzicht in de runtimelaag waar deze vertrouwensrelaties feitelijk ontstaan.

Toestemmingsphishing zal waarschijnlijk niet veel langer aan de marge blijven. Phishing-bestendige authenticatie heeft jaren van investeringen en onderzoek ondergaan, terwijl de toestemmingslaag nog steeds grotendeels op basis van vertrouwen functioneert. Het dichten van deze kloof betekent dat OAuth-subsidies en AI-agentverbindingen worden behandeld met dezelfde zichtbaarheids-, monitoring- en intrekkingsdiscipline die al wordt toegepast op de authenticatie zelf.

Lees meer over het AI-beveiligingsplatform van Reco.