SAML vs OIDC

Vad är SAML?#

SAML (Security Assertion Markup Language) är en XML-baserad öppen standard för att utbyta autentiserings- och auktoriseringsdata mellan olika parter, särskilt mellan en identitetsleverantör (IdP) och en tjänsteleverantör (SP). Det möjliggör webbaserad SSO (Single Sign-On) som låter användare autentisera sig en gång för att få tillgång till flera applikationer. SAML är ett moget protokoll som har funnits länge och är allmänt använt av företag. Några av de mest populära SaaS-plattformarna som Salesforce, Workday och Microsoft Azure AD stöder alla SAML SSO.

SAML-komponenter#

1. Identitetsleverantör (IdP): Enheten som autentiserar användare och förser tjänsteleverantörer med identitetsinformation.
2. Tjänsteleverantör (SP): Enheten som erbjuder tjänster till användare och förlitar sig på identitetsleverantören för att autentisera användare.
3. SAML-utfästelser: XML-baserade dokument som bär användarens autentiserings- och auktoriseringsdetaljer. Inkluderar autentiseringsuttalanden, attribututtalanden och beslutsuttalanden om auktorisering.
4. SAML-protokoll: Definierar meddelandeformatet och reglerna för att utbyta SAML-utfästelser mellan IdP och SP.
5. SAML-bindningar: Definierar hur SAML-meddelanden transporteras över olika kommunikationsprotokoll som HTTP POST, HTTP Redirect osv.
6. SAML-metadata: XML-baserade dokument som innehåller konfigurationsinformationen för IdP och SP. Det inkluderar den offentliga nyckeln, slutpunkter, och stöds bindningar som används för att etablera tillit mellan IdP och SP.
7. Single sign-on-slutpunkt: Slutpunkten där SP omdirigerar användaren för att autentisera med IdP.
8. Assertion consumer service (ACS) URL: Slutpunkten där IdP skickar SAML-utfästelsen efter lyckad autentisering.

Hur fungerar SAML?#

1. SP-initierad SSO-flöde:

2. IdP-initierad SSO-flöde:

Fördelar med SAML#

• Mogen och allmänt använt: SAML är ett moget protokoll som har funnits länge och är allmänt använt av företag.
• Standardiserad: SAML är en öppen standard som underhålls av OASIS, vilket säkerställer interoperabilitet mellan olika leverantörer.
• SSO: SAML möjliggör webbaserad SSO som låter användare autentisera sig en gång för att få tillgång till flera applikationer.
• Centraliserad användarhantering: SAML låter organisationer hantera användaridentiteter centralt och verkställa säkerhetspolicys konsekvent.

Utmaningar med SAML#

• Komplexitet: SAML är ett komplext protokoll som kräver en djup förståelse för XML och säkerhetskoncept.
• Prestanda: SAML-meddelanden är XML-baserade och kan vara stora. XML-leverans och -analys kan vara långsammare jämfört med tokenformat som JSON Web Token (JWT).
• Föråldrad standard: SAML är en äldre standard jämfört med OIDC och anses vara mindre säker.
• Leverantörsinlåsning: SAML är ett leverantörsspecifikt protokoll och att byta mellan leverantörer kan vara utmanande.

Vad är OIDC?#

OIDC (OpenID Connect) är ett identitetslager byggt ovanpå OAuth 2.0 protokollet. Precis som SAML, används OIDC också för att utbyta autentiserings- och auktoriseringsdata mellan IdP och SP.

Jämfört med SAML, är OIDC ett mer modernt och lättviktigt protokoll som vinner popularitet för moderna webbaserade och mobila applikationer. OIDC använder JWT för att överföra identitetsinformation, vilket är mer kompakt och lättare att arbeta med jämfört med XML-baserade SAML-utfästelser. Det är särskilt populärt för konsumentinriktade applikationer och API-säkerhet.

OIDC-komponenter#

1. Identitetsleverantör (IdP): Enheten som autentiserar användare och förser tjänsteleverantörer med identitetsinformation.
2. Beroendeparti (RP): Enheten som erbjuder tjänster till användare och förlitar sig på identitetsleverantören för att autentisera användare. Exempelvis webbapplikationer, mobilappar eller API:er.
3. OIDC-token: Token som bär användarens identitetsinformation.
   • ID-token: JWT-format token som innehåller användarens identitetsinformation.
   • Access-token: JWT eller ogenomskinligt format token som beviljar tillgång till skyddade resurser.
   • Refresh-token: Token som används för att få en ny access-token utan att kräva att användaren autentiserar sig igen. Det ger en offline långlivad auktorisation till RP.
4. OIDC-slutpunkter: Slutpunkter som används för autentisering och tokenutbyte. Några av de viktigaste slutpunkterna är:
   • Discovery-slutpunkt: Där RP kan hämta den offentliga OIDC-konfigurationsinformationen från IdP.
   • Authorization slutpunkt: Där RP skickar autentiseringsbegäran.
   • Token endpoint: Där RP begär token från auktoriseringsservern.
   • Userinfo endpoint: Där RP kan hämta användarens profilinformation.
5. Scopes: OIDC definierar en uppsättning standardscopes som definierar de åtkomsträttigheter som beviljats RP. Såsom openid, profile, email, address osv.

Hur fungerar OIDC?#

OIDC erbjuder flera flöden som är uttryckligen utformade för olika användningsfall. Här är de två vanligaste OIDC-flödena:

1. Authorization code flow:

Authorization code flow är det vanligaste flödet som används i OIDC för konsumentinriktade applikationer.

2. Client credentials flow:

Client credentials flow kan användas för icke-användarbaserad (maskin-till-maskin) autentisering.

Fördelar med OIDC#

• Modern och lättviktig: OIDC är ett samtida protokoll som använder JSON-baserade JWT-token, vilket är mer kompakt och enklare att hantera jämfört med XML-baserade SAML-utfästelser.
• Konsumentinriktade applikationer: OIDC är särskilt populärt för konsumentinriktade applikationer och API-säkerhet.
• Interoperabilitet: Byggt ovanpå OAuth 2.0, är OIDC kompatibelt med olika plattformar, enheter och plattformar.
• Säkerhet: OIDC erbjuder en säkrare metod för användarautentisering och API-skydd. Det inkluderar olika moderna säkerhetsfunktioner såsom tokeninspektion, tokenåterkallelse, Proof Key for Code Exchange (PKCE), och stöder olika autentiseringsflöden anpassade till olika säkerhetsbehov.
• Lättanvänt: OIDC är enklare att implementera och arbeta med jämfört med SAML. Det är mer utvecklarvänligt och har omfattande bibliotek och SDK för flera programmeringsspråk och plattformar.

Utmaningar med OIDC#

• Tokenhantering: OIDC förlitar sig på tokens för autentisering och auktorisering. Det kräver rätt tokenhanteringsrutiner för att säkerställa säkerhet.
• Komplexitet: Även om OIDC är enkelt för grundläggande inställningar, kan det på grund av sin flexibla natur tillföra komplexitet när man implementerar avancerade anpassningar. T.ex. anpassade anspråk, och rollbaserad åtkomstkontroll (RBAC) osv.
• Antagande: OIDC är fortfarande relativt nytt jämfört med SAML, särskilt inom företagssektorn. Vissa äldre system kan fortfarande förlita sig på SAML för SSO-ändamål.

Jämförelse SAML vs OIDC#

Aspekt	SAML	OIDC
Tokenformat	XML-baserade SAML-utfästelser	JSON-baserade JWT-token
Primärt användningsfall	Företags-SSO, B2B-integrationer	Konsumentinriktade appar, API-säkerhet
Lättanvänt	Komplext, kräver djup förståelse för XML	Enkelt, JSON-baserat, lätt att implementera
Antagande	Allmänt använt av företag	Ökande popularitet för moderna appar
Säkerhet	Moget men anses mindre säkert	Modernt och mer säkert
Flexibilitet	Begränsat, utformat för SSO-användningsfall	Flexibelt, stöder olika användningsfall

Framtiden för SAML och OIDC#

Både SAML och OIDC används allmänt för autentiserings- och auktoriseringsändamål.

SAML förblir en hörnsten för företags-SSO och B2B-integrationer. Dess robusta stöd för federerad identitetshantering och beprövade meritlista säkerställer dess fortsatta relevans, särskilt för äldre system och storskaliga organisationer.

Å andra sidan fortsätter OIDC att utvecklas, drivet av efterfrågan på säker och skalbar autentisering i moderna applikationer. Dess lättviktiga natur och överensstämmelse med API:er och mikrotjänster gör det till en hörnsten för molninbyggda och distribuerade arkitekturer. Med ökningen av lösenordslös autentisering, biometriska funktioner och multifaktorsautentisering (MFA), förväntas OIDC integrera sömlöst med framväxande teknologier, vilket säkerställer dess relevans under de kommande åren.