Begrijp IAM, OAuth, OpenID Connect, SAML, SSO en JWT in één artikel

Het domein van identity- en access management (IAM) is de afgelopen jaren ingewikkelder geworden. De dure woorden als OAuth, OpenID Connect (OIDC), SAML, SSO en JWT worden vaak gebruikt, maar wat betekenen ze? Hoe werken ze samen? Laten we deze concepten en frameworks verkennen om ze begrijpelijker en praktischer te maken.

Wat is IAM?#

Identity- en access management (IAM) is een breed concept dat het beheren van digitale identiteiten en het implementeren van toegangscontrole omvat. De eerder genoemde frameworks en protocollen vallen binnen IAM, elk met specifieke uitdagingen in dit gebied.

In essentie gaat IAM over:

• Identiteit: Een digitale representatie van een gebruiker, dienst of apparaat. Een identiteit omvat meestal attributen zoals naam, e-mail, rollen, enz., om de entiteit te beschrijven.
• Toegang: Het vermogen om met bronnen te interageren, acties uit te voeren of diensten te gebruiken. Toegang definieert welke acties op welke bronnen kunnen worden uitgevoerd.

In het diagram hierboven wil een gebruiker (identiteit) een GET-verzoek uitvoeren op een API (bron). De kenmerken van de gebruiker - naam, e-mail en rol - beschrijven de identiteit.

Authenticatie vs. autorisatie#

Authenticatie en autorisatie komen vaak samen voor in IAM-discussies. Laten we hun definities verduidelijken:

• Authenticatie: Het proces van het verifiëren van het eigendom van een identiteit. Het beantwoordt de vraag: "Welke identiteit bezit je?"
• Autorisatie: Het proces van het bepalen welke acties een geauthenticeerde identiteit kan uitvoeren op een bron. Het beantwoordt de vraag: “Wat kun je doen?”

In het eerdere voorbeeld:

• Voordat de gebruiker (identiteit) enige acties kan uitvoeren, moet hij of zij het authenticatie-proces voltooien.
• Na authenticatie moet het systeem bepalen of de gebruiker een GET-verzoek (actie) op de API (bron) kan uitvoeren, d.w.z. het autorisatie-proces voltooien.

---

Gewapend met deze basiskennis, laten we de andere acroniemen en protocollen ontcijferen.

OAuth#

OAuth 2.0, vaak simpelweg OAuth genoemd, is een autorisatie-framework dat een applicatie in staat stelt toegang te krijgen tot beschermde bronnen op een andere applicatie (meestal namens een gebruiker).

Stel je voor dat je een webapplicatie hebt genaamd MyApp die toegang wil tot de Google Drive van een gebruiker. In plaats van de gebruiker te vragen zijn Google Drive-inloggegevens te delen, kan MyApp OAuth 2.0 gebruiken om toestemming (autorisatie) van Google te vragen om toegang te krijgen tot de Drive van de gebruiker.

Hier is een vereenvoudigd diagram dat de OAuth-flow illustreert:

In deze flow:

• MyApp is de client (identiteit) die toegang vraagt tot Google Drive (bron).
• De gebruiker (bronhouder) verleent MyApp toestemming in stap 6, waarmee het autorisatie-proces voltooid wordt.

Een sleutelbegrip in OAuth 2.0 is het toegangstoken, dat de client gebruikt om de autorisatie van de gebruiker te demonstreren bij het openen van bronnen. Voor diepere inzichten, zie toegangstoken.

OpenID Connect (OIDC)#

OpenID Connect (OIDC) is een authenticatielaag gebouwd bovenop OAuth 2.0. Het voegt functies toe die specifiek zijn voor authenticatie, zoals ID-tokens en een UserInfo-eindpunt, waardoor het geschikt is voor zowel authenticatie als autorisatie.

Als we de OAuth-flow opnieuw bekijken, introduceert OIDC een ID-token. Dit token bevat informatie over de geauthenticeerde gebruiker en stelt MyApp in staat om de identiteit van de gebruiker te verifiëren.

Voorbeeldscenario: "Log in met Google"#

Laten we een ander voorbeeld bekijken. Als MyApp gebruikers wil toestaan in te loggen met hun Google-accounts, verschuift het doel naar authenticatie in plaats van bronacces. In dit geval is OIDC beter geschikt. Zo ziet de OIDC-flow eruit:

Belangrijk verschil: Naast een toegangstoken voorziet OIDC in een ID-token, waarmee MyApp de gebruiker kan authentiseren zonder extra verzoeken in te dienen.

OIDC deelt OAuth 2.0's grant definities, wat compatibiliteit en consistentie tussen de twee frameworks verzekert.

SAML#

Security Assertion Markup Language (SAML) is een XML-gebaseerd framework voor het uitwisselen van authenticatie- en autorisatiegegevens tussen partijen. SAML, geïntroduceerd in het begin van de jaren 2000, is breed aangenomen in bedrijfsomgevingen.

Hoe vergelijkt SAML zich met OIDC?#

SAML en OIDC zijn functioneel vergelijkbaar maar verschillen in hun implementatiedetails:

• SAML: Gebruikt XML-gebaseerde assertions en wordt vaak als complexer beschouwd.
• OIDC: Maakt gebruik van JSON en JWT, waardoor het lichter en gebruiksvriendelijker is voor ontwikkelaars.

Moderne applicaties geven vaak de voorkeur aan OIDC vanwege de eenvoud en flexibiliteit, maar SAML blijft veelvoorkomend in legacy systemen en bedrijfsgebruik.

Single sign-on (SSO)#

Single sign-on (SSO) is een authenticatieschema dat gebruikers in staat stelt meerdere applicaties en diensten te openen met één set inloggegevens. In plaats van afzonderlijk in te loggen bij elke applicatie, logt de gebruiker eenmalig in en krijgt toegang tot alle gekoppelde systemen.

Hoe werkt SSO?#

SSO vertrouwt op een centrale identity provider (IdP) om gebruikersidentiteiten te beheren. De IdP authenticiseert de gebruiker en biedt diensten zoals authenticatie en autorisatie aan gekoppelde applicaties.

De IdP kan protocollen zoals OIDC, OAuth 2.0, SAML of andere gebruiken om deze diensten te bieden. Een enkele IdP kan meerdere protocollen ondersteunen om aan de verschillende behoeften van verschillende applicaties te voldoen.

Voorbeeld van OIDC-gebaseerde SSO#

Laten we een voorbeeld van OIDC-gebaseerde SSO verkennen:

In deze flow logt de gebruiker eenmalig in op de IdP en wordt geauthenticeerd bij meerdere applicaties (AppA en AppB).

Enterprise SSO#

Hoewel SSO een breed concept is, kom je ook de term enterprise SSO tegen, die verwijst naar een specifiek type SSO ontworpen voor bedrijfsomgevingen (meestal voor werknemers en partners).

Wanneer een klant SSO voor je applicatie aanvraagt, is het belangrijk om hun behoeften en de protocollen die ze gebruiken te verduidelijken. Meestal betekent dit dat voor specifieke e-maildomeinen je wil dat je applicatie gebruikers doorverwijst naar hun IdP (die enterprise SSO implementeert) voor authenticatie.

Voorbeeld: Een enterprise SSO-provider toevoegen#

Hier is een vereenvoudigd voorbeeld van het integreren van een enterprise SSO-provider (Banana) met je applicatie (MyApp):

JWT#

JSON Web Token (JWT) is een open standaard gedefinieerd in RFC 7519 die veilige communicatie tussen twee partijen mogelijk maakt. Het is het standaardformaat voor ID-tokens in OIDC en wordt veel gebruikt voor OAuth 2.0 toegangstokens.

Hier zijn de belangrijkste kenmerken van JWT:

• Compact: JWT's zijn JSON-objecten die gecodeerd zijn in een compact formaat, waardoor ze gemakkelijk over te dragen en op te slaan zijn.
• Zelfstandige: JWT's bevatten alle noodzakelijke informatie over de gebruiker en het token zelf.
• Verifieerbaar en versleutelbaar: JWT's kunnen ondertekend en versleuteld worden om gegevensintegriteit en vertrouwelijkheid te verzekeren.

Een typisch JWT ziet er als volgt uit:

Dit JWT bestaat uit drie delen gescheiden door punten:

• Header: Bevat metadata over het token, zoals het type token en het ondertekeningsalgoritme.
• Payload: Bevat informatie over de identiteit en het token zelf.
• Signature: Verifieert de integriteit van het token.

Zowel de header als de payload zijn base64-gecodeerde JSON-objecten. Het bovenstaande JWT kan als volgt worden gedecodeerd:

Met JWT kan de client het token decoderen en de gebruikersinformatie extraheren zonder aanvullende verzoeken aan de identiteitprovider in te dienen. Om meer te leren over JWT, bezoek JSON Web Token (JWT).

Samenvatting#

We hebben veel terrein behandeld in dit artikel. Laten we de belangrijkste punten samenvatten met een voorbeeld:

Stel je voor dat je een webapplicatie hebt, AppA, die een identity- en access management (IAM)-oplossing vereist. Je kiest Logto, een identity provider die OpenID Connect (OIDC) gebruikt voor authenticatie. Omdat OIDC gebouwd is bovenop OAuth 2.0, ondersteunt Logto ook autorisatie voor je applicatie.

Om wrijving voor je gebruikers te verminderen, stel je "Log in met Google" in binnen Logto. Dit gebruikt OAuth 2.0 om autorisatiegegevens en gebruikersinformatie uit te wisselen tussen Logto en Google.

Nadat de gebruiker inlogt op AppA via Logto, ontvangt AppA een ID-token, wat een JSON Web Token (JWT) is dat informatie over de gebruiker bevat.

Naarmate je bedrijf groeit, lanceer je een nieuwe applicatie, AppB, die ook gebruikersauthenticatie nodig heeft. Aangezien Logto al is ingesteld, kun je dezelfde authenticatiestroom hergebruiken voor AppB. Je gebruikers kunnen nu inloggen op zowel AppA als AppB met één set inloggegevens, een functie die bekend staat als single sign-on (SSO).

Later vraagt een zakenpartner je om hun enterprise SSO-systeem te koppelen, dat Security Assertion Markup Language (SAML) gebruikt. Je ontdekt dat Logto SAML-verbindingen ondersteunt, dus stel je een verbinding in tussen Logto en het SSO-systeem van de partner. Nu kunnen gebruikers van de organisatie van de partner ook inloggen op AppA en AppB met hun bestaande inloggegevens.

---

Ik hoop dat dit artikel deze concepten voor jou heeft verduidelijkt. Voor meer diepgaande uitleg en voorbeelden, bekijk Auth Wiki. Als je op zoek bent naar een IAM-oplossing voor je applicatie, overweeg dan een beheerde dienst zoals Logto te gebruiken om tijd en moeite te besparen.