Beveiligingswijzigingen voor Salesforce Connected Apps: een gereedheidsgids

Salesforce verschuift de toegang van Connected Apps van "standaard open" naar "standaard goedgekeurd". Niet-geïnstalleerde Connected Apps worden nu voor de meeste gebruikers geblokkeerd, OAuth 2.0 Device Flow wordt uitgefaseerd en Salesforce stuurt iedereen richting External Client Apps als vervanging op lange termijn. Als je org nog niet heeft gecontroleerd wat er echt toegang heeft, zal er ergens een integratie breken voordat je begrijpt waarom.

Wat verandert er precies bij Connected Apps?

Salesforce blokkeert niet-geïnstalleerde Connected Apps nu standaard. Dat betekent dat elke app die een gebruiker zelf heeft geautoriseerd, zonder dat een admin hem formeel in de org heeft geïnstalleerd, zijn toegang verliest tenzij iemand een specifieke bypass-permissie toekent. Apps die nog op OAuth 2.0 Device Flow draaien, verliezen hun toegang helemaal, ook als ze eerder geautoriseerd waren. Op langere termijn stopt Salesforce met de klassieke Connected App als primair integratieobject, ten gunste van External Client Apps. Die scheiden de appdefinitie van het beleid en geven admins fijnmaziger controle over scopes, IP-bereiken en sessiegedrag.

Waarom scherpt Salesforce dit juist nu aan?

Kort gezegd: OAuth-autorisatie werd een geliefd doelwit. Aanvallers die zich voordeden als IT-support haalden medewerkers over om legitiem ogende connected apps goed te keuren en gebruikten die toegang vervolgens om wekenlang ongemerkt data weg te halen. Dat is een social engineering-probleem en geen kwetsbaarheid in het platform, maar Salesforce reageert architectonisch: de standaardhouding wordt "niets maakt verbinding tot een admin het toestaat".

Die verschuiving is redelijk. Ze betekent ook dat org-hygiëne die vroeger optioneel was, weten welke apps precies API-toegang hebben en waarom, nu het verschil maakt tussen een rustige dinsdag en een onverwacht incidentgesprek.

Waar breken integraties in de praktijk?

Uit onze ervaring met het begeleiden van Salesforce-orgs door platformwijzigingen blijkt dat de fouten zelden opduiken waar teams ze verwachten. Let op:

• Middleware- en iPaaS-connectoren die jaren geleden zijn opgezet door iemand die inmiddels weg is, zonder gedocumenteerde eigenaar.
• Data Loader-jobs en geplande ETL-scripts die voor onbeheerde runs nog OAuth Device Flow gebruiken.
• Rapportage- of BI-tools die door een individuele gebruiker zijn geautoriseerd in plaats van voor de hele org geïnstalleerd.
• Partner- of ISV-apps die nooit formeel zijn geïnstalleerd en alleen tijdens een pilot eenmalig zijn geautoriseerd.

Elk van deze gevallen kan maandenlang onopgemerkt blijven tot de beperking ingaat en de sync-job gewoon stopt, vaak zonder duidelijke foutmelding die naar de oorzaak wijst.

Hoe controleer je je org voordat de beperkingen ingaan?

Daar is geen nieuwe tooling voor nodig, alleen een bewuste ronde door Setup:

• Open Setup > Connected Apps OAuth Usage en maak een lijst van elke app die nu geautoriseerd is, niet alleen de apps die je hebt geïnstalleerd.
• Markeer alles met een "Install"-actie: dat is je lijst met niet-geïnstalleerde apps die risico lopen.
• Controleer de datums van laatste gebruik. Apps zonder recente activiteit zijn kandidaten om in te trekken, niet om "voor de zekerheid" te bewaren.
• Bevestig het API Access Control-beleid van je org en wie de permissie "Approve Uninstalled Connected Apps" heeft.
• Noteer voor alles wat je behoudt wie de eigenaar is en waarom. Dat overzicht bespaart je tijd bij de volgende platformwijziging, niet alleen bij deze.

Wat moet er veranderen in hoe je integraties voortaan beheert?

Zie dit als aanleiding om integratiegovernance te formaliseren, niet als eenmalige opruimactie. Nieuwe integraties horen vanaf dag één bewust geïnstalleerd en afgebakend te worden, in plaats van ad hoc geautoriseerd door degene die ze opzette. Plan je nieuwe externe koppelingen, bouw ze dan vanaf het begin als External Client Apps. Dat voorkomt later een tweede migratie.

Dit is precies het soort werk dat we samen met interne Salesforce-teams doen: bestaande integraties in kaart brengen, bepalen wat blijft, verdwijnt of opnieuw wordt gebouwd, en het resultaat opnemen in een ontwikkelproces dat toegangsbeheer als onderdeel van de release behandelt, niet als bijzaak.

Loop je liever samen met iemand door de Connected App-inventaris van je org voordat de volgende platformupdate komt, neem dan contact op en we helpen je de checklist om te zetten in iets herhaalbaars.

FAQ

Breekt dit mijn bestaande Salesforce-integraties?

Alleen als ze niet geïnstalleerd zijn of nog OAuth 2.0 Device Flow gebruiken. Geïnstalleerde apps en moderne authenticatieflows blijven zonder aanpassingen werken.

Wat is het verschil tussen een Connected App en een External Client App?

External Client Apps scheiden de identiteit van de app van het toegangsbeleid en geven admins gedetailleerdere controle over scopes en sessies. Salesforce positioneert ze als vervanging op lange termijn voor klassieke Connected Apps.

Wie moet de permissie "Approve Uninstalled Connected Apps" krijgen?

Houd die groep klein, admins die nieuwe apps testen en developers die integraties onderhouden, want het is een alles-of-niets-bypass en geen toekenning per app.

Hoe vaak moeten we de toegang van Connected Apps controleren?

Minimaal elk kwartaal en direct na elke beveiligingsrelease van Salesforce, want een uitdijende autorisatiescope ontstaat geleidelijk en wordt makkelijk gemist.