SAML of OIDC: het verschil en de juiste keuze voor je bedrijf

SAML en OIDC doen allebei hetzelfde: ze laten je medewerkers met één account inloggen op meerdere applicaties (single sign-on). Het verschil zit in de techniek en het type applicatie. SAML is de oudere XML-standaard voor zakelijke webapplicaties in de browser, OIDC is de modernere laag bovenop OAuth 2.0 met compacte JSON-tokens, gebouwd voor cloud, mobiele apps en API’s. Voor nieuwe toepassingen is OIDC meestal de logische keuze, SAML blijft nodig waar een leverancier, klant of overheidskoppeling erom vraagt. Maar voor een mkb-bedrijf is de keuze zelden het echte probleem. Wat het verschil maakt, is of iemand de koppelingen goed instelt, certificaten en sleutels op tijd vernieuwt en direct ingrijpt als inloggen ineens niet meer lukt.

Kort samengevat

• Zelfde doel, andere techniek: SAML werkt met XML-assertions via de browser, OIDC met JSON Web Tokens (JWT) en REST-API’s.
• SAML past bij bestaande zakelijke webapplicaties, leveranciers die het eisen en koppelingen zoals DigiD en eHerkenning.
• OIDC past bij nieuwe SaaS-diensten, single-page-apps, mobiele apps en API’s, en is daar volgens Microsoft de standaardkeuze.
• OAuth 2.0 is geen inlogprotocol maar een autorisatiekader; OIDC voegt daar de identiteitslaag aan toe.
• Beheer bepaalt de veiligheid: tokenvalidatie, sleutelrotatie, certificaatbeheer en MFA zijn bij beide protocollen het werk dat telt.

Inhoudsopgave

• Wat SAML en OIDC gemeen hebben
• Hoe SAML werkt
• Hoe OIDC werkt
• Waar past OAuth 2.0 in het verhaal?
• De verschillen op een rij
• Wanneer kies je SAML, wanneer OIDC?
• SAML en OIDC in Nederland: DigiD, eHerkenning en de overheid
• Veilig instellen en beheren: hier gaat het mis
• Onze kijk: het protocol is zelden het probleem
• ICT-beheer dat je inlogomgeving veilig houdt
• Veelgestelde vragen
• Bronnen

Wat SAML en OIDC gemeen hebben

Voordat we de verschillen bespreken, eerst de overeenkomst, want die is groter dan veel vergelijkingen doen vermoeden. SURF, de ICT-coöperatie van het Nederlandse onderwijs en onderzoek, legt het helder uit: SAML en OIDC zijn allebei federatieve authenticatieprotocollen. Het systeem waar de identiteit van de gebruiker is opgeslagen, is niet hetzelfde als de online dienst waar hij inlogt. De dienst vertrouwt erop dat de identiteitsgegevens kloppen.

In de praktijk heb je bij beide protocollen dus drie partijen:

1. De gebruiker, bijvoorbeeld een medewerker die zijn boekhoudpakket opent.
2. De identity provider (IdP), het systeem dat weet wie die medewerker is, zoals Microsoft Entra ID.
3. De applicatie (bij SAML de service provider, bij OIDC de relying party of client), die de medewerker toegang geeft zodra de IdP heeft bevestigd wie hij is.

Voor je medewerkers voelt het resultaat hetzelfde: één keer inloggen, eventueel met een tweede factor, en daarna zonder extra wachtwoorden door naar de applicaties die ze nodig hebben. Het verschil zit onder de motorkap, en juist daar bepaalt het hoeveel werk de koppeling vraagt.

Hoe SAML werkt

SAML staat voor Security Assertion Markup Language. Versie 2.0 is een standaard van OASIS die op 1 maart 2005 werd goedgekeurd. De specificatie beschrijft XML-gecodeerde ‘assertions’, verklaringen over authenticatie, attributen en autorisatie, plus de protocollen om die verklaringen over te brengen.

Een typische inlog via SAML verloopt zo:

1. De medewerker opent een zakelijke webapplicatie.
2. De applicatie stuurt de browser door naar de identity provider.
3. De medewerker logt daar in, eventueel met tweestapsverificatie.
4. De IdP maakt een ondertekende XML-assertion met daarin wie de gebruiker is en welke kenmerken (zoals afdeling of rol) hij heeft.
5. De browser levert die assertion af bij de applicatie, die de handtekening controleert en toegang geeft.

Bij de variant die SURFconext ondersteunt, loopt het berichtenverkeer volledig via de browser. Dat maakt SAML sterk in klassieke webomgevingen, maar minder geschikt voor situaties zonder browser. Microsoft noemt SAML 2.0 een volwassen XML-standaard die veel wordt gebruikt in ondernemingen. Wie al jaren zakelijke software gebruikt, komt het dus vrijwel zeker tegen.

NLXS

Bespreek veilig ICT-beheer

Kom langs om te bespreken hoe NLXS bedrijven ontzorgt met hosting en ICT-diensten, afgestemd op hun specifieke behoeften.

NLXS

Lage Mosten 51, 4822 NK Breda

Bekijk de route

© OpenStreetMap contributors

Hoe OIDC werkt

OpenID Connect is jonger. OpenID Connect Core 1.0 werd in februari 2014 door de OpenID Foundation gepubliceerd als een eenvoudige identiteitslaag bovenop OAuth 2.0. Een applicatie kan daarmee de identiteit van de gebruiker controleren op basis van de authenticatie door een autorisatieserver, en basisprofielgegevens ophalen via een REST-achtige interface.

Het belangrijkste onderdeel is het ID-token: een JSON Web Token (JWT) waarin staat wie de gebruiker is, wie het token heeft uitgegeven, voor welke applicatie het bedoeld is en tot wanneer het geldig is. Volgens de beslisgids van Microsoft gebruikt OIDC JWT’s en REST-API’s en is het ontworpen voor het authenticeren van eindgebruikers.

Een tweede verschil met SAML: bij OIDC wisselen de online dienst en de identiteitsserver ook rechtstreeks berichten uit, in JSON in plaats van XML. Daardoor werkt OIDC net zo goed in een mobiele app of tussen twee servers als in een webbrowser.

Waar past OAuth 2.0 in het verhaal?

Wie zoekt op SAML en OIDC, komt al snel OAuth tegen. Die drie worden vaak door elkaar gehaald, terwijl ze iets anders doen.

• Authenticatie is vaststellen wie iemand is. Dat doen SAML en OIDC.
• Autorisatie is bepalen wat iemand of een applicatie mag. Dat doet OAuth 2.0.

OAuth 2.0 is vastgelegd in RFC 6749 van de IETF uit oktober 2012. Het framework laat een applicatie van derden beperkte toegang krijgen tot een dienst, namens de eigenaar van de gegevens of in eigen naam. Het access token dat OAuth uitgeeft, beschrijft een bereik en een levensduur, en is voor de applicatie doorgaans ondoorzichtig: het zegt wat er mag, niet wie de gebruiker is.

Precies dat gat vult OIDC. Een eenvoudige vergelijking: OAuth zegt tegen een applicatie “deze gebruiker heeft je toegang gegeven tot zijn agenda”. OIDC voegt toe “en dit is Sanne van de financiële administratie, zojuist ingelogd”. Is OIDC dan gebaseerd op SAML? Nee. OIDC bouwt voort op OAuth 2.0, SAML is een losstaande standaard op basis van XML. Ze lossen hetzelfde probleem op, maar hebben geen gemeenschappelijke techniek.

De verschillen op een rij

De rij over tokens en handtekeningen komt rechtstreeks uit de vergelijking van Microsoft: SAML werkt met XML-assertions en XML-handtekeningen, OIDC met JWT’s en JWT-handtekeningen. Beide zijn veilig als ze goed zijn ingericht. Het verschil is vooral hoeveel er bij het inrichten en onderhouden mis kan gaan, en wie dat in de gaten houdt.

Wanneer kies je SAML, wanneer OIDC?

Microsoft geeft in zijn beslisgids voor SAML en OIDC een heldere vuistregel: gebruik voor nieuwe SaaS- en cloud-native toepassingen OIDC als standaard, tenzij er expliciete eisen zijn die SAML voorschrijven. Vertaald naar de praktijk van een Nederlands mkb-bedrijf:

SAML is de juiste keuze als

• een zakelijke applicatie of leverancier alleen SAML ondersteunt;
• een grote klant of opdrachtgever SAML eist vanuit inkoop- of compliance-regels;
• je bestaande identity provider een oudere omgeving is die alleen met SAML werkt;
• je koppelt met een Nederlandse identiteitsdienst als DigiD of eHerkenning (zie hieronder).

OIDC is de juiste keuze als

• je een nieuwe cloudapplicatie of SaaS-dienst aansluit;
• je eigen software, een webshop of klantportaal ‘inloggen met je zakelijke account’ wilt bieden;
• je een mobiele app of single-page-app gebruikt of laat bouwen;
• applicaties onderling via API’s gegevens uitwisselen.

Allebei tegelijk

Veel bedrijven hebben in de praktijk beide nodig. Je identity provider spreekt dan SAML met het oudere personeelssysteem en OIDC met de nieuwe SaaS-tools. Dat is geen probleem, zolang één partij overziet welke koppelingen er zijn, welk protocol ze gebruiken en wanneer certificaten of sleutels verlopen. Hier hoort ook je bredere cloudkoers bij: wie een zakelijke cloudstrategie opstelt, neemt de inlogarchitectuur er meteen in mee.

SAML en OIDC in Nederland: DigiD, eHerkenning en de overheid

Voor Nederlandse organisaties speelt nog een factor mee: de overheid. Volgens developer.overheid.nl stoelen DigiD, eHerkenning en eIDAS op SAML 2.0 als technische basis. Tegelijk wijst dezelfde bron erop dat SAML is ontworpen voor SSO in de browser en niet voor het beveiligen van API’s, terwijl OIDC API-first en kanaalonafhankelijk is.

Het Forum Standaardisatie heeft SAML en OpenID.NLGov op de lijst van open standaarden staan. Volgens het Forum Standaardisatie gelden ze samen als verplichting onder ‘pas toe of leg uit’ voor de overheid. OpenID.NLGov is het Nederlandse profiel van OIDC, met aanscherpende eisen bovenop de internationale standaard.

Wat betekent dit voor jou als ondernemer? Werk je voor of met overheidsorganisaties, of bied je diensten aan waarvoor klanten met eHerkenning inloggen, dan krijg je vrijwel zeker met SAML te maken. Bouw je nieuwe digitale diensten, dan is het verstandig rekening te houden met OIDC, omdat de overheid die richting ook expliciet opneemt. Ook in het onderwijs zie je beide naast elkaar: SURFconext ondersteunt naast SAML ook OIDC.

Veilig instellen en beheren: hier gaat het mis

Het protocol kiezen is één beslissing. Het veilig houden is dagelijks werk. Dit zijn de punten die bij elke SSO-koppeling op orde moeten zijn.

1. Valideer het ID-token volledig (OIDC). Een applicatie moet controleren wie het token heeft uitgegeven (iss), voor wie het bedoeld is (aud), wanneer het verloopt (exp) en of de nonce klopt. Onderzoek naar federatief identiteitsbeheer noemt die validatie en het afdwingen van PKCE essentieel voor een betrouwbaar inlogproces. Waar het misgaat: een applicatie die alleen kijkt of er een token is, zonder de inhoud te controleren.
2. Gebruik PKCE bij mobiele apps en single-page-apps. Die extra controle voorkomt dat een onderschepte autorisatiecode bruikbaar is. Waar het misgaat: oude voorbeeldcode zonder PKCE die ongemerkt in productie belandt.
3. Laat XML over aan beproefde software (SAML). XML-handtekeningen correct verwerken is complex. Gebruik de ingebouwde SAML-ondersteuning van je identity provider en applicaties, en geen zelfgeschreven verwerking. Waar het misgaat: maatwerkcode die een handtekening controleert, maar niet of die handtekening ook echt de inhoud dekt.
4. Plan certificaat- en sleutelrotatie. Bij SAML heeft elke koppeling een ondertekeningscertificaat met een einddatum. Verloopt dat ongemerkt, dan kan niemand meer inloggen. Bij OIDC werkt het soepeler: integraties die sleutels dynamisch via JWKS ophalen werken doorgaans zonder wijzigingen als de sleutels wisselen. Test een rotatie altijd eerst buiten de productieomgeving. Het principe kennen we van webcertificaten: een SSL-certificaat vernieuwen vraagt dezelfde discipline.
5. Zet tweestapsverificatie aan bij de identity provider. SSO betekent één sleutel tot alle applicaties. Is dat account niet extra beveiligd, dan is één gelekt wachtwoord genoeg. Lees hoe je tweestapsverificatie overal aanzet.
6. Houd een overzicht van alle koppelingen. Welke applicaties zijn gekoppeld, met welk protocol, welke gebruikersgegevens gaan erheen en wie is eigenaar? Waar het misgaat: een vertrokken medewerker die via een vergeten koppeling nog toegang heeft.

Elk van deze punten is op zich niet ingewikkeld. Het risico zit in de combinatie: tientallen koppelingen, elk met een eigen vervaldatum en instellingen, beheerd naast het gewone werk. Dat is het moment waarop uitbesteden meer oplevert dan zelf blijven puzzelen.

Onze kijk: het protocol is zelden het probleem

Als ondernemers ons vragen of ze voor SAML of OIDC moeten kiezen, is ons eerlijke antwoord vaak: je kiest meestal niet zelf. De applicatie, de leverancier of de klant bepaalt welk protocol er gesproken wordt. Wat je wel zelf bepaalt, is hoe goed het geregeld is.

Voor een klein bedrijf is single sign-on een enorme winst. Minder wachtwoorden, minder vergeten inlogs en één centrale plek om een medewerker toegang te geven of te ontnemen. Maar die winst valt alleen als de basis klopt: tweestapsverificatie aan, certificaten op tijd vernieuwd, koppelingen gedocumenteerd. Gaat daar iets mis, dan staat niet één applicatie stil, maar het hele bedrijf.

Daarom geloven we in ontzorgen. Wij willen dat je ons direct aan de telefoon hebt als er iets niet werkt, en dat het binnen één dag is opgelost. Geen wachtrij, geen ticket dat een week blijft liggen, en een vast maandbedrag zonder verrassingen. Dan kun jij je richten op je core business, en houden wij de techniek eronder betrouwbaar en veilig.

Ken

ICT-beheer dat je inlogomgeving veilig houdt

Wil je weten hoe jouw ICT-omgeving ervoor staat? Met een ICT-scan brengen we je omgeving in kaart en geven we advies over wat beter, veiliger of goedkoper kan. Daarna kunnen we het beheer volledig van je overnemen, met werkplekbeheer, serverbeheer, netwerkbeheer en support voor een transparant maandtarief.

Bekijk onze hosted ICT-diensten voor het mkb of lees eerst wat beter past: managed ICT of eigen beheer. Neem contact met ons op, dan denken we persoonlijk met je mee.

Veelgestelde vragen

Wat is het belangrijkste verschil tussen SAML en OIDC?

SAML wisselt identiteitsgegevens uit via XML-assertions die vooral via de browser lopen. OIDC gebruikt compacte JSON Web Tokens en bouwt voort op OAuth 2.0, waardoor het ook goed werkt in mobiele apps en tussen API’s. Het doel, veilig inloggen met één account, is bij beide hetzelfde.

Is OIDC beter dan SAML?

Niet in het algemeen, wel voor nieuwe toepassingen. Voor nieuwe cloud- en SaaS-applicaties, mobiele apps en API’s is OIDC meestal de eenvoudigere en flexibelere keuze. SAML blijft de juiste keuze waar een leverancier, klant of overheidskoppeling het vereist. Beide zijn veilig als ze goed zijn ingericht en beheerd.

Is OIDC gebaseerd op SAML?

Nee. OIDC is een identiteitslaag bovenop OAuth 2.0 en gebruikt JSON. SAML is een losstaande standaard uit 2005 op basis van XML. Ze lossen hetzelfde probleem op, maar delen geen techniek.

Wat is het verschil tussen SAML en OAuth?

SAML regelt authenticatie: het bevestigt wie een gebruiker is. OAuth 2.0 regelt autorisatie: het bepaalt waartoe een applicatie toegang krijgt namens een gebruiker. Wil je met OAuth ook vaststellen wie er inlogt, dan heb je OIDC nodig.

Heb ik als klein bedrijf SSO nodig?

Zodra je medewerkers met meerdere zakelijke applicaties werken, maakt single sign-on het werk eenvoudiger en het beheer veiliger, omdat je toegang op één plek regelt. Combineer het altijd met tweestapsverificatie. Wij helpen je graag om te bepalen wat bij jouw situatie past.

Bronnen

• OASIS: Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0
• OpenID Foundation: OpenID Connect Core 1.0
• IETF: RFC 6749, The OAuth 2.0 Authorization Framework
• Microsoft Learn: SAML versus OpenID Connect, choose the right SSO protocol
• Microsoft Learn: Wat is eenmalige aanmelding in Microsoft Entra ID?
• SURF Communities: SURFconext OpenID Connect voor dummies
• developer.overheid.nl: OIDC voor Nederlandse identiteitsdiensten
• Forum Standaardisatie: OIDC
• Federated Identity Management in Cloud Microservices: Protocols, Patterns, and Security
• Ubisecure Developer: Key rotation, SSO, Identity Server 2025.2

Aanbevelingen

• Microsoft Authenticator instellen voor je bedrijf