Salesforce OAuth-flows: het juiste authenticatieontwerp kiezen

Hoe kies je de juiste Salesforce OAuth-flow? Stuur een mens door de Authorization Code Flow met PKCE, koppel een server-to-server-job aan de JWT Bearer Flow (of de Client Credentials Flow) en val nooit terug op een gebruikersnaam, wachtwoord en security token omdat dat sneller is opgezet. Die laatste shortcut loopt nu af. Salesforce kondigde de uitfasering van de OAuth 2.0 username-password flow voor connected apps aan in Spring '26, zette die aanvankelijk op de lijst voor handhaving bij de uitrol van Winter '27 en legde hem daarna vast op één vaste datum: 20 februari 2027. Die datum is voor elke org op het platform gelijk en niet gekoppeld aan het upgradeweekend van je instance, dus er is geen gespreid venster om achter te schuilen. Orgs die in Summer '23 of later zijn aangemaakt, blokkeren de flow nu al volledig. Kies je het verkeerde ontwerp, dan sluit je legitieme integraties buiten je org of laat je een langlevende credential achter waar een aanvaller hem kan vinden.

Hoe kies je de juiste Salesforce OAuth-flow?

Elke OAuth-beslissing begint met één vraag: autoriseert een persoon deze verbinding, of een machine?

Is er een persoon aanwezig, stuur die dan door de Authorization Code Flow met PKCE (Proof Key for Code Exchange), die Salesforce documenteert als de OAuth 2.0 web server flow met de PKCE-extensie en nu noemt als aanbevolen vervanging voor logins op gebruikersbasis. PKCE koppelt de autorisatiecode aan de client die hem heeft aangevraagd, dus een onderschepte code is nutteloos voor een aanvaller. Kies dit boven de OAuth 2.0 Device Flow, die Salesforce aan het terugdraaien is: het haalde de ondersteuning voor Device Flow op 2 september 2025 weg uit de automatisch geïnstalleerde connected app van Data Loader, en Data Loader 64.1.0 liet zowel de Device Flow als de User-Agent Flow vallen. Beide waren makkelijk te misbruiken omdat ze met weinig meer dan een client-ID konden worden gestart, een geliefd doelwit voor social engineering.

Is er geen persoon aanwezig, zoals bij een nachtelijke ETL-job of middleware die records naar Salesforce stuurt, kies dan een server-to-server-flow: de JWT Bearer Flow of de Client Credentials Flow. Met beide authenticeert een backendservice zich zonder browser of sessie om naar door te sturen. Dezelfde keuze ligt onder de meeste integratiearchitectuurpatronen die echt schalen, want het authenticatieontwerp moet elke retry, time-out en credentialrotatie overleven die deze patronen met zich meebrengen.

JWT Bearer of Client Credentials: welke server-to-server-flow?

Beide flows authenticeren de app zelf zonder gebruiker erbij, maar ze maken verschillende afwegingen in de omgang met secrets.

• JWT Bearer Flow authenticeert met een digitaal ondertekend certificaat in plaats van een gedeeld secret. Er staat geen client secret in een configuratiebestand dat kan lekken, de ondertekende assertion is kortlevend en een sleutel roteren betekent een certificaat vervangen in plaats van code opnieuw uitrollen. Kies dit als je de sterkste beveiliging wilt en een private key kunt beheren.
• Client Credentials Flow wisselt een consumer key en consumer secret in voor een access token en draait als een aangewezen integratiegebruiker. Dit is eenvoudiger op te zetten, maar het secret is een bearer credential: iedereen die het onderschept, kan zich voordoen als de integratie, dus het moet met echte discipline worden opgeslagen en geroteerd.

Wat je ook kiest, beperk de uitvoerende of integratiegebruiker strikt met een eigen profiel en permission sets, in plaats van voor het gemak brede admintoegang te geven. Een machineaccount dat alleen de objecten kan raken die het nodig heeft, is het verschil tussen een beheersbaar incident en een compromittering van de hele org.

Connected Apps of External Client Apps: wat is er veranderd voor 2026?

Salesforce splitst de klassieke connected app op in twee speciaal ontworpen apptypes, en de tijdlijn dwingt nu tot een keuze. Sinds Spring '26 blokkeert Salesforce het aanmaken van nieuwe connected apps via zowel de UI als de API, met package-installatie als enige uitzondering, en beveelt het external client apps aan. Bestaande connected apps blijven tijdens en na de wijziging werken: er breekt niets in je org in het upgradeweekend. Moet je echt een nieuwe connected app aanmaken, dan kan Salesforce Support dat voorlopig weer inschakelen voor je org, maar Salesforce heeft aangegeven dat die mogelijkheid in een latere release verdwijnt. Het is dus een brug, geen plan voor de lange termijn.

External client apps zijn de nieuwere, aanbevolen route voor elk extern systeem dat via OAuth bij Salesforce authenticeert, inclusief je eigen middleware, ETL-tools en partnerintegraties. Ze zijn bewust strenger: ze ondersteunen alleen de veilige OAuth-flows en sluiten de username-password flow volledig uit. Ook ondersteunen ze de Metadata API volledig en houden ze consumer secrets buiten gepackagede componenten, waardoor ze veel makkelijker te beheren zijn via versiebeheer en CI/CD-pipelines dan een oude connected app.

De praktische conclusie voor een architectuurreview: kies standaard een external client app voor nieuwe integraties en bewaar connected apps voor de Salesforce-eigen gevallen die ze nog nodig hebben, zoals canvas en mobile publishing. Wie uit gewoonte naar een oude connected app grijpt, loopt bij de volgende build tegen een aanmaakbeperking aan.

Waar passen Named Credentials in een veilig integratieontwerp?

Named Credentials lossen een ander probleem op: uitgaande callouts van Salesforce naar externe systemen, aangestuurd door Apex of Flow. In plaats van een endpoint-URL en OAuth-gegevens hard in een klasse te coderen, registreer je één keer een Named Credential en verwijs je ernaar op naam, per gebruiker of voor de hele org, en Salesforce regelt op de achtergrond de tokenuitwisseling en vernieuwing.

Dit is belangrijk voor de security review omdat credentials helemaal uit de code verdwijnen. Of de onderliggende handshake nu JWT Bearer of Client Credentials is, het secret of de sleutel staat buiten je integratiecode, dus roteren gebeurt op één plek in plaats van zoeken door Apex-klassen en Flow-definities. Koppel je Salesforce aan een zwaar bronsysteem zoals een ERP, dan is dit wat de integratiepatronen voor Salesforce en SAP controleerbaar houdt in plaats van een stapel ingebedde wachtwoorden.

Hoe migreer je oude username-password-integraties naar moderne OAuth-flows?

De meeste orgs die we beoordelen, hebben nog minstens één integratie die authenticeert met een gebruikersnaam, wachtwoord en security token, soms uit een script dat niemand zich herinnert te hebben geschreven. De cutoff van 20 februari 2027 is al een keer verschoven, van de handhavingslijst van Winter '27, dus zie de extra tijd als migratietijd en niet als uitstel. Er is geen waarschuwingsbanner in de UI: op de cutoffdatum krijgt een integratie op basis van wachtwoorden gewoon geen access token meer en geeft ze een authenticatiefout. Een gestructureerde migratie ziet er zo uit:

• Inventariseer elke integratiegebruiker en elk profiel met API-toegang om te vinden waar logins met wachtwoorden nog worden gebruikt.
• Classificeer elke integratie als gebruiker aanwezig of server-to-server, en koppel ze aan de Authorization Code Flow met PKCE, de JWT Bearer Flow of de Client Credentials Flow.
• Registreer per integratie een eigen External Client App in plaats van één app te delen over systemen die niets met elkaar te maken hebben.
• Zet uitgaande callouts achter Named Credentials, zodat secrets buiten de codebase staan.
• Roteer het wachtwoord van de oude integratiegebruiker en trek zijn API-toegang in zodra het verkeer volledig is overgezet.

Voer de overstap integratie voor integratie uit en controleer of elke verbinding authenticeert in een sandbox voordat je de credential aanraakt waarvan productie afhangt. Hetzelfde authenticatieontwerp ligt ook onder nieuwere patronen zoals CRM-acties uitvoeren vanuit een agentic hub, waar één machine-identiteit veel acties aanstuurt en een gelekt secret des te schadelijker zou zijn.

Dit is het soort werk dat ons consultingteam regelmatig doet. Draait je org nog integraties op basis van wachtwoorden, dan brengen we het migratiepad in kaart ruim voordat 20 februari 2027 er een brandoefening van maakt. Neem contact op om je situatie te bespreken.

FAQ

Wanneer wordt de Salesforce username-password OAuth-flow uitgefaseerd?

Salesforce verplaatste de uitfasering van de uitrol van Winter '27 naar één vaste datum, 20 februari 2027, die voor elke org tegelijk geldt en niet het upgradeweekend van elke org volgt. Orgs die in Summer '23 of later zijn aangemaakt, blokkeren de flow nu al. Migreer getroffen integraties vóór die tijd naar de web server flow met PKCE, de JWT Bearer Flow of de Client Credentials Flow.

Kan ik in 2026 nog een nieuwe Connected App aanmaken?

Salesforce beperkt het aanmaken van nieuwe connected apps sinds Spring '26 en beveelt external client apps aan. Bestaande connected apps blijven werken, en je kunt via Salesforce Support een uitzondering aanvragen als je er echt een nodig hebt.

Wat is het verschil tussen de JWT Bearer- en Client Credentials-flows?

Beide zijn server-to-server-flows zonder aanwezige gebruiker. JWT Bearer authenticeert met een ondertekend certificaat en heeft geen gedeeld secret dat kan lekken. Client Credentials wisselt een consumer key en secret in en draait als aangewezen integratiegebruiker, wat eenvoudiger is maar steunt op een bearer secret dat je zorgvuldig moet opslaan en roteren.

Moeten nieuwe integraties Connected Apps of External Client Apps gebruiken?

Kies standaard external client apps voor nieuwe externe integraties. Ze ondersteunen alleen de veilige OAuth-flows, werken volledig met de Metadata API voor CI/CD en zijn de route die Salesforce nu aanbeveelt. Bewaar connected apps voor Salesforce-eigen gevallen zoals canvas en mobile publishing.

Vervangen Named Credentials OAuth-flows?

Nee. Named Credentials beheren de authenticatie van uitgaande callouts en kunnen onder de motorkap OAuth-flows zoals JWT Bearer gebruiken. Ze houden secrets buiten Apex en Flow, maar vervangen de flow zelf niet.