Wat is Single Sign-On SSO? | phoenixNAP IT-woordenlijst

Single sign-on (SSO) is een authenticatiemethode waarmee gebruikers met één set inloggegevens toegang kunnen krijgen tot meerdere applicaties of services.

Wat is Single Sign-On?

Single sign-on is een identiteitsfederatiepatroon waarbij een gebruiker zich één keer authenticeert bij een vertrouwde identiteitsprovider (IdP) en vervolgens cryptografisch ondertekende beweringen of tokens ontvangt die andere toepassingen (zogenaamde serviceproviders) accepteren als identiteitsbewijs. Na de eerste aanmelding geeft de IdP tijdsgebonden inloggegevens uit (bijvoorbeeld SAML-asserties of OpenID Connect ID-tokens) die de browser or klant presenteert aan elke applicatie, die de handtekening, het publiek en de vervaldatum verifieert voordat deze een eigen sessie start.

Omdat vertrouwen verankerd is in de IdP en wordt overgebracht via op standaarden gebaseerde protocollen, kunnen onafhankelijke systemen dankzij SSO een consistent beeld delen van wie de gebruiker is, welke kenmerken deze heeft en hoe lang deze actief is. authenticatie als geldig beschouwd moet worden.

Soorten Single Sign-On

Hieronder vindt u de meest voorkomende typen en hun werking.

SAML 2.0 Federatie

Beveiligingsverklaring Markup Language (SAML) is een op XML gebaseerde standaard die veel wordt gebruikt voor browser-SSO in ondernemingen SaaSNadat de gebruiker is geauthenticeerd bij de Identity Provider (IdP), ontvangt de browser van de gebruiker een ondertekende SAML-assertie die door de Service Provider (SP) wordt gevalideerd om een sessie tot stand te brengen.

SAML is volwassen, excelleert in het vrijgeven van bedrijfskenmerken (rollen, groepen) en is gebruikelijk voor HRIS-naar-SaaS en ADFS-naar-cloud integraties.

OpenID Connect (OIDC)

OIDC is gebaseerd op OAuth 2.0 en gebruikt JSON Web Tokens (JWT's) voor identiteit. Na authenticatie bij de IdP ontvangt de client een ID-token (wie u bent) en vaak ook een toegangstoken (wat u kunt noemen).

OIDC is lichter dan SAML, mobiel- en API-vriendelijk en ideaal voor moderne web en mobiele apps, single page applications (SPA's)en microservices die gestandaardiseerde, compacte tokens nodig hebben.

Kerberos/Geïntegreerde Windows-authenticatie (IWA)

Bij Kerberos-gebaseerde SSO (bijvoorbeeld met Active Directory) ontvangt het besturingssysteem een ticket van een Key Distribution Center en presenteert dit transparant aan services, waardoor 'stille' SSO op bedrijfsnetwerken mogelijk is. Het is snel, ondersteunt wederzijdse authenticatie en is ideaal voor on-premises apps en intranetten, omdat moderne configuraties vaak Kerberos-identiteiten overbruggen naar cloud via federatie.

OAuth 2.0-ondersteunde SSO (Token-Based Access)

OAuth zelf is een autorisatieframework, geen identiteitsprotocol, maar veel SSO-implementaties combineren het met OIDC of aangepaste identiteitseindpunten, zodat gebruikers zich één keer kunnen aanmelden en toegangstokens voor API's kunnen verkrijgen. Het resultaat is SSO over web- en servicelagen met kortlopende tokens, scopes en vernieuwingsstromen die geschikt zijn voor zero-trust-ontwerpen.

WS-Federatie (WS-Fed)

Een ouder, SOAP-georiënteerd Microsoft-federatieprotocol dat nog steeds aanwezig is in oudere ADFS- en SharePoint-scenario's. Het maakt browser-SSO mogelijk, vergelijkbaar met SAML, maar komt minder vaak voor in greenfield-projecten. In plaats daarvan migreren organisaties vaak WS-Fed-apps naar OIDC/SAML als onderdeel van cloud modernisering.

CAS (Centrale Authenticatie Service)

Dit is een eenvoudig protocol voor het verlenen van tickets, populair in het hoger onderwijs. Gebruikers authenticeren zich bij een centrale CAS. server, die servicetickets uitgeeft die door applicaties worden gevalideerd. CAS is eenvoudig te bedienen en uit te breiden, maar mist de rijkere claim- en token-ecosystemen van SAML/OIDC.

Reverse-Proxy/Header-gebaseerde SSO

Een gateway authenticeert gebruikers (via Kerberos, SAML, OIDC of MFA) en injecteert identiteitsheaders (bijv. X-Remote-User) in backend-apps die geen federatieprotocollen ondersteunen. Dit is handig voor het aanpassen van oudere apps, maar de beveiliging is afhankelijk van het strikt vertrouwen van alleen de volmacht en het verstevigen van directe app-toegang.

Wachtwoordkluis/Formulier-invul-SSO

Als laatste redmiddel voor apps zonder federatieondersteuning slaat een toegangsgateway de inloggegevens per gebruiker veilig op en logt deze programmatisch in. Dit verbetert het gemak, maar biedt geen echte federatie en taken zoals rotatie van inloggegevens, MFA handhaving en auditing worden complexer dan bij op standaarden gebaseerde SSO.

Hoe werkt Single Sign-On?

Met SSO kan een gebruiker zich één keer authenticeren bij een vertrouwde identiteitsprovider en dat bewijs hergebruiken om veilig toegang te krijgen tot meerdere applicaties (serviceproviders, SP's). Zo werkt het precies:

Initiatie en IdP-detectie. De gebruiker probeert een app te openen. De app (SP) detecteert geen lokale sessie en stuurt de gebruiker (vaak via SAML/OIDC-metadata) door naar de juiste IdP, waarmee wordt vastgesteld waar vertrouwen en aanmelding plaatsvinden.
Gebruikersauthenticatie bij de IdP. De IdP valideert de identiteit met behulp van geconfigureerde methoden, zoals een wachtwoord en MFA, toegangscodes of controles van de apparaatstatus, waardoor een nieuwe authenticatiecontext wordt gecreëerd met een nauwkeurig tijdstempel en betrouwbaarheidsniveau.
Uitgifte van tokens/asserties. Als de aanvraag slaagt, geeft de IdP een ondertekende, tijdsgebonden referentie uit (bijvoorbeeld een SAML-assertie, OIDC ID-token en toegangstoken) met de identificatie en claims/kenmerken van de gebruiker.
Veilige levering terug naar de app. De browser of client keert via een beveiligde binding (POST/redirect front-channel of back-channel token exchange) met de referenties terug naar de SP, waardoor de integriteit behouden blijft en manipulatie of herhaling wordt voorkomen.
Verificatie en sessie aanmaken. De SP valideert de handtekening, doelgroep, uitgever, nonce en vervaldatum. Als de controles slagen, wordt een app-sessie (cookie of token) gestart en wordt autorisatie toegepast op basis van rollen of claims.
Token vernieuwen en opvoeren (indien nodig). Naarmate sessies ouder worden of de toegangsgevoeligheid toeneemt, gebruikt de client vernieuwings- of herautorisatiestromen om nieuwe tokens te verkrijgen of MFA te verhogen, waardoor de toegang continu blijft zonder herhaaldelijke volledige aanmeldingen.
Afmelden en intrekken. Wanneer de gebruiker zich afmeldt of er een risico wordt gedetecteerd, beëindigt de SP de sessie. Optioneel zorgt Single Logout (SLO) of back-channel revocatie bij de IdP ervoor dat de afmelding wordt doorgegeven aan andere apps om resterende sessies te sluiten.

Wat is een voorbeeld van een SSO?

Een voorbeeld van een SSO is wanneer een medewerker Salesforce gebruikt zonder een lokale sessie, waardoor Salesforce hem of haar doorstuurt naar Okta (de identiteitsprovider van de organisatie). De gebruiker voltooit de inlog- en MFA-procedure van Okta, waarna Okta een ondertekende, kortstondige SAML-assertie uitgeeft met de ID en rollen van de gebruiker.

De browser stuurt deze bevestiging terug naar Salesforce, dat de handtekening, doelgroep en vervaldatum verifieert en vervolgens een eigen sessie aanmaakt en de machtigingen van de gebruiker toepast. Een apart Salesforce-wachtwoord is dus niet nodig. Bij volgende aanmeldingen bij andere gekoppelde apps (bijv. ServiceNow en Box) wordt de Okta-sessie hergebruikt, wat zorgt voor naadloze toegang tot alle apps met gecentraliseerd beleid en controle.

Wat zijn de voor- en nadelen van Single Sign-On?

Single sign-on stroomlijnt de toegang doordat gebruikers zich één keer hoeven te authenticeren en toegang hebben tot meerdere apps. Dit verbetert de gebruikerservaring en centraliseert de beveiligingsmaatregelen. Het concentreren van authenticatie brengt echter ook risico's en complexiteit met zich mee: als de identiteitslaag faalt of verkeerd is geconfigureerd, worden meerdere apps tegelijk getroffen. Daarom is een zorgvuldig ontwerp nodig om gemak en sterke beveiliging in balans te brengen.

Wat zijn de voordelen van Single Sign-On?

SSO verbetert de gebruikerservaring en centraliseert de controle door authenticatie te federeren via een vertrouwde identiteitsprovider. Dit zijn de belangrijkste voordelen:

Minder wachtwoorden, betere gebruikerservaring. Gebruikers melden zich één keer aan en hebben vervolgens toegang tot alle apps. Hierdoor verloopt het inloggen soepel en vermoeiend.
Strengere beveiligingsmaatregelen. Gecentraliseerde MFA, wachtwoordsleutels, apparaatstatuscontroles en voorwaardelijke toegang worden op uniforme wijze in alle apps toegepast.
Snellere onboarding/offboarding. Het verlenen of intrekken van toegang gebeurt via één identiteitsrecord, waardoor wijzigingen worden doorgevoerd naar alle aangesloten services.
Lagere ondersteuningskosten. Minder wachtwoordresets en accountblokkeringen betekenen minder helpdesktickets.
Consistent bestuur. Rollen, groepen en op kenmerken gebaseerde beleidsregels worden overal op dezelfde manier afgedwongen, waardoor minste privilege.
Betere zichtbaarheid en controle. Centrale logs en gestandaardiseerde tokens vereenvoudigen de monitoring, incident reactieen nalevingsrapportage.
Gereduceerd Phishing risico's. Gebruikers herkennen één enkele, beveiligde IdP-inlogstroom, waardoor er minder app-specifieke wachtwoorden zijn om te stelen.
Moderne app- en API-gereedheid. Standaarden (OIDC/SAML/OAuth) maken veilige toegang mogelijk voor web, mobiel en microservices met kortdurende tokens.
Veiliger verandermanagement. Met tokenlevensduur, sessiebeleid en step-up-authenticatie kunt u de zekerheid voor gevoelige acties vergroten zonder dat er nieuwe aanmeldingen nodig zijn.
Verbeterde productiviteit. Naadloze toegang tot meerdere apps zorgt voor kortere contextwisselingen en snellere workflows.

Wat zijn de nadelen van Single Sign-On?

Centralisatie van authenticatie levert concrete voordelen op, maar brengt ook technische en operationele risico's met zich mee die u moet beheersen. Dit zijn de belangrijkste uitdagingen:

Eén punt van falen en explosieradius. Als de IdP niet werkt of verkeerd is geconfigureerd, zijn meerdere apps in één keer ontoegankelijk.
Risico op verkeerde configuratie. Zwakke tokenvalidatie (doelgroep/uitgever/nonce), lange vervaldata of permissieve toekenning van kenmerken kunnen de deur openen voor imitatie en privilege creep.
Sessie- en tokenhygiëne. Het is lastig om een balans te vinden tussen gemak en veiligheid (bijvoorbeeld door het beheren van inactieve en absolute time-outs, vernieuwingstokens en het opvoeren van MFA). Bovendien verhogen te lange sessies het risico op overname.
Certificaat en sleutelbeheer. Roterende ondertekeningssleutels, afhandeling metadata Updates en klokafwijkingen vereisen gedisciplineerde handelingen, anders kunnen aanmeldingen stilzwijgend mislukken.
Complexiteit van het afmelden. Ondersteuning voor eenmalige afmelding (SLO) is inconsistent en gedeeltelijke afmeldingen laten resterende app-sessies achter.
Legacy en edge cases. Niet-gefedereerde apps dwingen wachtwoordopslag of headerinjectie af, wat kwetsbaarder en minder veilig is dan echte federatie.
Accountkoppeling en levenscyclus. Het toewijzen van identiteiten over directory's en tenants, JIT-provisioning en tijdige deprovisioning zijn foutgevoelig zonder schone HR en IAM bronnen.
Toegangsbeleid is wijdverspreid. Voorwaardelijke toegang, de status van apparaten en uitzonderingen per app kunnen lastig te begrijpen zijn, wat tot uitval of hiaten kan leiden.
Verkoper en normen worden vastgelegd. Eigendomsfuncties of protocolafwijkingen maken migraties duur en multi-IdP-strategieën moeilijker.
Privacy en gegevensminimalisatie. Als u te veel kenmerken tussen apps deelt, neemt de blootstelling toe. Daarom zijn er beheersmaatregelen nodig voor het vrijgeven van de minste kenmerken en toestemming.
Concentratie op phishing en misbruik. Eén beveiligde stroom helpt, maar als aanvallers IdP-referenties/sessies onderscheppen, krijgen ze brede toegang.

Veelgestelde vragen over eenmalige aanmelding

Hier vindt u de antwoorden op de meestgestelde vragen over eenmalige aanmelding.

Wat is het verschil tussen SSO en AD?

Laten we de verschillen tussen single sign-on en Active Directory (AD) eens nader bekijken:

Aspect	Eenmalige aanmelding (SSO)	Actieve Directory (AD)
Definitie	Een authenticatiemethode waarmee gebruikers met één aanmelding toegang krijgen tot meerdere systemen via een gecentraliseerde identiteitsprovider.	Een directoryservice die door Microsoft is ontwikkeld om gebruikers, computers en beleidsregels binnen een Windows-domein op te slaan en te beheren.
Primaire functie	Federatieve authenticatie over meerdere apps en services, vaak over verschillende domeinen of platforms.	Beheert lokale netwerkidentiteiten, bronnen en beveiligingsbeleid in Windows-omgevingen.
strekking	Cross-platform en cloud-vriendelijk; werkt met webapps, SaaS en API's.	Voornamelijk on-premises en Windows-gericht, maar kan worden geïntegreerd met Azure AD voor cloud gebruikt.
Authenticatiemechanisme	Maakt gebruik van federatieprotocollen zoals SAML, OAuth 2.0 of OpenID Connect.	Gebruikt Kerberos en NTLM voor authenticatie binnen een Windows-domein.
Identiteitsopslag	Maakt gebruik van een externe identiteitsprovider (IdP) die gebruikers verifieert en tokens uitgeeft.	Slaat gebruikers- en computeraccounts op in een gecentraliseerde LDAP-gebaseerde directory.
Toegangsmodel	Biedt toegang tot meerdere onafhankelijke applicaties na één authenticatie.	Biedt toegang tot netwerkbronnen (bestandsshares, printers, domein diensten) binnen één organisatie.
User experience	Met één login krijgt u toegang tot vele cloud en webapplicaties naadloos.	Gebruikers melden zich aan bij hun domeinaccount om automatisch toegang te krijgen tot interne bronnen.
Implementatie	Kan worden geïmplementeerd met behulp van IdP's zoals Okta, Azure AD, Ping Identity of Google Workspace.	Wordt ingebouwd in Windows Server omgevingen als onderdeel van domeinbeheer.
Gebruik geval	Unificerende authenticatie voor cloud, SaaS en hybride omgevingen.	Centraliseer identiteits- en toegangscontrole voor Windows-bedrijfsnetwerken.
Verhouding	SSO kan AD gebruiken als identiteitsbron; AD kan fungeren als de backend-directory voor een SSO-oplossing.	AD ondersteunt SSO vaak door de gebruikersdirectory en Kerberos-tickets te leveren die worden gebruikt bij geïntegreerde authenticatie.

Is Single Sign-On veilig?

Ja, mits correct geïmplementeerd, is single sign-on zeer veilig omdat het sterke controles (MFA/wachtwoorden, voorwaardelijke toegang, apparaatstatuscontroles) centraliseert bij een geharde identiteitsprovider en kortdurende, ondertekende tokens uitgeeft die door elke app worden geverifieerd. De belangrijkste risico's komen voort uit de architectuur, en niet uit SSO zelf. Een uitval of verkeerde configuratie van de IdP kan veel apps treffen, en langdurende of zwak gevalideerde tokens verhogen het overnamerisico.

SSO moet ook worden gecombineerd met claims met de minste privileges, strikte tokenvalidatie (uitgever/doelgroep/nonce/vervaldatum), sleutelrotatie en kloksynchronisatie, continue monitoring met anomaliedetectie, step-up-authenticatie voor gevoelige acties en een veerkrachtige IdP-architectuur (redundantie, snelheidsbeperking, DDoS-beschermingDankzij deze veiligheidsmaatregelen is SSO doorgaans veiliger dan geïsoleerde aanmeldingen per app.

Is Single Sign-On de moeite waard?

Ja, single sign-on is over het algemeen de moeite waard voor de meeste organisaties, omdat het authenticatie vereenvoudigt en tegelijkertijd de beveiliging en productiviteit verbetert. Gecentraliseerde login vermindert wachtwoordmoeheid, beperkt hergebruik van inloggegevens en helpdesk-overhead door wachtwoordreset. Het maakt ook consistente handhaving van beleid zoals multi-factorauthenticatie en voorwaardelijke toegang mogelijk voor alle verbonden apps.

De initiële installatie en de afhankelijkheid van een betrouwbare identiteitsprovider zijn serieuze nadelen, maar de voordelen op de lange termijn. Een sterkere beveiligingspositie, snellere onboarding en offboarding, beter inzicht in compliance en een soepelere gebruikerservaring wegen meestal op tegen de complexiteit en kosten van de implementatie.