SSO vs SAML uitgelegd voor iedereen

SSO en SAML worden vaak vaag gebruikt en kunnen op verschillende manieren worden geïnterpreteerd. In dit artikel verduidelijken we deze concepten, leggen we uit hoe ze zich tot elkaar verhouden en bieden we echte voorbeelden om ze gemakkelijker begrijpelijk te maken.

Wat is SSO?#

SSO (Single Sign-On) is een authenticatieproces dat een gebruiker in staat stelt om eenmaal in te loggen en toegang te krijgen tot meerdere applicaties of diensten zonder opnieuw in te hoeven loggen voor elk ervan. Deze algemene definitie kan echter worden toegepast op verschillende scenario's waarbij SSO wordt gebruikt.

Er zijn verschillende scenario's waarin SSO een rol speelt.

Sociale SSO#

Soms verwijzen mensen naar sociale login als sociale SSO. Bijvoorbeeld, gebruikers kunnen Google-login gebruiken om een account aan te maken in een nieuwe app, direct gebruikmakend van de identiteit en informatie die in Google is opgeslagen. In dit scenario beheert de gebruiker zijn eigen identiteit.

Sociale SSO maakt het voor gebruikers gemakkelijker om hun informatie te beheren, waardoor de vervelende stappen in het aanmaken van een account en inlogproces worden verminderd. Sociale SSO vertrouwt doorgaans op open standaardprotocollen zoals OAuth 2.0 en OIDC.

Enterprise SSO#

Laten we eerst de concepten van Identity Provider en Service Provider in eenvoudige bewoordingen uiteenzetten.

1. Identity Provider (IdP) is als de "poortwachter" van je identiteit. Het is het systeem dat je inloggegevens bewaart en verifieert wie je bent. Zie het als een vertrouwde autoriteit die zegt: "Ja, deze persoon is wie hij beweert te zijn." Voorbeelden zijn Google Workspace, Microsoft Entra en Okta Workforce Identity.
2. Service Provider (SP) is de "applicatie" of "dienst" waartoe je toegang wilt krijgen zodra je identiteit is geverifieerd. Het is de plaats waar je probeert in te loggen, zoals een app of website. Bijvoorbeeld, Zoom, Slack, of de interne tools van je bedrijf zijn allemaal serviceproviders.

In eenvoudige bewoordingen bewijst de Identity Provider wie je bent, en de Service Provider geeft je toegang tot zijn diensten zodra je identiteit is bevestigd.

Enterprise SSO wordt gebruikt in meer zakelijke scenario's en onderverdeeld door die twee hierboven uitgelegde termen, zijn er twee typische gevallen: IdP-geïnitieerde SSO en SP-geïnitieerde SSO. Hoewel de termen technisch kunnen klinken, zijn de scenario's eigenlijk vrij eenvoudig.

IdP-geïnitieerde SSO#

Denk aan wanneer je als werknemer kennismaakt met de applicaties en resources van je bedrijf. Meestal maakt HR een account voor je aan. Je gebruikt dat account dan om in te loggen op een platform zoals Okta of Google Workspace. Zodra je bent ingelogd, word je naar een bedrijfsportaal geleid, waar je toegang hebt tot alle applicaties van het bedrijf, zoals loonadministratie, samenwerkingstools, Workday en meer.

SP-geïnitieerde SSO#

Laten we de zaak eens van een andere kant bekijken. Soms moet je beginnen op de inlogpagina van een specifiek product. Bijvoorbeeld, als je Zoom wilt gebruiken voor een online vergadering met je collega's, zie je een optie om "In te loggen met SSO". Dit scenario staat bekend als SP-geïnitieerde SSO.

Welke problemen lost Enterprise SSO op?#

Het eerste voordeel van enterprise SSO is dat het bedrijven in staat stelt om de identiteit van werknemers gemakkelijk, flexibel en veilig te beheren.

Stel dat je een bedrijf runt en al je medewerkers toegang moeten hebben tot de producten en diensten die je hebt gekocht. Aangezien de middelen geproduceerd door het bedrijf eigendom zijn van het bedrijf, is er een bedrijfsidentiteitssysteem nodig. Als medewerkers persoonlijke identiteiten zouden gebruiken om toegang te krijgen tot bedrijfsbronnen, zou dat beveiligings- en beheersuitdagingen creëren.

Aan de andere kant, in een scenario zoals SP-geïnitieerde SSO, hebben medewerkers toegang tot meerdere applicaties en diensten die eigendom zijn van het bedrijf. Wanneer medewerkers in- of uit dienst treden, moet HR talloze accounts aanmaken en verwijderen over alle producten en diensten van het bedrijf, wat vervelend en tijdrovend is.

Enterprise SSO vereenvoudigt dit proces via een universeel identiteitssysteem, en tools zoals SCIM (System for Cross-domain Identity Management) en Just-in-Time provisioning maken het nog efficiënter.

Voor IdP-geïnitieerde SSO is het voordelig voor productontwikkelaars die "enterprise-ready" willen zijn. Bijvoorbeeld, als je een startup bent die aanvankelijk gericht is op individuele consumenten, en later wil een groot bedrijf je product gebruiken, kunnen ze vereisen dat werknemers inloggen met Microsoft Entra, bijvoorbeeld. In dit geval zou je enterprise SSO in je product moeten integreren om de deal te sluiten.

Wat is SAML?#

SAML (Security Assertion Markup Language) is een open standaardprotocol dat wordt gebruikt voor authenticatie en autorisatie. Samen met OAuth en OIDC wordt SAML veel gebruikt in identiteitsbeheersystemen, met name in workforce identity management. Commerciële identiteitproviders zoals Okta en Microsoft Entra ondersteunen SAML vaak als een van hun standaardprotocollen.

Sommige oudere systemen en aanbieders van sociale inlogmogelijkheden bieden ook SAML-ondersteuning, dus het hebben van SAML geïntegreerd in je systeem kan helpen om compatibiliteit te garanderen met een breder scala aan identiteitproviders en toekomstige ecosysteemgroei.

Wanneer is SAML nodig?#

SAML wordt vaak gebruikt in Enterprise SSO scenario's. Overweeg bijvoorbeeld deze situatie:

Je verkoopteam neemt contact op met de productontwikkelaars en zegt: "We hebben een grote klant en zij vereisen SAML-login. We moeten deze technologie ondersteunen."

Voor ingenieurs die niet bekend zijn met SAML of IAM (Identity and Access Management), zou hun eerste stap waarschijnlijk zijn om te zoeken naar "SAML" of "SAML-login."

Uiteindelijk is het doel om enterprise SSO in je product te integreren, waardoor het "enterprise-ready" wordt om tegemoet te komen aan de behoeften van grotere klanten die vertrouwen op technologieën zoals SAML voor veilige authenticatie.

Hoe werkt SAML?#

Hier is een vereenvoudigde uitsplitsing van de twee typen:

SP-geïnitieerde flow#

1. Gebruiker probeert toegang te krijgen tot de resource van de SP.
2. SP verwijst de gebruiker door naar de IdP met een SAML authenticatieverzoek.
3. Gebruiker logt in bij de IdP en wordt geverifieerd.
4. IdP genereert een SAML-assertion met de identiteit van de gebruiker en mogelijk autorisatiegegevens.
5. IdP stuurt de SAML-assertion terug naar de SP, meestal via de browser van de gebruiker.
6. SP verwerkt de assertion, valideert deze en verleent/ontzegt de gebruiker toegang.

IdP-geïnitieerde flow#

1. Gebruiker is al ingelogd bij de IdP en selecteert een dienst/resource vanuit het portaal van de IdP.
2. IdP genereert een SAML-assertion op basis van de huidige sessie van de gebruiker, met identiteit en attributen.
3. IdP stuurt de assertion direct naar de SP, zonder dat de SP vooraf om verzoek vraagt.
4. SP verwerkt de assertion, valideert de integriteit ervan en haalt de identiteit en attributen van de gebruiker eruit.
5. SP verleent of ontzegt toegang op basis van de assertion.

Om te zien hoe SAML technisch werkt, kijk op Hoe werkt SAML

Het verschil tussen SAML en SSO#

SAML en SSO-definities worden vaak door elkaar gehaald, maar hier is de eenvoudige uitsplitsing:

1. SSO is een authenticatieproces dat door apps en software wordt gebruikt, waardoor gebruikers eenmaal inloggen en toegang krijgen tot meerdere diensten.
2. SAML is een technisch protocol dat voornamelijk wordt gebruikt in enterprise identiteitsbeheer om authenticatiegegevens veilig uit te wisselen.

Stel je dit voor: Je komt 's ochtends je kantoor binnen en in plaats van dat je voor elke applicatie apart moet inloggen—je e-mail, agenda, projectmanagementtools—log je gewoon één keer in en hebt toegang tot alles. Deze naadloze ervaring is SSO (Single Sign-On). Het is als een universele sleutel die alle deuren naar je werkplatstools opent.

Maar hoe werkt SSO?

Dit is waar SAML (Security Assertion Markup Language) een rol speelt. Denk aan SAML als een vertrouwde boodschapper tussen je inlogsysteem (de Identity Provider of IdP) en de apps die je wilt gebruiken (de Service Providers of SP's). Wanneer je inlogt via SSO, stuurt SAML veilig een "bewijs" van je identiteit van de IdP naar de app, om te bevestigen dat je bent wie je zegt te zijn.

Dus, kort samengevat:

1. SSO is de gebruikerservaring: één login om toegang te krijgen tot meerdere apps.
2. SAML is het achter-de-schermen-protocol dat die naadloze ervaring mogelijk maakt door veilige identiteitsverificatie te verzorgen.

Hoewel SSO het gemak verhoogt, zorgt SAML ervoor dat alles veilig en verbonden blijft, zodat je overal toegang tot hebt zonder erbij na te hoeven denken.

Gebruikt Enterprise SSO andere protocollen?#

Ja, naast SAML wordt OIDC ook vaak gebruikt in Enterprise SSO-scenario's. Bijvoorbeeld, in de enterprise connector van Logto, ondersteunt het zowel Microsoft Entra (OIDC) als Microsoft Entra (SAML).

Moet ik SAML SSO gebruiken?#

Als je verkoopt aan zakelijke klanten, is het belangrijk om zo vroeg mogelijk ondersteuning voor SAML te overwegen. Maar focus niet alleen op het ondersteunen van het SAML-protocol—denk na over de hele enterprise SSO-authenticatieflow. Hier zijn een paar belangrijke scenario's om te overwegen:

1. Laat je klanten zichzelf onboarden en enterprise SSO instellen.
2. Zorg ervoor dat medewerkers automatisch bij de juiste organisaties kunnen aansluiten in multi-tenant applicaties (dit kan gedaan worden met Just-in-Time provisioning en SCIM).
3. Implementeer een end-to-end inlogflow die compatibel is met je consumentgerichte inlogproces.

Implementeer SAML en Enterprise SSO met Logto#

Logto biedt end-to-end enterprise SSO-flows en ondersteunt meerdere bekende SAML-connectors. Het kan geïntegreerd worden in veelvoorkomende scenario's die je nodig zult hebben. Ontdek alle functies van Logto, van Logto Cloud tot Logto OSS, op de Logto-website.