SSO vs SAML, förklarat för alla

SSO, SAML används ofta vagt och kan tolkas på olika sätt. I den här artikeln kommer vi att klargöra dessa koncept, förklara hur de relaterar till varandra och ge riktiga exempel för att göra dem lättare att förstå.

Vad är SSO?#

SSO (Single Sign-On) är en autentiseringsprocess som låter en användare logga in en gång och komma åt flera applikationer eller tjänster utan att behöva logga in igen för varje. Denna allmänna definition kan dock gälla för olika scenarier när SSO används.

Det finns olika scenarier där SSO kommer i spel.

Social SSO#

Ibland hänvisar folk till social inloggning som social SSO. Till exempel kan användare använda Google-inloggning för att skapa ett konto i en ny app, direkt använda den identitet och information som lagras i Google. I detta scenario hanterar användaren sin egen identitet.

Social SSO gör det lättare för användare att kontrollera sin information och minskar de tråkiga stegen i kontoskapande och inloggningsprocessen. Social SSO förlitar sig vanligtvis på öppna standardprotokoll som OAuth 2.0 and OIDC.

Företags-SSO#

Först, låt oss bryta ner koncepten av Identity Provider och Service Provider i enkla termer.

1. Identity Provider (IdP) är som "grindvakten" till din identitet. Det är systemet som förvarar din inloggningsinformation och verifierar vem du är. Tänk på det som en betrodd myndighet som säger, "Ja, den här personen är den de påstår sig vara." Exempel inkluderar Google Workspace, Microsoft Entra och Okta Workforce Identity.
2. Service Provider (SP) är "applikationen" eller "tjänsten" du vill komma åt när din identitet är verifierad. Det är platsen där du försöker logga in, som en app eller en webbplats. Till exempel, Zoom, Slack, eller ditt företags interna verktyg är alla tjänsteleverantörer.

På enkla termer bevisar Identity Provider vem du är, och Service Provider ger dig åtkomst till sina tjänster när din identitet är bekräftad.

Företags-SSO används i mer affärsinriktade scenarier och uppdelat i dessa två termer som förklarades ovan, finns det två typiska fall: IdP-initierad SSO och SP-initierad SSO. Även om termerna kan låta tekniska är scenarierna faktiskt ganska enkla.

IdP-initierad SSO#

Tänk på när du, som anställd, introduceras till ditt företags applikationer och resurser. Vanligtvis skapar HR ett konto för dig. Du använder sedan det kontot för att logga in på en plattform som Okta eller Google Workspace. När du är inloggad kommer du att ledas till en företags portal, där du kan komma åt alla företagets applikationer, såsom lönesystem, samarbetsverktyg, Workday och mer.

SP-initierad SSO#

Låt oss växla perspektiv och titta på det från ett annat perspektiv. Ibland behöver du börja på en specifik produkts inloggningssida. Till exempel, om du vill använda Zoom för ett online möte med dina kollegor, kommer du att se ett alternativ att "Logga in med SSO." Detta scenario är känt som SP-initierad SSO.

Vilka problem löser företags-SSO#

Den första fördelen med företags-SSO är att det gör det möjligt för företag att hantera arbetskraftens identiteter enkelt, flexibelt och säkert.

Säg att du driver ett företag, och alla dina anställda behöver åtkomst till de produkter och tjänster som du har köpt. Eftersom de resurser som produceras av företaget tillhör företaget behövs ett företagssägt identitetssystem. Om anställda skulle använda personliga identiteter för att komma åt företagets resurser skulle det skapa säkerhets- och förvaltningsmässiga utmaningar.

Å andra sidan, i ett scenario som SP-initierad SSO, har anställda åtkomst till flera applikationer och tjänster som tillhör företaget. När anställda introduceras eller slutar, måste HR skapa och radera många konton över alla företagets produkter och tjänster, vilket är tråkigt och tidskrävande.

Företags-SSO förenklar denna process genom ett universellt identitetssystem, och verktyg som SCIM (System for Cross-domain Identity Management) och Just-in-Time provisioning gör det ännu mer effektivt.

För IdP-initierad SSO är det fördelaktigt för produktutvecklare som vill vara "företagsredo". Till exempel, om du är ett startup som initialt fokuserar på individuella konsumenter, och senare ett stort företag vill använda din produkt, kan de kräva att anställda loggar in med till exempel Microsoft Entra. I detta fall skulle du behöva integrera företags-SSO i din produkt för att slutföra affären.

Vad är SAML?#

SAML (Security Assertion Markup Language) är ett öppet standardprotokoll som används för autentisering och auktorisation. Tillsammans med OAuth och OIDC används SAML ofta i identitetshanteringssystem, särskilt i arbetskraftens identitetshantering. Kommersiella identitetsleverantörer som Okta och Microsoft Entra stöder vanligtvis SAML som ett av sina standardprotokoll.

Vissa äldre system och sociala inloggningsleverantörer erbjuder också SAML-stöd, så att ha SAML inbyggt i ditt system kan hjälpa till att säkerställa kompatibilitet med en bredare mängd identitetsleverantörer och framtida ekosystemutveckling.

När behövs SAML?#

SAML används ofta i Enterprise SSO scenarier. Till exempel, överväg denna situation:

Ditt försäljningsteam kontaktar produktutvecklarna och säger, "Vi har en stor kund, och de kräver SAML-inloggning. Vi behöver stödja denna teknik."

För ingenjörer som inte är bekanta med SAML eller IAM (Identity and Access Management), skulle deras första steg troligen vara att söka efter "SAML" eller "SAML-inloggning."

Slutligen är målet att integrera företags-SSO i din produkt, vilket gör den "företagsredo" för att möta behoven hos större kunder som förlitar sig på teknologier som SAML för säker autentisering.

Hur fungerar SAML#

Här är en förenklad förklaring av de två typerna:

SP-initierat flöde#

1. Användaren försöker komma åt SP:s resurs.
2. SP omdirigerar användaren till IdP med en SAML autentiseringsförfrågan.
3. Användaren loggar in på IdP och autentiseras.
4. IdP genererar ett SAML-uttalande med användarens identitet och eventuellt auktorisationsdata.
5. IdP skickar tillbaka SAML-uttalandet till SP, normalt via användarens webbläsare.
6. SP bearbetar uttalandet, validerar det och beviljar/nekar användaren åtkomst.

IdP-initierat flöde#

1. Användaren är redan inloggad på IdP och väljer en tjänst/resurs från IdP:s portal.
2. IdP genererar ett SAML-uttalande baserat på användarens nuvarande session, innehållande identitet och attribut.
3. IdP skickar uttalandet direkt till SP, utan SP:s tidigare begäran.
4. SP bearbetar uttalandet, validerar dess integritet och extraherar användarens identitet och attribut.
5. SP beviljar eller nekar åtkomst baserat på uttalandet.

För att se hur SAML fungerar från ett tekniskt perspektiv, kolla in Hur fungerar SAML

Skillnaden mellan SAML och SSO#

SAML- och SSO-definitioner blandas ofta ihop, men här är en enkel sammanställning:

1. SSO är en autentiseringsprocess som används av appar och mjukvara, vilket låter användare logga in en gång och få åtkomst till flera tjänster.
2. SAML är ett tekniskt protokoll som främst används i företags identitetshantering för att säkert utbyta autentiseringsdata.

Föreställ dig detta: Du går in på ditt kontor på morgonen, och istället för att behöva logga in på varje applikation separat—ditt e-post, din kalender, dina projektledningsverktyg—loggar du bara in en gång och har åtkomst till allt. Denna sömlösa upplevelse är SSO (Single Sign-On). Det är som att ha en universell nyckel som öppnar alla dörrar till dina arbetsverktyg.

Men hur fungerar SSO?

Det är här SAML (Security Assertion Markup Language) kommer in. Tänk på SAML som en pålitlig budbärare mellan ditt inloggningssystem (kallat Identity Provider, eller IdP) och de appar du vill använda (kallade Service Providers, eller SPs). När du loggar in genom SSO skickar SAML säkert ett "bevis" på din identitet från IdP till appen och bekräftar att du är den du säger att du är.

Så, kort sagt:

1. SSO är användarupplevelsen: en inloggning för att komma åt flera appar.
2. SAML är protokollet bakom kulisserna som gör den sömlösa upplevelsen möjlig genom att säkert hantera identitetsverifiering.

Medan SSO förbättrar bekvämligheten, säkerställer SAML att allt förblir säkert och sammankopplat, vilket gör att du kan komma åt allt utan att tänka två gånger.

Använder företags-SSO andra protokoll?#

Ja, förutom SAML, är OIDC ett annat protokoll som vanligtvis används i företags-SSO-scenarier. Till exempel, i Logtos företagsanslutare, stöder den både Microsoft Entra (OIDC) och Microsoft Entra (SAML).

Bör jag använda SAML SSO?#

Om du säljer till företagskunder är det viktigt att överväga att stödja SAML så tidigt som möjligt. Men fokusera inte bara på att stödja SAML-protokollet—tänk på hela företags-SSO-autentiseringsflödet. Här är några nyckelscenarier att överväga:

1. Tillåt dina kunder att självintroducera och ställa in företags-SSO.
2. Säkerställ att anställda automatiskt kan gå med i rätt organisationer i multi-tenant applikationer (detta kan göras med Just-in-Time provisioning och SCIM).
3. Implementera ett end-to-end-inloggningsflöde som är kompatibelt med din konsumentorienterade inloggningsprocess.

Implementera SAML och företags-SSO med Logto#

Logto ger end-to-end företags-SSO-flöden och stöder flera kända SAML-anslutare. Det kan integreras i många vanliga scenarier och du kommer att behöva. Utforska alla Logtos funktioner, från Logto Cloud till Logto OSS, på Logto-webbplatsen.