Identiteitsbeheer: SAML vs. OAuth2 vs. OpenID Connect
Het begon allemaal met organisaties die een manier nodig hadden om hun authenticatie systemen te centraliseren voor beter beheer en beveiliging. Dat is waar Single Sign On (SSO) zijn intrede deed. Single sign-on (SSO) is een gecentraliseerde sessie- en gebruikersauthenticatiedienst waarbij één set inloggegevens kan worden gebruikt om toegang te krijgen tot meerdere applicaties. De schoonheid zit hem in de eenvoud; de dienst authenticeert je op één platform, waardoor je transparant kunt inloggen op meerdere interne diensten zonder telkens in en uit te hoeven loggen.
Daarna kwamen externe app-ontwikkelaars die interne API’s wilden gebruiken om het met hun producten en oplossingen te integreren, dit was duidelijk een uitdaging. Daarna kwamen de sociale netwerken en die maakten het nog ingewikkelder, we hebben momenteel duizenden apps die authenticatie ondersteunen via sociale netwerken zoals Facebook, Google, Twitter, LinkedIn, enz. Het probleem in deze architecturen is de uitdaging om de zaken zo eenvoudig mogelijk te houden en tegelijkertijd de beveiliging te verhogen. De oplossing? Federated Identities.
De drie belangrijkste protocollen voor federated identity zijn op dit moment: SAML, OAuth2 & OpenID Connect. Voordat we diep in deze drie protocollen duiken, laten we een aantal veel voorkomende concepten bespreken die mensen verwarren.
Authenticatie & als het gaat om beveiliging en toegang, zijn twee termen die mensen over het hoofd zien en die vaak ten onrechte hetzelfde betekenen. Welnu, authenticatie is het verifiëren van je identiteit, terwijl autorisatie is het verifiëren waartoe je toegang hebt.
Authenticatie is het valideren van de inloggegevens voordat de gebruiker toegang krijgt tot het systeem. Als het om beveiliging gaat, is het aan te bevelen om ten minste twee authenticatiefactoren te gebruiken voordat je een gebruiker toegang tot iets geeft. (2FA, MFA, digitale & fysieke tokens, etc.).
Authorisatie vindt plaats na het authenticatieproces door uw rechten te verifiëren voordat u toegang krijgt tot de vereiste bronnen, zoals databases, bestanden, opslagplaatsen, enz. Een praktisch voorbeeld zou zijn wanneer de logins van een werknemer zijn geverifieerd, om te zien tot welke verdiepingen hij toegang heeft.
Beide authorisatie & authenticatie zijn van cruciaal belang voor beveiliging en toegangsbeheer en hoewel ze beide verschillende concepten achter zich hebben, zijn ze van cruciaal belang voor de infrastructuur van een systeem en het begrijpen ervan is de sleutel voor identiteit en toegangsbeheer.
SAML
Security Assertion Markup Language (SAML) is een op XML gebaseerde open standaard die wordt gebruikt voor single sign on (SSO) implementaties. SAML 2.0 werd in 2005 uitgebracht en is de huidige versie van de standaard.
SAML wordt gebruikt voor zowel authenticatie & autorisatie tussen twee partijen: een Service Provider (Office365, Salesforce, G Suite, etc.) & een Identity Provider (Okta, OneLogin, Ping Identity, etc.). De Service Provider (SP) gaat ermee akkoord de Identity Provider (IdP) te vertrouwen in het authenticatieproces. Dit gebeurt door middel van een SAML XML document dat door de IdP wordt verstuurd met daarin de gebruikersautorisatie & authenticatie en vervolgens wordt doorgestuurd naar de service provider.
Laten we dit voorbeeld eens bekijken:
- Identity Provider (IdP): Okta
- Service Provider (SP): Salesforce-applicatie
- Gebruiker probeert vanuit Chrome in te loggen op de Salesforce-applicatie van zijn bedrijf.
- Salesforce app reageert door een SAML-verzoek te genereren
- Chrome stuurt de gebruiker door naar een SSO URL, Okta parseert het SAML-verzoek, authenticeert de gebruiker (dit kan via gebruikersnaam en wachtwoord, twee-factor authenticatie of MFA als de gebruiker zich niet op het interne netwerk van het bedrijf bevindt; als de gebruiker al op Okta is geauthenticeerd, wordt deze stap overgeslagen) en genereert een SAML-antwoord.
- Okta stuurt de gecodeerde SAML-respons opnieuw naar Chrome
- Chrome stuurt de SAML-respons door naar de Salesforce-app
- Als de verificatie succesvol is, wordt de gebruiker ingelogd in de Salesforce-applicatie en krijgt hij toegang tot alle verschillende resources.
OAuth2
“Hoe kan ik een app toegang geven tot mijn gegevens zonder dat ik hem per se mijn wachtwoord hoef te geven?”
OAuth2 is een open standaard die wordt gebruikt voor autorisatie, het stelt apps in staat om applicaties te voorzien van ‘gedelegeerde autorisatie’. In tegenstelling tot andere frameworks die authenticatie bieden, autoriseert OAuth alleen apparaten, API, servers met toegangstokens in plaats van referenties en het werkt over HTTPS.
Als je ooit een van de onderstaande dialogen hebt gezien, dat is waar we het over hebben. Dit is een applicatie die vraagt of het namens jou toegang mag krijgen tot gegevens. Dit is OAuth.
Je kunt dit zien als hotel sleutelkaarten, maar dan voor apps. Als je een hotel sleutelkaart hebt, kun je toegang krijgen tot je kamer. Hoe krijg je een hotel sleutelkaart? Je moet een authenticatie proces doen bij de receptie om het te krijgen. Na authenticatie en het verkrijgen van de key card kun je toegang krijgen tot resources in het hele hotel.
OAuth definieert vier rollen:
- Resource Owner: Over het algemeen de gebruiker zelf
- Client: Applicatie die toegang vraagt tot een resource server
- Resource Server: Server die beschermde gegevens host (bijvoorbeeld Facebook die uw profiel en persoonlijke gegevens host)
- Authorization Server: Server die toegangstoken afgeeft aan de client. Dit token zal worden gebruikt voor de client om de resource server aan te vragen.
Hieronder staat een diagram van de OAuth2 flow.
Laten we dit voorbeeld eens bekijken:
- Spotify wil toegang tot je vriendenlijst van je facebook account.
- Je wordt door Spotify doorgestuurd naar de autorisatieserver (facebook in dit geval)
- Als je toegang autoriseert, stuurt de autorisatieserver een autorisatiecode naar de client (Spotify) in de callback response.
- Daarna wordt deze code uitgewisseld tegen een toegangstoken tussen de Facebook en Spotify.
- Nu kan Spotify dit toegangstoken gebruiken om de bronserver (Facebook) te bevragen en je vriendenlijst op te halen.
Eén ding dat moet worden opgemerkt, is dat de gebruiker het toegangstoken nooit te zien krijgt, het wordt opgeslagen in de sessie. De autorisatieserver stuurt ook andere informatie zoals de levensduur van het token en een refresh token.
OpenID Connect
OpenID Connect is een eenvoudige identiteitslaag bovenop het OAuth 2.0 protocol dat OAuth2 uitbreidt en ‘Federated Authentication’ mogelijk maakt.
De OpenID Connect proces flow is vergelijkbaar met de OAuth2 authorization flow met als grootste verschil een ‘id-token’ waarmee de gebruiker geauthenticeerd kan worden.
Merk op dat Federated Authentication iets heel anders is dan Delegated Authorization. Laten we opnieuw het voorbeeld van Facebook en Spotify nemen
- Gedelegeerde authenticatie is inloggen bij Spotify met je Facebook-gegevens.
- Gedelegeerde autorisatie is de mogelijkheid van een externe app om toegang te krijgen tot bronnen. In dit geval probeert Spotify toegang te krijgen tot je facebook vriendenlijst om deze te importeren in Spotify.
Om af te ronden volgt hier een tabel met een samenvatting van alle drie de protocollen/frameworks.