Förstå IAM, OAuth, OpenID Connect, SAML, SSO och JWT i en artikel

Domänen för identitets- och åtkomsthantering (IAM) har blivit mer komplicerad under de senaste åren. De komplicerade termerna som OAuth, OpenID Connect (OIDC), SAML, SSO och JWT används ofta, men vad betyder de? Hur fungerar de tillsammans? Låt oss utforska dessa koncept och ramverk för att göra dem mer begripliga och praktiska.

Vad är IAM?#

Identitets- och åtkomsthantering (IAM) är ett brett koncept som innefattar hantering av digitala identiteter och implementering av åtkomstkontroll. De tidigare nämnda ramverken och protokollen faller under IAM, var och en som adresserar specifika utmaningar inom detta område.

I huvudsak handlar IAM om:

• Identitet: En digital representation av en användare, tjänst eller enhet. En identitet inkluderar vanligtvis attribut som namn, e-post, roller, etc., för att beskriva enheten.
• Åtkomst: Möjligheten att interagera med resurser, utföra handlingar eller använda tjänster. Åtkomst definierar vilka handlingar som kan utföras på vilka resurser.

I diagrammet ovan vill en användare (identitet) utföra en GET-begäran på ett API (resurs). Användarens attribut - namn, e-post och roll - beskriver identiteten.

Autentisering vs. auktorisering#

Autentisering och auktorisering dyker ofta upp tillsammans i IAM-diskussioner. Låt oss klargöra deras definitioner:

• Autentisering: Processen att verifiera äganderättigheten till en identitet. Den svarar på frågan, "Vilken identitet äger du?"
• Auktorisering: Processen att avgöra vilka handlingar en autentiserad identitet kan utföra på en resurs. Den svarar på frågan, ”Vad kan du göra?”

I det tidigare exemplet:

• Innan användaren (identiteten) kan utföra några handlingar, måste de slutföra autentiseringsprocessen.
• Efter autentisering behöver systemet avgöra om användaren kan utföra en GET-begäran (åtgärd) på API:t (resurs), det vill säga slutföra auktoriseringsprocessen.

---

Utrustad med denna grundläggande kunskap, låt oss avmystifiera de andra förkortningarna och protokollen.

OAuth#

OAuth 2.0, ofta kallad OAuth, är ett auktoriseringsramverk som möjliggör att en applikation får åtkomst till skyddade resurser på en annan applikation (vanligtvis på uppdrag av en användare).

Till exempel, föreställ dig att du har en webbapplikation som heter MyApp som vill ha åtkomst till en användares Google Drive. Istället för att be användaren att dela sina Google Drive-uppgifter kan MyApp använda OAuth 2.0 för att begära tillstånd (auktorisering) från Google att få åtkomst till användarens Drive.

Här är ett förenklat diagram som illustrerar OAuth-flödet:

I detta flöde:

• MyApp är klienten (identiteten) som begär åtkomst till Google Drive (resurs).
• Användaren (resursägaren) ger MyApp tillstånd i steg 6, vilket slutför auktoriseringsprocessen.

En nyckelkomponent i OAuth 2.0 är åtkomsttoken, som klienten använder för att visa användarens auktorisering att komma åt resurser. För att fördjupa dig, se Åtkomsttoken.

OpenID Connect (OIDC)#

OpenID Connect (OIDC) är ett autentiseringslager byggt ovanpå OAuth 2.0. Det lägger till funktioner specifikt för autentisering, såsom ID tokens och en UserInfo-endpunkt, vilket gör det lämpligt för både autentisering och auktorisering.

Om vi återvänder till OAuth-flödet, införandet av OIDC introducerar en ID-token. Denna token innehåller information om den autentiserade användaren och möjliggör för MyApp att verifiera användarens identitet.

Exempelscenario: "Logga in med Google"#

Låt oss byta exempel. Om MyApp vill låta användare logga in med sina Google-konton, förändras målet till autentisering snarare än resursåtkomst. I detta fall är OIDC en bättre lösning. Så här ser OIDC-flödet ut:

Viktig skillnad: Förutom en åtkomsttoken tillhandahåller OIDC en ID-token, vilket gör det möjligt för MyApp att autentisera användaren utan att kräva ytterligare förfrågningar.

OIDC delar OAuth 2.0:s grant definitioner, vilket säkerställer kompatibilitet och konsekvens mellan de två ramverken.

SAML#

Security Assertion Markup Language (SAML) är ett XML-baserat ramverk för att utbyta autentiserings- och auktoriseringsdata mellan parter. SAML, som introducerades i början av 2000-talet, har blivit allmänt använt i företagsmiljöer.

Hur jämförs SAML med OIDC?#

SAML och OIDC är funktionellt lika men skiljer sig åt i sina implementeringsdetaljer:

• SAML: Använder XML-baserade påståenden och anses ofta vara mer komplexa.
• OIDC: Utnyttjar JSON och JWT, vilket gör det lättare och mer utvecklarvänligt.

Moderna applikationer föredrar ofta OIDC för dess enkelhet och flexibilitet, men SAML är fortfarande vanligt i äldre system och företagsanvändningsfall.

Single sign-on (SSO)#

Single sign-on (SSO) är ett autentiseringssystem som möjliggör för användare att få tillgång till flera applikationer och tjänster med en enda uppsättning uppgifter. Istället för att logga in till varje applikation individuellt, loggar användaren in en gång och får tillgång till alla anslutna system.

Hur fungerar SSO?#

SSO förlitar sig på en central identitetsleverantör (IdP) för att hantera användaridentiteter. IdP:n autentiserar användaren och tillhandahåller tjänster som autentisering och auktorisering till anslutna applikationer.

IdP:n kan använda protokoll som OIDC, OAuth 2.0, SAML eller andra för att tillhandahålla dessa tjänster. En enda IdP kan stödja flera protokoll för att möta de olika behoven hos olika applikationer.

Exempel på OIDC-baserad SSO#

Låt oss utforska ett exempel på OIDC-baserad SSO:

I detta flöde loggar användaren in till IdP en gång och autentiseras över flera applikationer (AppA och AppB).

Företags-SSO#

Medan SSO är ett brett koncept, kan du också stöta på termen företags-SSO, vilket hänvisar till en specifik typ av SSO utformad för företagsmiljöer (vanligtvis för anställda och partners).

När en kund begär SSO för din applikation, är det viktigt att klargöra deras behov och de protokoll de använder. I de flesta fall betyder det att för specifika e-postdomäner, vill de att din applikation ska omdirigera användare till deras IdP (som implementerar företags-SSO) för autentisering.

Exempel: Lägg till en företags-SSO-leverantör#

Här är ett förenklat exempel på att integrera en företags-SSO-leverantör (Banana) med din applikation (MyApp):

JWT#

JSON Web Token (JWT) är en öppen standard definierad i RFC 7519 som möjliggör säker kommunikation mellan två parter. Det är standardformatet för ID-tokens i OIDC och används flitigt för OAuth 2.0-åtkomsttokens.

Här är de viktigaste egenskaperna hos JWT:

• Kompakt: JWT:er är JSON-objekt kodade i ett kompakt format, vilket gör dem lätta att överföra och lagra.
• Självbärande: JWT:er innehåller all nödvändig information om användaren och token i sig.
• Verifierbara och krypterbara: JWT:er kan signeras och krypteras för att säkerställa dataintegritet och konfidentialitet.

En typisk JWT ser ut så här:

Denna JWT består av tre delar separerade med punkter:

• Header: Innehåller metadata om token, som typen av token och signeringsalgoritm.
• Payload: Innehåller information om identiteten och token i sig.
• Signature: Verifierar tokenens integritet.

Både header och payload är base64-kodade JSON-objekt. JWT ovan kan avkodas enligt följande:

Med hjälp av JWT kan klienten avkoda token och extrahera användarens information utan att göra ytterligare förfrågningar till identitetsleverantören. För att lära dig mer om JWT, besök JSON Web Token (JWT).

Sammanfattning#

Vi har täckt mycket i denna artikel. Låt oss sammanfatta huvudpunkterna med ett exempel:

Föreställ dig att du har en webbapplikation, AppA, som kräver en lösning för identitets- och åtkomsthantering (IAM). Du väljer Logto, en identitetsleverantör som använder OpenID Connect (OIDC) för autentisering. Eftersom OIDC bygger på OAuth 2.0, stöder Logto även auktorisering för din applikation.

För att minska friktionen för dina användare, aktiverar du "Logga in med Google" i Logto. Detta använder OAuth 2.0 för att utbyta auktoriseringsdata och användarinformation mellan Logto och Google.

Efter att användaren loggat in i AppA via Logto, får AppA en ID-token, vilket är en JSON Web Token (JWT) som innehåller användarens information.

När ditt företag växer lanserar du en ny applikation, AppB, som också behöver användarautentisering. Eftersom Logto redan är uppsatt, kan du återanvända samma autentiseringsflöde för AppB. Dina användare kan nu logga in i både AppA och AppB med en enda uppsättning uppgifter, en funktion som kallas single sign-on (SSO).

Senare frågar en affärspartner dig om att ansluta deras företags-SSO-system, som använder Security Assertion Markup Language (SAML). Du upptäcker att Logto stöder SAML-anslutningar, så du sätter upp en anslutning mellan Logto och partnerns SSO-system. Nu kan användare från partnerns organisation också logga in i AppA och AppB med sina befintliga uppgifter.

---

Jag hoppas att denna artikel har klargjort dessa koncept för dig. För mer detaljerade förklaringar och exempel, kolla in Auth Wiki. Om du letar efter en IAM-lösning för din applikation, överväg att använda en hanterad tjänst som Logto för att spara tid och ansträngning.