16 nov 2025·8 min
OAuth vs SAML voor SSO: wat enterprise-kopers verwachten
OAuth vs SAML voor SSO uitgelegd in eenvoudige bewoordingen, plus wat bedrijven vragen, wat je moet bouwen en hoe je je bestaande login werkend houdt.
OAuth vs SAML voor SSO uitgelegd in eenvoudige bewoordingen, plus wat bedrijven vragen, wat je moet bouwen en hoe je je bestaande login werkend houdt.
SSO wordt urgent op het moment dat een deal verschuift van een "teamtrial" naar een bedrijfsbrede uitrol. Een koper kan je product geweldig vinden, maar security en IT vertragen de inkoop als medewerkers nieuwe wachtwoorden moeten aanmaken, MFA op nog een plek moeten beheren, of accounts kwijtraken wanneer mensen van rol veranderen.
Voor veel bedrijven gaat SSO minder over gemak en meer over controle. Ze willen één plek om inlogregels af te dwingen, snel toegang in te trekken en auditors te kunnen laten zien dat identiteit centraal wordt beheerd. Daarom komt de vraag "OAuth vs SAML for SSO" vaak laat in de salescyclus: het is een snelle manier om te checken of je in hun identity-omgeving past.
SSO later toevoegen kan aannames die je al gebruikt breken. Als je huidige model "één e-mail = één gebruiker" is, introduceert SSO randgevallen zoals gedeelde aliassen, meerdere identity providers of gebruikers die zowel wachtwoordlogin als SSO moeten blijven houden tijdens een migratie. Als accountkoppeling fout gaat, verliezen mensen toegang of — nog erger — krijgen ze toegang tot de verkeerde tenant.
SSO verandert ook onboarding en support. Goed gedaan vermindert het wachtwoordresets en tickets als "wie heeft dit account?". Slecht gedaan stagneren roll-outs, worden admins boos en komen verlengingen op het spel te staan omdat het product "werkte in een trial" maar faalt op dag één van enterprise-deployment.
De beslissing ligt zelden bij één persoon. De koper wil voortgang, security wil risico- en auditchecks, IT-admins hebben duidelijke setupstappen nodig, eindgebruikers willen een soepele login en support behandelt lockouts, migraties en uitzonderingen.
Als je apps bouwt op platforms zoals Koder.ai, helpt het om vroeg op SSO te plannen zodat je identiteit niet helemaal moet herontwerpen nadat klanten al actief zijn.
SSO (single sign-on) betekent dat je klant inlogt in jouw app met hun bedrijfsaccount, niet met een apart wachtwoord dat jij opslaat. Ze melden zich aan met hun werkaccount en toegang wordt geregeld via het bedrijfsbeleid.
Dit zijn de termen die je op enterprise-calls hoort:
Als mensen zeggen "OAuth login" bedoelen ze vaak OpenID Connect (OIDC). OAuth gaat vooral over autorisatie (toestemming om iets te benaderen). OIDC voegt authenticatie toe (wie de gebruiker is), dus het kan voor login worden gebruikt.
SAML is een ouder, XML-gebaseerd SSO-standaard. Enterprises gebruiken het nog veel omdat het bewezen werkt, breed ondersteund wordt door IdP's en vaak in compliance-checklists staat.
SCIM is geen SSO. SCIM is voor provisioning: automatisch gebruikers (en soms groepen) aanmaken, bijwerken en deactiveren. Een veelvoorkomende setup is SAML of OIDC voor inloggen, plus SCIM zodat toegang wordt toegevoegd en verwijderd zonder handmatig adminwerk.
Enterprisekopers beginnen meestal niet met protocoldetails. Ze beginnen met risico en controle: "Kunnen we toegang beheren vanaf onze identity provider, en kunnen we bewijzen wie wat deed?"
De meeste enterprise-teams willen minstens één enterprise-vriendelijke optie, en veel teams willen beide:
Ze vragen ook hoe de setup werkt: metadata of discovery-URL, certificaatrotatie en of IT self-service kan doen zonder afhankelijk te zijn van jouw engineers.
De snelste manier om een enterprise-deal te verliezen is vaag zijn over offboarding. Ze vragen wat er gebeurt als een medewerker vertrekt, van afdeling wisselt of een laptop verliest.
Voorzie vragen zoals:
Een eenvoudig scenario waar ze om geven: een admin zet een gebruiker uit om 09:02 en om 09:03 mag die gebruiker de app niet meer openen, ook niet met een open browsertab. Als je die flow niet duidelijk kunt uitleggen, verwacht extra reviewcycli.
OAuth is oorspronkelijk gemaakt voor gedelegeerde toegang: het laten communiceren van het ene systeem met het API van een ander zonder wachtwoord te delen. Veel teams gebruiken het nog voor dat doel (bijv. integraties die agenda’s lezen). Voor medewerkerlogin gebruiken de meeste producten OpenID Connect (OIDC), dat bovenop OAuth zit en een standaard manier toevoegt om te bewijzen wie de gebruiker is.
Bij OIDC is de gangbare setup de authorization code flow. Je app stuurt de gebruiker naar de IdP van het bedrijf om in te loggen. Na succesvolle login stuurt de IdP een korte authorization code terug naar je app. Je backend ruilt die code in voor tokens.
De token-scheidingen die ertoe doen:
Een praktische manier om over OAuth vs SAML voor SSO te denken: OIDC is ideaal als je een moderne login wilt die bij web, mobiel en API-patronen past. SAML is gebruikelijker wanneer de enterprise de klassieke "sign in to the app" handshake wil en minder geeft om API-toegang.
Wat je opslaat, houd eenvoudig: de stabiele identifier van de gebruiker (subject), hun e-mail (als die wordt meegeleverd) en de tenant-verbinding die ze gebruikten. Sla niet het wachtwoord van de gebruiker op. Vermijd ook het bewaren van langlevende refresh-tokens tenzij je echt offline API-toegang nodig hebt.
Om dit per klanttenant te laten werken, heb je nodig:
openid, email, profile)Goed opgezet landen gebruikers terug in je app, valideer je de tokens en maak je je normale sessie zonder je hele auth-model te herschrijven.
SAML laat een enterprise-IdP je app vertellen: "deze persoon heeft zich al aangemeld, dit zijn hun gegevens." De IdP stuurt een SAML-assertion, een ondertekend bericht met wie de gebruiker is (en soms group- of role-info) plus een korte geldigheidsperiode.
Om dat bericht betrouwbaar te maken, vertrouwt SAML op metadata en certificaten. Metadata is een kleine configuratiepakket dat endpoints en keys beschrijft. Certificaten worden vooral voor signing gebruikt, zodat je app kan controleren dat de assertion van de klant-IdP komt en niet gewijzigd is.
Twee identifiers verschijnen in bijna elke setup:
Als een van beide verkeerd is, faalt de login zelfs als alles verder correct lijkt.
Echte SAML-implementatie is net zo veel operatie als code. Plan voor tenant-level SAML-instellingen, certificaatrotatie zonder downtime, klokverschil (al een paar minuten kan assertions breken) en duidelijke foutmeldingen voor admins (niet alleen "invalid response").
Een veelgebruikt patroon: de klantadmin schakelt SAML per tenant in, jouw app verifieert de handtekening, controleert dat de assertion niet verlopen is en mapt de e-mail (of NameID) naar een bestaande gebruiker of een veilige auto-provision-regel. In de praktijk is dit het hart van de OAuth vs SAML-beslissing: SAML dwingt je vaak om sterkere admin-workflows te bouwen.
Kiezen tussen OIDC en SAML gaat grotendeels over wat je koper al draait. Veel B2B-apps ondersteunen beide in de loop van de tijd, maar je kunt per klant een nette beslissing maken en je auth-systeem voorspelbaar houden.
OIDC is vaak soepeler voor moderne apps. Het past bij browser- en mobiele apps, werkt goed met API’s en is doorgaans makkelijker te debuggen en uit te breiden (scopes, tokenlifetimes, enz.). Als je enterprise-klant al een moderne IdP-setup heeft en hun IT-team vertrouwd is met OIDC, begin dan daarmee.
SAML kan non-negotiable zijn. Veel grote bedrijven hebben bestaande SAML-programma’s en onboardingregels zoals "SAML only." In die gevallen is de beste aanpak rechttoe rechtaan: implementeer SAML één keer op een gecontroleerde manier en houd het geïsoleerd van de rest van je login-systeem.
Vragen om te stellen voordat je je commit:
Een korte besliswijzer:
| Als de klant zegt... | Geef de voorkeur aan | Waarom |
|---|---|---|
| "We gebruiken Entra ID en willen een moderne app-integratie" | OIDC | Beter voor web- en API-flows |
| "Ons beleid is SAML-only voor leveranciers" | SAML | Vereist voor security-onboarding |
| "We hebben beide nodig voor verschillende dochterondernemingen" | Beide | Gebruikelijk in grote organisaties |
| "We hebben aangepaste claims per app nodig" | Beide | Beide ondersteunen attribuutmapping |
Als je beide ondersteunt, houd de rest van je app consistent: één intern gebruikersmodel, één sessiemodel en één set autorisatieregels. De SSO-methode moet beantwoorden "wie is deze gebruiker en bij welke tenant hoort hij/zij" — niet je toegangsmodel opnieuw uitvinden.
Begin met definiëren wat "tenant" betekent in je product. Voor de meeste B2B-apps wordt SSO per organisatie of workspace geconfigureerd, niet per gebruiker. Die keuze bepaalt waar je IdP-instellingen opslaat, wie ze kan wijzigen en hoe gebruikers tussen workspaces bewegen.
Kies daarna een voorspelbaar inloggedrag. E-maildomeinrouting (typ e-mail, en redirect als het domein SSO-enabled is) vermindert verwarring, maar je moet randgevallen zoals contractors en multi-domeinbedrijven afhandelen. Een simpele "Continue with SSO"-knop is makkelijker te begrijpen, maar gebruikers kunnen de verkeerde optie kiezen.
Een veilige bouwvolgorde voor zowel OIDC als SAML:
Testen is geen optie. Gebruik een sandbox-IdP en een staging-tenant met realistische domeinen. Test happy paths en foutgevallen: verlopen certificaat, verkeerde audience, klokverschil, gebruiker verwijderd uit IdP. Behandel SSO-rollout als een feature flag.
Platforms zoals Koder.ai maken dit soort iteratie eenvoudiger door snapshots en rollback te ondersteunen naast per-tenant configuratie, zodat een slechte wijziging niet iedereen tegelijk buitensluit.
SSO is niet alleen een inlogknop. Security-teams vragen naar sessieduur, offboarding en wat je kunt bewijzen als er iets misgaat. Behandel SSO als een kernonderdeel van je auth-systeem (niet als een bolt-on) en je voorkomt de meeste pijnlijke escalaties.
Begin met sessieregels. Kies een idle-timeout en een absolute sessieduur en wees expliciet over wat er gebeurt als iemand zijn laptop sluit en de volgende dag terugkeert. Met OIDC kunnen refresh-tokens sessies langer openhouden dan verwacht, dus stel limieten in (rotatie, max age) als je ze gebruikt. Met SAML kunnen browser-sessies lang leven tenzij je re-auth afdwingt.
Logout is een andere valkuil. "Single logout" is niet universeel. Ondersteun lokale logout betrouwbaar en communiceer dat globale logout over alle apps afhangt van de IdP.
MFA is vergelijkbaar. Enterprises willen vaak dat de IdP MFA afdwingt, dus je app moet een geauthenticeerde gebruiker accepteren zonder opnieuw te vragen. Toch is het nuttig step-up checks te ondersteunen voor risicovolle acties (zoals data-export of wijzigen van billing), omdat niet elke IdP-policy perfect is.
User provisioning is waar toegangslekken ontstaan. JIT-provisioning is handig, maar kan accounts creëren voor iedereen die kan authenticeren. Invite-only is veiliger maar geeft meer adminwerk. Veel teams kiezen een middenweg: JIT is toegestaan, maar beperkt tot toegestane domeinen en (optioneel) group-claims.
Houd SSO-configuratie achter least-privilege rollen. Iemand zou geen super-adminrechten moeten nodig hebben alleen om een certificaat te roteren of een IdP-URL te updaten.
Voor support, log genoeg om een enkele login te traceren zonder geheimen te bewaren:
Dit is het verschil tussen "we kunnen het niet reproduceren" en het oplossen van een enterprise SSO-uitval binnen enkele minuten.
Een mid-market bedrijf bereikt procurement en zegt: "We hebben SSO nodig voordat we kunnen tekenen." Dat is zelden filosofisch. Het is een controle die ze nodig hebben voor onboarding, offboarding en audit.
De twist: je verkoopt aan twee teams. Team A is blij met OIDC omdat ze Okta en moderne apps gebruiken. Team B staat op SAML omdat hun legacy-tools dat nog altijd vereisen. Hier stopt de OAuth vs SAML-discussie met debatteren en wordt het een rollout-plan.
Houd één regel: SSO is een per-tenant loginoptie, geen globale vervanging. Bestaande gebruikers kunnen op de oude manier blijven inloggen totdat de tenantadmin "SSO required" inschakelt.
Bij de eerste SSO-login heb je veilige accountkoppeling nodig. Een nette aanpak is: match op geverifieerde e-mail, bevestig de tenant via domein (of een invite) en koppel dan de IdP-identiteit aan de bestaande gebruiker. Als er geen match is, maak de gebruiker just-in-time aan, maar alleen als de admin dat heeft toegestaan.
Roltoewijzing is waar deals vaak vastlopen. Houd het simpel: een standaardrol voor nieuwe gebruikers en optionele mapping van IdP-groepen of claims naar jouw rollen.
Aan de adminzijde moeten ze vaak configureren:
Om lockouts tijdens de switch te vermijden, houd een break-glass admin-account buiten SSO, voer een testmodus uit voor de eerste logins en handhaaf SSO pas nadat ten minste één werkende admin-sessie is bevestigd.
De meeste SSO-incidenten worden niet door de IdP veroorzaakt. Ze ontstaan omdat je app SSO als een globale schakel behandelt in plaats van per-klant.
Een klassiek falen is het missen van tenantgrenzen. Eén nieuwe IdP-config wordt globaal opgeslagen en plots wordt iedere klant naar de laatst gewijzigde IdP gestuurd. Houd IdP-instellingen aan een tenant gekoppeld en los de tenant altijd op voordat je de SSO-handshake start.
Accountmatching is de volgende grote valkuil. Als je alleen op e-mail vertrouwt, creëer je dubbele gebruikers of sluit je echte gebruikers uit wanneer hun IdP-e-mail verschilt van de e-mail die ze voorheen gebruikten. Definieer je merge-policy vroeg: welke identifiers vertrouw je, hoe ga je om met e-mailwijzigingen en hoe kunnen admins mismatches oplossen zonder engineering?
Teams vertrouwen ook te veel op claims. Valideer wat je terugkrijgt: issuer, audience, signature en of de e-mail geverifieerd is (of gebruik een stabiele subject-identifier in plaats daarvan). Het accepteren van de verkeerde audience of een ongeverifieerde e-mail is een gemakkelijke manier om toegang aan de verkeerde persoon te geven.
Als er iets faalt, veroorzaken vage foutmeldingen lange supportgesprekken. Geef gebruikers een duidelijke boodschap en admins een diagnostische hint (bijv. "Audience mismatch" of "Certificate expired") zonder geheimen bloot te geven.
Tijdgerelateerde issues zijn het waard om van tevoren te testen. Clock skew en certificaatrotatie breken logins op maandagochtend.
Vijf checks die de meeste uitvalsituaties voorkomen:
sub of NameID) en definieer een veilige merge-policySSO is waar kleine aannames grote supporttickets worden. Voordat je een enterprise-klant zegt dat je het ondersteunt, zorg dat de basis in je product werkt, niet alleen in een demo.
Doorloop dit in een staging-omgeving die productie nabootst:
Doe één volledige "bad day"-drill: roteer een certificaat, verander een claim of breek de IdP-URL en bevestig dat je het snel kunt detecteren.
Bevestig vervolgens dat je monitoring en alerts hebt voor SSO-fouten (per tenant), plus een rollback-plan (feature flag, config revert of snelle deploy) dat je geoefend hebt.
Kies een helder startpunt. De meeste enterprise-kopers vragen om "SAML met Okta/Entra ID" of "OIDC met Google/Microsoft," en je wilt niet in week één beide beloven tenzij je het team hebt. Beslis wat je eerst ondersteunt (SAML only, OIDC only of beide) en beschrijf wat "klaar" betekent voor product en support.
Maak voordat je een echte klant betrekt een kleine interne demo-tenant. Gebruik die om de volledige flow te repeteren: schakel SSO in, test login, beperk tot een domein en herstel toegang als iets fout gaat. Hier wordt ook je support-playbook getest.
Houd een levend enterprise-requirementsdocument bij. Reviews veranderen en één centrale bron over wat je ondersteunt voorkomt eenmalige beloften die later onboarding breken.
Een eenvoudig plan dat in de praktijk werkt:
Als je snel wilt bewegen aan de productzijde, kun je de instellingen en tenantstructuur prototypen in Koder.ai (koder.ai) en itereren zodra security-questionnaires van klanten binnenkomen.
Plan voor add-ons die vaak volgen na SSO: SCIM-provisioning, auditlog-exports en admin-rollen met duidelijke permissies. Zelfs als je ze niet meteen uitbrengt, zullen kopers ernaar vragen en je antwoord moet consistent blijven.
De meeste enterprise-teams willen gecentraliseerde controle over toegang. SSO stelt hen in staat om MFA en inlogregels via hun identity provider af te dwingen, toegang snel te verwijderen als iemand vertrekt, en aan auditvereisten te voldoen zonder dat jouw app wachtwoorden hoeft te beheren.
Begin met wat hun identity provider al ondersteunt en wat hun vendor-onboardingbeleid vereist. OIDC is vaak vloeiender voor moderne web- en mobiele flows, terwijl SAML in veel grotere bedrijven verplicht kan zijn omdat het al wijdverspreid en gestandaardiseerd is.
OIDC is een authenticatielaag bovenop OAuth die ontworpen is voor login. OAuth op zichzelf gaat vooral over autorisatie van API-toegang, niet over het bewijzen van iemands identiteit. Als je “Inloggen met het bedrijfs-IdP” implementeert, bedoel je vrijwel altijd OIDC in plaats van rauwe OAuth.
Nee. SSO regelt hoe gebruikers inloggen; SCIM automatiseert het aanmaken, bijwerken en deactiveren van gebruikers (en soms groepen). Een veelgebruikte enterprise-opzet is SAML of OIDC voor sign-in plus SCIM zodat offboarding en rolwijzigingen niet handmatig in jouw app hoeven te gebeuren.
Behandel SSO als een per-tenant instelling, niet als een globale schakel. Los de tenant eerst op (via domeinrouting, invite of expliciete organisatiekeuze) en start dan de SSO-handshake met de IdP-config van die tenant. Zo voorkom je dat de IdP-instellingen van de ene klant de inlog van een andere klant beïnvloeden.
Gebruik een stabiele identifier van de IdP (zoals OIDC sub of een SAML NameID) als primaire koppeling, en behandel e-mail als een secundair attribuut dat kan veranderen. Koppel bij de eerste SSO-login alleen aan een bestaand account wanneer je zeker bent dat het dezelfde persoon is en de tenant klopt; anders eis je een invite of admin-confirmatie.
Houd een break-glass admin-account dat zonder SSO kan inloggen en maak SSO opt-in totdat een admin bevestigt dat het werkt. Zorg ook voor een enkele schakel om SSO voor die tenant uit te zetten als de IdP-config misgaat, zodat support snel toegang kan herstellen zonder codewijziging.
Ondersteun lokale logout betrouwbaar in je app en leg uit dat globale afmelding over alle apps heen afhankelijk is van de IdP van de klant. Plan daarnaast snelle intrekking van toegang door sessies te laten verlopen of gebruikersstatus opnieuw te controleren zodat een gedeactiveerde gebruiker niet kan blijven werken vanuit een oude browsertab.
Focus op tenant-gebonden SSO-foutlogs die helpen te achterhalen wat misging zonder geheimen te bewaren. Leg een correlatie-ID vast, de tenant, de issuer/entity ID, tijdstempels en een duidelijke reden zoals handtekeningfout, audience mismatch of verlopen certificaat. Sla geen raw tokens, volledige SAML-assertions, client secrets of private keys op.
Je hebt tenant-level configuratiestorage nodig, een admin-UI om IdP-instellingen te beheren, veilige account-linkregels en een rollback-pad. Als je op Koder.ai bouwt, plan dan het tenantmodel vroeg en gebruik snapshots en rollback tijdens de rollout zodat een verkeerde wijziging niet elke klant buitensluit.