Single Sign-On (SSO): hoe eenmalige authenticatie werkt, met protocollen en voorbeelden

Wat is Single Sign-On (SSO): hoe eenmalige authenticatie werkt, met protocollen en voorbeelden?

Single Sign-On (SSO) is een authenticatiemechanisme waarmee gebruikers één keer inloggen om toegang te krijgen tot meerdere applicaties zonder voor elke app opnieuw credentials in te voeren. Een centrale Identity Provider (IdP) verifieert de identiteit van de gebruiker en geeft tokens uit die applicaties (Service Providers) vertrouwen als bewijs van authenticatie. SSO vereenvoudigt het identiteitsbeheer voor zowel eindgebruikers als IT-beheerders.

Hoe werkt Single Sign-On (SSO): hoe eenmalige authenticatie werkt, met protocollen en voorbeelden technisch?

SSO is gebaseerd op federatieve authenticatieprotocollen die vertrouwen delegeren naar een centrale Identity Provider (IdP). De twee dominante protocollen zijn SAML 2.0 en OpenID Connect (OIDC). SAML 2.0 is het oudere, XML-gebaseerde protocol dat veel wordt gebruikt in enterprise-omgevingen. De flow werkt als volgt: een gebruiker bezoekt een applicatie (Service Provider), wordt doorgestuurd naar de IdP, logt in, en ontvangt een ondertekende SAML-assertion die de SP verifieert om toegang te verlenen. OIDC is gebouwd bovenop OAuth 2.0, gebruikt JSON Web Tokens (JWTs) en is populairder bij moderne webapplicaties en API-integraties vanwege de eenvoudigere implementatie. De OIDC-flow omvat een Authorization Code Flow (voor server-side apps), Implicit Flow (verouderd, voor SPAs) en PKCE (Proof Key for Code Exchange, de huidige standaard voor publieke clients). Gangbare Identity Providers in 2026 zijn Okta, Auth0 (onderdeel van Okta), Microsoft Entra ID (voorheen Azure AD), Google Cloud Identity, en de open-source oplossing Keycloak. SCIM (System for Cross-domain Identity Management) automatiseert user provisioning en deprovisioning tussen de IdP en aangesloten applicaties, zodat accounts direct worden aangemaakt of uitgeschakeld wanneer een medewerker in dienst treedt of vertrekt. Multi-factor authentication (MFA) wordt vrijwel altijd gecombineerd met SSO om een extra beveiligingslaag toe te voegen. Session management is een kritiek aandachtspunt: tokens moeten een beperkte levensduur hebben, refresh tokens moeten veilig worden opgeslagen, en single logout (SLO) moet ervoor zorgen dat alle sessies worden beëindigd wanneer een gebruiker uitlogt bij de IdP. Binnen de tokenlevenscyclus hebben access tokens doorgaans een korte geldigheid van 5 tot 15 minuten, terwijl refresh tokens langer meegaan maar na elk gebruik geroteerd moeten worden om token replay-aanvallen te voorkomen. SAML-metadata wordt uitgewisseld tussen IdP en SP via XML-documenten die de endpoints, ondersteunde bindings en X.509-certificaten bevatten; deze certificaten moeten periodiek worden geroteerd, idealiter met een overlappingsperiode waarin zowel het oude als het nieuwe certificaat geldig zijn om downtime te voorkomen. Ter preventie van session fixation dient de applicatie bij elke succesvolle authenticatie een nieuw session-ID te genereren in plaats van het bestaande ID te hergebruiken. Voor IdP-failover configureren enterprise-organisaties vaak een secundaire IdP of lokale fallback-authenticatie, zodat gebruikers bij een storing van de primaire IdP niet volledig worden buitengesloten.

Hoe past MG Software Single Sign-On (SSO): hoe eenmalige authenticatie werkt, met protocollen en voorbeelden toe in de praktijk?

Bij MG Software integreren we SSO via OIDC en SAML in de SaaS-producten die we voor klanten bouwen. We ondersteunen enterprise-klanten bij het koppelen van hun bestaande IdP (Okta, Entra ID, Google) aan de applicatie en bouwen op Supabase Auth als flexibele authenticatielaag. Onze implementaties omvatten SCIM-provisioning voor automatisch gebruikersbeheer, MFA-integratie voor extra beveiliging, en secure session management met korte token-levensduur en refresh-token-rotatie. We adviseren klanten over de juiste protocolkeuze op basis van hun bestaande IT-landschap. Concreet bouwen we SCIM-webhookhandlers die provisioninggebeurtenissen in real-time verwerken en foutmeldingen loggen naar een centraal monitoringdashboard. Onze token-rotatiestrategie combineert korte access tokens (10 minuten) met veilig opgeslagen refresh tokens in HttpOnly cookies, waarbij elke rotatie het vorige token direct ongeldig maakt. Daarnaast implementeren we periodieke IdP-health checks die bij onbereikbaarheid automatisch een fallback-authenticatiemechanisme activeren, en voorzien we elke SSO-flow van gedetailleerde audit logging met IP-adres, user agent en tijdstempel voor compliance-rapportages.

Waarom is Single Sign-On (SSO): hoe eenmalige authenticatie werkt, met protocollen en voorbeelden belangrijk?

SSO vermindert het aantal wachtwoorden dat medewerkers moeten onthouden en verlaagt daarmee het risico op hergebruikte of zwakke wachtwoorden aanzienlijk. Voor enterprise-klanten is SSO-ondersteuning vaak een harde eis bij de aanschaf van SaaS-producten, waardoor het een commercieel relevante feature is. IT-beheerders krijgen centraal overzicht over wie toegang heeft tot welke applicaties en kunnen bij uitdiensttreding in één handeling alle toegang intrekken. Dit versterkt de beveiligingshouding van de organisatie en vereenvoudigt compliance met regelgeving zoals AVG/GDPR en ISO 27001. Daarnaast biedt een centraal audit trail via de IdP volledige traceerbaarheid van wie wanneer welke applicatie heeft benaderd, wat bij incidentonderzoek of forensische analyse essentieel is. Organisaties met SSO-implementaties rapporteren doorgaans lagere cyberverzekeringspremies doordat verzekeraars centraal identiteitsbeheer als risicoverlagend beschouwen. Voor softwareleveranciers die aan enterprise-klanten verkopen is SSO bovendien een concurrentievoordeel: zonder SSO-ondersteuning vallen producten vaak al in de preselectiefase af bij aanbestedingen en procurement-evaluaties.

Veelgemaakte fouten met Single Sign-On (SSO): hoe eenmalige authenticatie werkt, met protocollen en voorbeelden

Teams implementeren SSO zonder degelijk session management, waardoor tokens actief blijven nadat een gebruiker bij de IdP is gedeactiveerd. Single logout (SLO) wordt vaak vergeten, zodat het uitloggen bij één applicatie de sessies bij andere apps intact laat. Een andere fout is het niet testen van edge cases zoals verlopen tokens, IdP-downtime en het gedrag wanneer een gebruiker halverwege de login-flow de browser sluit. SCIM-provisioning wordt soms overgeslagen waardoor accounts handmatig moeten worden aangemaakt en verwijderd, wat het risico op zwevende accounts vergroot. Daarnaast wordt session fixation soms over het hoofd gezien: als de applicatie geen nieuw session-ID genereert na authenticatie, kan een aanvaller een vooraf verkregen sessie overnemen. Certificaatbeheer is een ander veelvoorkomend probleem; teams vergeten SAML-signing-certificaten tijdig te roteren, wat leidt tot plotselinge loginfouten wanneer een certificaat verloopt. Tot slot negeren sommige teams foutafhandeling in SCIM-webhooks, waardoor provisioningfouten onopgemerkt blijven en gebruikers geen toegang krijgen.

Welke voorbeelden zijn er van Single Sign-On (SSO): hoe eenmalige authenticatie werkt, met protocollen en voorbeelden?

• Google Workspace waar een medewerker één keer inlogt via SAML 2.0 of OIDC en vervolgens naadloos toegang heeft tot Gmail, Google Drive, Google Meet, Calendar en alle andere Google-diensten zonder opnieuw een wachtwoord in te voeren. Organisaties met meer dan 500 medewerkers gebruiken dit om gemiddeld vijf tot tien aparte loginmomenten per dag te elimineren, wat de productiviteit merkbaar verhoogt.
• Een enterprise SaaS-applicatie die via SAML 2.0 is gekoppeld aan Microsoft Entra ID, zodat medewerkers met hun bedrijfsaccount inloggen en IT-beheerders centraal toegang kunnen beheren en intrekken wanneer iemand uit dienst gaat. Bij organisaties met 1.000 of meer gebruikers bespaart dit het IT-team gemiddeld 15 uur per maand aan handmatig accountbeheer en verlaagt het het risico op ongeautoriseerde toegang na vertrek.
• Een intern bedrijfsportaal dat OIDC met PKCE-flow gebruikt om medewerkers met één login toegang te geven tot HR-tools, projectmanagementsoftware, tijdregistratie en het intranet, terwijl MFA wordt afgedwongen bij de eerste authenticatie. Access tokens verlopen na 10 minuten en worden automatisch vernieuwd via refresh tokens, zodat sessies veilig blijven zonder dat gebruikers opnieuw moeten inloggen.
• Een SaaS-platform dat SCIM 2.0-provisioning via webhooks implementeert zodat wanneer een nieuwe medewerker wordt toegevoegd in Okta, automatisch een account wordt aangemaakt in de applicatie met de juiste rechten op basis van groepslidmaatschap in de IdP-directory. Bij deactivering in Okta wordt het account binnen seconden uitgeschakeld, waardoor het venster voor ongeautoriseerde toegang minimaal is.
• Een zorginstelling die SSO combineert met role-based access control (RBAC), waarbij artsen na één login via Entra ID toegang krijgen tot het patiëntendossier (EPD), het laboratoriumsysteem en de medicatiemodule, terwijl administratief personeel uitsluitend de planningstools en facturatiesystemen ziet. De IdP stuurt groepsclaims mee in het SAML-token die de applicatie vertaalt naar fijnmazige permissies.

Gerelateerde begrippen