Cyberpediadoor Brain
NLDEENESFRIT

SSO: SAML en OpenID Connect eenvoudig uitgelegd

Eén account opent meerdere applicaties dankzij een token. Wat SAML en OpenID Connect doen en wat medewerkers kunnen doen tegen de valkuilen.

In 30 seconden

Waar het gebeurt
Telkens als u een bedrijfsapplicatie opent die doorverwijst naar de gezamenlijke inlogpagina.
Wat de aanvaller wil
Een token, een sessiecookie of een toestemming aan een nagemaakte, kwaadaardige applicatie, waarmee hij toegang krijgt zonder het wachtwoord te kennen23.
De reflex
Controleer het adres van de inlogpagina, schakel tweestapsverificatie in op het hoofdaccount, meld u af op een gedeelde computer en meld elk onverwacht inlogverzoek.
Als het al is gebeurd
Breng de IT-afdeling meteen op de hoogte en geef aan welke pagina openstond en welke toestemming is gegeven.

Waar gaat het over

SSO (single sign-on, eenmalige aanmelding) houdt in dat u zich één keer authenticeert bij een identiteitsprovider en daarna toegang krijgt tot meerdere applicaties, zonder voor elke applicatie een wachtwoord aan te maken of te onthouden1. De medewerker voert de inloggegevens in op de inlogpagina van het bedrijf, en de applicaties ontvangen een bewijs van de identiteit in plaats van het wachtwoord.

Twee protocollen verzorgen deze uitwisseling vooral: SAML en OpenID Connect (OIDC). Op het scherm ziet u ze niet, maar hun tokens zijn een doelwit geworden: wie het token of de sessie steelt, steelt de toegang.

Directe vragen

Wat is SSO?

Eén account, beheerd door een identiteitsprovider, dient voor meerdere applicaties. Het NIST-document over identiteitsfederatie beschrijft dit geval: de gebruiker authenticeert zich niet rechtstreeks bij de applicatie, maar de identiteitsprovider maakt een assertie op, vaak op verzoek van de applicatie1. NIST stelt dat dit mechanisme het overbodig maakt om voor elke dienst aparte inloggegevens te bezitten1.

Wat is het verschil tussen SAML en OpenID Connect?

SAML 2.0 is een protocol waarmee applicaties hun gebruikers SSO kunnen bieden; het wisselt asserties uit tussen de identiteitsprovider en de applicatie4. OpenID Connect breidt het autorisatieprotocol OAuth 2.0 uit tot een authenticatieprotocol, en SSO verloopt via een beveiligingstoken dat ID-token heet5. NIST noemt beide als voorbeelden van federatieprotocollen, met een assertie in de vorm van een OIDC-ID-token of een SAML-assertie1.

Is SSO minder veilig dan een wachtwoord per applicatie?

Het verplaatst het risico meer dan dat het dit wegneemt. De medewerker hoeft niet meer voor elke applicatie een wachtwoord te beheren1, maar één account opent meerdere diensten: als een aanvaller het account overneemt, zijn alle diensten die het accepteren blootgesteld. De valkuilen hieronder werken dit punt uit.

Wat beschermt tweestapsverificatie, en wat niet?

Ze beschermt het eerste inlogmoment, de aanmelding waarmee een sessie begint. Ze beschermt niet tegen een token of cookie die al is gestolen: directe toegang met een token heft het effect van een tweede factor op6, en sessiecookies kunnen sommige protocollen voor multifactorauthenticatie omzeilen3.

1Hoe het werkt1 min

Twee partijen wisselen informatie uit: de identiteitsprovider, die de persoon authenticeert, en de applicatie, die vertrouwt op wat de provider verklaart4. NIST noemt de applicatie een "relying party" en noemt het bericht van de identiteitsprovider dat haar over de persoon informeert een assertie1.

Bij SAML legt Microsoft uit dat de applicatie bij de identiteitsprovider een omleidingsadres en een metadata-adres registreert, waarmee de ondertekeningssleutel te verkrijgen is4. Bij OIDC haalt de applicatie ook een openbaar configuratiedocument op met de nuttige adressen en de publieke sleutels waarmee de handtekening van tokens wordt gecontroleerd5. OWASP beschrijft voor SAML een antwoord dat de assertie bevat, digitaal ondertekend met de privésleutel van de identiteitsprovider7.

Een token is geen wachtwoord: het bevestigt dat een authenticatie al heeft plaatsgevonden. Voor SAML noemt MITRE een standaardgeldigheid van een uur, die in het token kan worden aangepast8.

In de versie 2017/2020 van zijn richtlijnen, die inmiddels is vervangen, deelt NIST asserties in drie niveaus in. Op het eerste niveau is de assertie ondertekend door de identiteitsprovider. Op het tweede is ze ook versleuteld voor de applicatie. Op het derde bewijst de gebruiker bovendien dat hij een sleutel bezit die aan de assertie is gebonden1. De versie SP 800-63C-4, gedateerd juli 2025, vervangt die van 2 maart 20209; deze drie niveaus zijn dus niet de huidige regel1.

2Wat u doet1 min
  • Kijk naar het adres van de inlogpagina voordat u een wachtwoord invoert. Aanvallers onderscheppen de sessie onderweg, bijvoorbeeld met de tools evilginx2 en Muraena, die in phishingcampagnes zijn gebruikt3.
  • Schakel tweestapsverificatie in op uw hoofdaccount, het account dat de andere applicaties opent. Wie de toegang tot de hoofdmailbox in handen krijgt, kan via de procedure voor een vergeten wachtwoord bij andere diensten komen6.
  • Meld u af op een gedeelde computer. Sessiecookies blijven vaak lang geldig, ook als de applicatie niet meer wordt gebruikt3. Bij Microsoft beëindigt afmelden de sessie van de gebruiker5.
  • Lees het toestemmingsvenster voordat u klikt. Daarin wordt de gebruiker gevraagd rechten aan een applicatie te geven5.
  • Meld elk inlog- of toestemmingsverzoek dat u niet zelf hebt gestart, vooral na een bericht dat u aanzet op een link te klikken: zo laat een aanvaller toegang verlenen aan zijn applicatie2.
3De valkuilen2 min

Nepinlogportalen

De opensourceframeworks evilginx2 en Muraena verzamelen sessiecookies via een kwaadaardige proxy tussen het slachtoffer en de echte site3. Kali365 verkreeg OAuth-toegangs- en vernieuwingstokens door slachtoffers een apparaatautorisatieverzoek van de aanvaller te laten goedkeuren en door sessies te onderscheppen via een reverse-proxy-infrastructuur2.

Diefstal van tokens of sessies

Toegangstokens dienen om geautoriseerde verzoeken te doen namens een gebruiker6. Zodra ze gestolen zijn, vervangen ze het wachtwoord: de groep APT29 gebruikt gestolen tokens om zonder wachtwoord toegang tot accounts te krijgen2. Die toegang via API's is moeilijk op te merken, ook aan de kant van de provider, omdat ze op normaal gebruik lijkt6. Het wijzigen van het wachtwoord kan ontoereikend zijn om ze af te sluiten6. Met vernieuwingstokens zijn nieuwe tokens te krijgen zonder de gebruiker te raadplegen2.

Misbruik van OAuth-toestemmingen

Een aanvaller registreert zijn eigen applicatie bij de autorisatieserver en stuurt daarna een phishinglink, zodat het doelwit hem toegang geeft2. Zodra het token is verleend, kan de applicatie blijvende toegang tot het account krijgen, bijvoorbeeld om de mailbox te doorzoeken en contacten op te sommen26. De groep APT28 gebruikte applicaties die zich voordeden als "Google Defender", "Google Email Protection" en "Google Scanner" om Gmail-gebruikers te treffen2.

Het ene account als single point of failure

Wie een geldig SAML-ondertekeningscertificaat bezit, kan tokens vervalsen met de rechten en de geldigheidsduur van zijn keuze en zich zo authenticeren bij alle diensten die SAML 2.0 voor SSO gebruiken8. MITRE noemt de compromittering van SolarWinds, waarbij de groep APT29 tokens maakte met gecompromitteerde SAML-ondertekeningscertificaten8.

4Praktijkvoorbeelden1 min

2012: XML signature wrapping

OWASP wijst erop dat kwetsbaarheden in SAML-implementaties die verband houden met aanvallen met XML signature wrapping in 2012 zijn beschreven7. Tot de aanbevelingen behoort een veilige validatie van de digitale handtekening7. Dit werk is aan de IT-teams, niet aan de medewerker.

Fiche

Identificatie
CP-193
Vleugel
3. Protocollen en verdediging
Brain-competentie
Toegang beheersen (control_access)
Brain-reflex
cr-025
Schema
G3 · Anatomische doorsnede
Talen
de, en, es, fr, it, nl
Bronnen
9 bronnen gecontroleerd op 3 november 2026
Bronnen9 bronnen
  1. NIST, “NIST Special Publication 800-63C”. https://pages.nist.gov/800-63-3/sp800-63c.html (geraadpleegd op 3 november 2026)
  2. MITRE ATT&CK, “Steal Application Access Token, Technique T1528 - Enterprise | MITRE ATT&CK®”. https://attack.mitre.org/techniques/T1528/ (geraadpleegd op 3 november 2026)
  3. MITRE ATT&CK, “Steal Web Session Cookie, Technique T1539 - Enterprise | MITRE ATT&CK®”. https://attack.mitre.org/techniques/T1539/ (geraadpleegd op 3 november 2026)
  4. Microsoft, “How the Microsoft identity platform uses the SAML protocol - Microsoft identity platform”. https://learn.microsoft.com/en-us/entra/identity-platform/saml-protocol-reference (geraadpleegd op 3 november 2026)
  5. Microsoft, “OpenID Connect (OIDC) on the Microsoft identity platform - Microsoft identity platform”. https://learn.microsoft.com/en-us/entra/identity-platform/v2-protocols-oidc (geraadpleegd op 3 november 2026)
  6. MITRE ATT&CK, “Use Alternate Authentication Material: Application Access Token, Sub-technique T1550.001 - Enterprise | MITRE ATT&CK®”. https://attack.mitre.org/techniques/T1550/001/ (geraadpleegd op 3 november 2026)
  7. OWASP, “SAML Security - OWASP Cheat Sheet Series”. https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html (geraadpleegd op 3 november 2026)
  8. MITRE ATT&CK, “Forge Web Credentials: SAML Tokens, Sub-technique T1606.002 - Enterprise | MITRE ATT&CK®”. https://attack.mitre.org/techniques/T1606/002/ (geraadpleegd op 3 november 2026)
  9. NIST, “SP 800-63C-4, Digital Identity Guidelines: Federation and Assertions | CSRC”. https://csrc.nist.gov/pubs/sp/800/63/c/4/final (geraadpleegd op 3 november 2026)

Dit artikel citeren

Brain, “SSO: SAML en OpenID Connect eenvoudig uitgelegd”, Cyberpedia, 2026. https://startbrain.io/cyberpedia/nl/articles/sso-saml-openid-connect/

BibTeX 
@misc{brain_cp193_nl_2026,
  author = {Brain},
  title = {SSO: SAML en OpenID Connect eenvoudig uitgelegd},
  year = {2026},
  howpublished = {Cyberpedia},
  url = {https://startbrain.io/cyberpedia/nl/articles/sso-saml-openid-connect/},
  note = {CC BY 4.0}
}
Licentie CC BY 4.0