In salesgesprekken vragen we natuurlijk altijd waarom iemand contact opneemt, en wat ze al doen qua toegangsbeleid en wachtwoordmanagement. Dan horen we vaak dat ze “SSO hebben voor alles”. Dat wekt mijn nieuwsgierigheid; want als een organisatie al voor alles SSO heeft, waarom zou je dan met een aanbieder van wachtwoordoplossingen praten?

Wanneer ik doorvraag of werkelijk elke applicatie via SSO is gekoppeld, blijkt dat meestal niet het geval. Wat organisaties bedoelen, is dat een centrale identityprovider zoals Microsoft Entra ID (Azure AD) of Google Identity is ingericht. Gebruikers hebben daarmee direct toegang tot Microsoft 365 of Google Workspace (mail, agenda, bestanden, Teams/Meet) en een beperkt aantal externe SaaS-applicaties die via SAML, OAuth of OIDC zijn gekoppeld. Voor deze specifieke applicaties wordt authenticatie afgehandeld via de identityprovider en hoeven gebruikers niet apart in te loggen. Voor een groot deel van het applicatielandschap geldt dit echter niet.

Het principe van Single Sign-On gaat in essentie verder: één identity (bijvoorbeeld een Microsoft- of Google-account) die wordt gebruikt om toegang te krijgen tot alle applicaties, doordat deze technisch zijn gefedereerd met dezelfde identityprovider. In de praktijk is die volledige dekking zelden gerealiseerd en blijft een aanzienlijk deel van de applicaties buiten het SSO-domein vallen.

Juist daar ontstaat in de praktijk vaak verwarring. Met “SSO” bedoelt men geregeld dat Microsoft Entra ID of Google Identity in gebruik is en dat enkele zakelijke applicaties daarop is aangesloten. Technisch gezien is dat iets anders dan een situatie waarin het volledige applicatielandschap via één centrale identityprovider toegankelijk is. Daarom is het zinvol om scherp te definiëren wat SSO precies is, waar het goed werkt, waar de beperkingen liggen en wanneer aanvullende oplossingen nodig kunnen zijn, zoals een wachtwoordmanager. In dit artikel werken we dat stap voor stap uit.

Wat is de technische definitie van SSO?

Single Sign-On (SSO) is een authenticatiemechanisme waarbij een gebruiker zich één keer authenticeert bij een centrale identityprovider, zoals Microsoft Entra ID of Google Identity. Die identityprovider verzorgt vervolgens de authenticatie richting gekoppelde applicaties, waardoor de gebruiker niet opnieuw hoeft in te loggen.

Dit gebeurt via federatieve authenticatie: applicaties delegeren het inlogproces aan de identityprovider en vertrouwen op de identiteit die daar is vastgesteld. In de praktijk wordt dit gerealiseerd via standaarden zoals SAML, OAuth en OpenID Connect (OIDC).

SSO werkt daarmee uitsluitend voor applicaties die technisch zijn geïntegreerd met de identityprovider. Alleen in die gevallen kan authenticatie worden gecentraliseerd en hergebruikt. Dat betekent niet dat SSO beperkt is tot Microsoft- of Google-applicaties. Ook veel externe SaaS-applicaties ondersteunen federatieve login en kunnen worden gekoppeld aan dezelfde identityprovider, zoals Slack, Atlassian Jira, Salesforce, ServiceNow of Topdesk. In die gevallen wordt geen lokaal account meer gebruikt voor authenticatie, maar wordt de identiteit doorgegeven vanuit de identityprovider.

Voor applicaties zonder deze koppeling blijft een aparte authenticatiestroom bestaan, bijvoorbeeld via een gebruikersnaam en wachtwoord of een passkey. Die vallen daarmee buiten het SSO-domein.

Wat betekent dat voor de gebruiker?

Voor de gebruiker vertaalt SSO zich naar een doorlopende loginervaring. Na één succesvolle authenticatie bij de identityprovider (bijvoorbeeld via Microsoft Entra ID of Google Identity) ontstaat er een sessie, meestal in de vorm van een token. Zolang die sessie geldig is, kan de gebruiker zonder opnieuw in te loggen doorwerken in alle gekoppelde applicaties, zoals mail, agenda, Teams of andere SaaS-tools.

Zolang alle benodigde applicaties via dezelfde identityprovider zijn ontsloten, lijkt het alsof er geen losse accounts of wachtwoorden meer bestaan. De identityprovider fungeert immers als centrale bron voor authenticatie.

Dat verandert zodra een applicatie buiten dit SSO-domein valt. In dat geval ontbreekt de koppeling met de identityprovider en moet de gebruiker opnieuw authenticeren, bijvoorbeeld met een gebruikersnaam en wachtwoord of een passkey. Dit geldt ook voor scenario’s met gedeelde accounts, die vaak niet via federatieve login kunnen worden ontsloten.

Voor de gebruiker ontstaat daarmee een gefragmenteerde ervaring: een deel van de applicaties werkt naadloos via SSO, terwijl voor andere systemen nog steeds aparte inloggegevens nodig zijn.

De grenzen van SSO in de praktijk

In de praktijk stuit SSO op twee structurele beperkingen: technische dekking en kosten. Een aanzienlijk deel van het applicatielandschap ondersteunt geen federatieve authenticatie. Met name kleinere SaaS-tools, nicheapplicaties en leveranciersportalen hebben (nog) geen integratie met identityproviders zoals Microsoft Entra ID of Google Identity. Deze applicaties vallen daarmee buiten het SSO-domein en vereisen een eigen authenticatiestroom.

Daarnaast speelt een economisch vraagstuk. Veel SaaS-leveranciers bieden SSO-functionaliteit uitsluitend aan binnen hun duurdere enterprise-abonnementen. Op platforms zoals sso.tax is zichtbaar hoe vaak deze functionaliteit als premium optie wordt aangeboden. Organisaties betalen daardoor niet alleen voor hun eigen identityplatform, maar ook per applicatie om deze te kunnen koppelen. Zelfs wanneer volledige SSO technisch mogelijk is, betekent dit dus niet dat het praktisch of economisch logisch is om dit overal door te voeren.

Daar komt een strategische afweging bij. Hoe meer applicaties afhankelijk zijn van één identityprovider, hoe groter de impact bij compromittatie van die centrale identiteit. Toegang tot één account betekent in dat scenario toegang tot een groot deel van het applicatielandschap.

In de praktijk ontstaat daardoor vrijwel altijd een hybride situatie: een deel van de applicaties is gekoppeld via SSO, terwijl een ander deel daarbuiten valt en afhankelijk blijft van losse accounts en inloggegevens. Juist dat resterende deel bepaalt in hoge mate het daadwerkelijke risico en de beheerlast - en vraagt om een andere benadering dan SSO alleen.

Zonder inzicht geen effectief toegangsbeheer

Effectief toegangsbeheer begint niet bij technologie, maar bij inzicht in het applicatielandschap. In veel organisaties ontbreekt dat overzicht. Naast de formeel beheerde IT-systemen bestaat er vaak een lange reeks aan applicaties die buiten beeld blijven: SaaS-tools - in stroomverstelling geraakt dankzij de wildgroei aan AI-tools - die door teams zelf zijn geïntroduceerd, gratis diensten, leveranciers- en partnerportalen en diverse nicheapplicaties.

Voor deze applicaties is vaak onduidelijk hoe authenticatie plaatsvindt: of ze via de centrale identityprovider lopen, of dat er sprake is van losse accounts met eigen inloggegevens. Zonder dit inzicht is het niet mogelijk om gericht te bepalen waar SSO wordt toegepast, waar dat technisch of economisch haalbaar is en waar risico’s ontstaan door zwakke wachtwoorden, hergebruik of ongecontroleerde accounts.

Het in kaart brengen van dit applicatielandschap is in de praktijk complex, juist omdat veel van deze tools niet centraal worden geregistreerd. De monitoring-oplossing van MindYourPass maakt dit zichtbaar door daadwerkelijk applicatiegebruik en loginmethoden te inventariseren en analyseren. Daarmee ontstaat een realistisch beeld van waar SSO effectief wordt ingezet en waar aanvullende maatregelen nodig zijn binnen het werkelijke applicatielandschap van de organisatie.

Juist het deel van het applicatielandschap dat buiten SSO valt, bepaalt uiteindelijk de effectiviteit van je toegangsbeheer.

Van Single Sign-On naar Total Sign-On

SSO biedt een sterke basis voor applicaties die gekoppeld kunnen worden aan een identityprovider. Tegelijk is duidelijk dat een deel van het applicatielandschap daar structureel buiten valt. In plaats van dat als gegeven te accepteren, kun je sturen op één consistent model voor alle accounts - zowel binnen als buiten het SSO-domein.

Wij noemen dat Total Sign-On: een model waarin alle accounts onder dezelfde identiteit en hetzelfde afdwingbare beleid vallen, ongeacht of een applicatie SSO ondersteunt. Niet alles hoeft via SAML, OAuth of OIDC te lopen om toch onder centrale controle te vallen.

Daar komt een oplossing als MindYourPass in beeld. Medewerkers authenticeren zich één keer via de bestaande identityprovider, bijvoorbeeld met Microsoft Entra ID. Vanuit die identiteit krijgen zij toegang tot zowel SSO- als niet-SSO-applicaties.

Voor applicaties met een federatieve koppeling verloopt dit via reguliere SSO. Voor applicaties zonder SSO loopt de toegang via het MindYourPass-platform, dat is gekoppeld aan de identityprovider. Medewerkers authenticeren zich daar bijvoorbeeld met biometrie of een andere sterke factor, waarna MindYourPass de onderliggende login met gebruikersnaam en wachtwoord automatisch uitvoert.

Beheerders kunnen hierbij centraal beleid afdwingen en toegangscondities bepalen, zoals wachtwoordcomplexiteit, voorkomen van hergebruikte of gelekte wachtwoorden voor elke webapplicatie - juist ook voor systemen die zelf geen ondersteuning bieden voor SSO of modern identitybeheer.

Voor de gebruiker ontstaat daarmee één consistente loginervaring, terwijl onderliggend verschillende authenticatiemechanismen worden gebruikt. Voor de organisatie betekent dit dat ook niet-SSO-applicaties onder dezelfde controle en beheersbaarheid vallen als applicaties die wél federatief zijn gekoppeld. Zo verschuift de focus van gedeeltelijke centralisatie naar volledige dekking van het applicatielandschap.

SSO of Total Sign-On: een vergelijking

Kosten zijn één aspect van de afweging, maar zeker niet het enige. Wanneer je beide benaderingen naast elkaar zet, spelen ook factoren mee zoals implementatietijd, afhankelijkheid van SaaS-leveranciers, dekking van het applicatielandschap en de mate waarin beleid centraal kan worden afgedwongen.

In onderstaande tabel zetten we de belangrijkste verschillen tussen een volledige SSO-strategie en een model waarin SSO wordt aangevuld met MindYourPass overzichtelijk naast elkaar.

Eindnoot

Er zijn meerdere routes die je als organisatie kunt kiezen, afhankelijk van je prioriteiten en IT-landschap. In de praktijk is er geen one-size-fits-all oplossing, maar wel een duidelijke volgorde in hoe je tot een goede keuze komt.

Het begint met inzicht: welke applicaties worden daadwerkelijk gebruikt en hoe vindt authenticatie daarop plaats? Pas op basis daarvan kun je bepalen waar SSO effectief kan worden ingezet, waar dat niet haalbaar is en waar aanvullende maatregelen nodig zijn.

De uiteindelijke keuze tussen bijvoorbeeld een SSO-strategie, een breder model zoals Total Sign-On, of een combinatie daarvan volgt uit die analyse. Factoren zoals kosten, implementatietijd en beheersbaarheid spelen daarbij een rol, maar zijn ondergeschikt aan de vraag of je beleid daadwerkelijk consistent kunt toepassen. Effectief toegangsbeheer draait uiteindelijk niet om het maximaliseren van SSO-dekking, maar om het minimaliseren van ongecontroleerde toegang. Dat betekent dat juist ook de applicaties buiten het SSO-domein onder dezelfde controle en beleidskaders moeten vallen.

‍