SSO

koppeling:

SAML,

OpenID

Connect

en

OAuth2

in

de

praktijk.

Wat is een SSO-koppeling?

Kort antwoord: een afspraak tussen twee partijen over wie de gebruiker is. De ene partij bewaart de accounts en controleert het wachtwoord, de andere vertrouwt het antwoord van die eerste partij en laat de gebruiker binnen. Die eerste partij heet de identity provider, kortweg IdP. De tweede is de service provider of relying party: de applicatie waar de gebruiker naartoe wil. Het protocol bepaalt hoe die twee met elkaar praten en waarom de applicatie het antwoord mag vertrouwen. Het praktische gevolg is dat een gebruiker een keer inlogt en dat je als organisatie op een plek regelt wie toegang heeft. Zet je iemand daar uit, dan is hij overal weg, en dat laatste is voor de meeste organisaties het echte argument, niet het gebruiksgemak.

SAML, OpenID Connect en OAuth2 vergeleken.

De drie worden vaak in een adem genoemd en doen niet hetzelfde. SAML 2.0 en OpenID Connect zijn authenticatieprotocollen: ze vertellen een applicatie wie de gebruiker is. OAuth2 is een autorisatieframework: het geeft een applicatie toestemming om iets namens een gebruiker te doen, zonder te vertellen wie die gebruiker is.

Het tokenformaat verschilt daarmee ook. SAML wisselt XML-assertions uit, OpenID Connect een ID-token in JWT-formaat, en OAuth2 een access token dat een applicatie bij een API mag inleveren. Qua toepassing is SAML de standaard in enterprise- en onderwijsomgevingen en werkt het via browserredirects, terwijl OpenID Connect de standaard is voor moderne webapplicaties, single-page apps en mobiele apps. OAuth2 gebruik je wanneer een applicatie namens een gebruiker bij een API moet, bijvoorbeeld je eigen mobiele app die je eigen backend aanspreekt.

En qua complexiteit: SAML is het bewerkelijkste vanwege XML, certificaten en metadata-uitwisseling. OpenID Connect is aanzienlijk eenvoudiger door de discovery-mogelijkheid en het JWT-formaat. OAuth2 is eenvoudig zolang je het gebruikt waarvoor het bedoeld is, en lastig zodra je het misbruikt om in te loggen.

SAML 2.0.

SAML staat voor Security Assertion Markup Language en bestaat sinds 2005. Dat is geen diskwalificatie: het is volwassen, breed geimplementeerd en het doet precies wat het moet doen. De uitwisseling verloopt via de browser. Een gebruiker komt bij je applicatie, wordt doorgestuurd naar de identity provider, logt daar in, en komt terug met een ondertekende assertion waarin staat wie hij is en welke rollen hij heeft. Jouw applicatie controleert die ondertekening met een certificaat dat je vooraf hebt uitgewisseld. Je kiest SAML meestal omdat de andere partij het voorschrijft: onderwijsfederaties, overheidspartijen en veel grote werkgevers hebben hun identity provider op SAML staan en wisselen niet voor jou. Wat je daarbij onderschat is niet het protocol maar de operationele kant, want certificaten verlopen en metadata verandert, bij elke aangesloten partij op een ander moment.

OpenID Connect.

OpenID Connect is een authenticatielaag bovenop OAuth2. Waar OAuth2 alleen zegt dat een applicatie iets mag, voegt OpenID Connect een ID-token toe dat vertelt wie de gebruiker is. Dat token is een JWT: een ondertekend, compact stukje JSON dat je applicatie kan verifieren zonder de identity provider opnieuw te bevragen. Daarnaast publiceert de identity provider een discovery-document waarin staat waar alle endpoints staan en met welke sleutels hij ondertekent, en dat scheelt precies het handwerk dat SAML wel vraagt. Bij nieuwbouw en bij vrije keuze is OpenID Connect vrijwel altijd de betere optie, zeker als je meerdere soorten clients hebt: een webportaal, een mobiele app en een SaaS-omgeving laten inloggen op dezelfde identiteit is hier ontworpen gedrag en met SAML een reeks omwegen.

OAuth2: autorisatie in plaats van authenticatie.

Hier gaat het in de praktijk het vaakst mis. OAuth2 is niet gemaakt om iemand in te laten loggen, maar om een applicatie toegang te geven tot een resource namens een gebruiker. Het klassieke voorbeeld is een applicatie die je agenda mag lezen: je geeft toestemming, de applicatie krijgt een access token, en dat token opent de agenda-API. Wie die gebruiker precies is, staat er niet in. Wie OAuth2 alsnog gebruikt om in te loggen, bouwt zelf een aanname over identiteit bovenop een token dat daar niets over zegt. Dat werkt tot het moment dat het niet werkt, en dan is het een kwetsbaarheid en geen bug. Precies daarom bestaat OpenID Connect: het legt vast wat mensen anders zelf verzinnen.

Zelf identity provider worden.

Bijna alles wat er over SSO geschreven is gaat over het afnemen ervan: hoe sluit je jouw applicatie aan op een bestaande identity provider. De andere kant komt zelden aan bod en is voor sommige organisaties precies de vraag. Je wordt zelf identity provider wanneer jouw platform de plek is waar de accounts horen te staan: een softwareleverancier met een portaal en drie satellietapplicaties, een branchevereniging waarvan de leden bij verschillende aangesloten diensten moeten kunnen inloggen, of een ledenportaal dat de bron van waarheid is over wie lid is. Wat je daarmee op je neemt is meer dan een inlogscherm, want je beheert wachtwoordbeleid, sessies, tokenlevensduur en intrekking van toegang, en je bent de partij die anderen vertrouwen. Dat is een verantwoordelijkheid met een securitykant, en de reden dat wij daar altijd de security- en privacyeisen bij betrekken voordat er een regel code staat.

Hoe Cube SSO implementeert.

Cube implementeerde SSO in meerdere projecten, met OneLogin Saml2 voor de SAML-kant, OpenIDConnect voor de OpenID Connect-kant en Laravel Passport waar de applicatie zelf tokens moest uitgeven. In minstens een project fungeerde het platform zelf als identity provider voor aangesloten partijen. Onze aanpak begint niet bij het protocol maar bij de vraag wie eigenaar is van het account en wat er moet gebeuren als iemand vertrekt. Daaruit volgt het protocol, en niet andersom.

Standaardintegratie of maatwerk.

Sluit je aan op een bekende identity provider zoals Microsoft Entra, Okta of Auth0, gebruik dan hun eigen integratie of een bestaande bibliotheek. Maatwerk is nodig wanneer je meerdere partijen met verschillende protocollen aansluit, of wanneer je zelf identity provider wordt. Bij SAML hoort daar bovendien monitoring op geldigheidsdata bij, want een verlopen certificaat betekent dat niemand meer kan inloggen. Zie ook onze aanpak voor API-koppelingen.

Kort samengevat.

SAML 2.0 en OpenID Connect vertellen een applicatie wie de gebruiker is, OAuth2 geeft alleen toestemming om iets te doen en is geen inlogprotocol. SAML kies je als de andere partij het voorschrijft, OpenID Connect bij vrije keuze en bij mobiele of single-page clients. Zelf identity provider worden is een aparte vraag met een eigen securityverantwoordelijkheid. Cube implementeerde alle drie de protocollen en fungeerde in minstens een project zelf als identity provider.