OIDC voor Nederlandse Identiteitsdiensten

Binnen de Nederlandse overheid zijn DigiD, eHerkenning en eIDAS al jaren de ruggengraat van digitale identiteit en toegang. Ze zijn betrouwbaar, veilig, bewezen en breed ingezet door heel Nederland heen. Tegelijkertijd stoelen deze voorzieningen op een technische basis die steeds minder goed afgestemd is op hoe we vandaag digitale diensten bouwen: SAML 2.0.

Eerlijk is eerlijk, SAML werkt. Het is veilig, veel klassieke webapplicaties zijn erop ingericht om het te ondersteunen en de techniek is door de experts echt goed begrepen. Maar er schuurt wel wat. Ontwikkelaars en beheerders ervaren het vaak als lastig te implementeren en te testen, de uiteenlopende manieren waarop de eHerkenningsmakelaars de standaard implementeren compliceert aansluitingen en updates en het is lastig te combineren met moderne security-patronen zoals “zero trust”. SAML is in de kern ontworpen voor browser-based SSO, niet voor API beveiliging. Voor organsaties die richting API-first architectuur, mobiele apps en microservices bewegen is er echter een passend alternatief: OpenID Connect, ofwel OIDC.

OIDC

OIDC is een identiteitslaag bovenop de OAuth 2.0 standaard, en gezamenlijk vormen zij de breedst-gedragen moderne standaard voor IAM-oplossingen. De berichtenstromen zijn een stuk lichter door JSON en REST te gebruiken i.p.v. XML, er is een expliciete scheiding tussen autorisatie en authenticatie die men naar eigen inzicht kan implementeren, en het staat toe om zeer uitgebreide niveaus aan toegang en gegevensuitwisseling toe te staan en af te dwingen op basis van simpele, door de eigenaar van de data goedgekeurde “consent”. Ook is het API-first en kanaalonafhankelijk, in tegenstelling tot SAML welke echt browser-centrisch is; de wereld is dit echter niet meer. Daarnaast is de instap voor developers een stuk lager door de lichtgewicht aard van de berichtenstromen (JSON en REST i.p.v. XML, zie OIDC en SAML) en de bekendheid van de techniek over de gehele wereld. Het is ook flexibel en toekomstvast; door OIDC flows als Authorization Code (met PKCE) voor web en apps en Device Code voor beperkte apparaten is OIDC veilig in te zetten voor vele gebruiksscenario’s, zonder protocoluitbreidingen of workarounds. Tot slot is er een sterkere aansluiting mogelijk op basis van “zero trust”, omdat elke aparte request in OIDC expliciet geautoriseerd is, tokens context afhankelijk en slechts van korte duur zijn, en er minder afhankelijkheid is van sessies. SAML is daar nooit voor ontworpen, OIDC wel.

Voordelen van SAML

OIDC is echter ook niet zonder zwakke plekken. SAML biedt strakkere controle op sessie-management, vooral op het gebied van SSO/SLO voor sessies over meerdere applicaties heen. Daarnaast zit het afhandelen van complexe attribuutstructuren ingebakken in de SAML standaard; OIDC laat dit heel vrij, wat een voor- en een nadeel kan zijn. Dit is tegelijk de brug naar een ander mogelijk voordeel van SAML: de welliswaar complexe maar ook zeer strakke definitie van attributen schept eenduidigheid in implementatie, en daarmee gemak in het koppelen van verschillende systemen die wel allemaal SAML kunnen. In OIDC gaat dit via custom claims; niet onmogelijk dus, maar vereist wel weer maatwerk waarin organisaties uiteen kunnen gaan lopen in hun implementatie terwijl we juist bewegen naar meer standaardisatie. Vergeet ook niet het praktische voordeel van het feit dat veel legacy systemen ingericht zijn om SAML te ondersteunen. Wanneer men hiermee te maken heeft kan SAML zeker van grotere waarde zijn dan OIDC, welke meer gericht is op moderne apps, API's, mobiele apparaten en situaties wanneer gebruiksnelheid (voor eindgebruiker en implementer) voorop moeten staan. SAML heeft dus wel degelijk sterke kanten waar OIDC minder geschikt voor is.

Waarom dan toch OIDC?

Als we de toekomst van onze Identiteitsdiensten willen veiligstellen dan valt er met OIDC een hoop te behalen voor burgers en overheid. Een simpelere implementatie bij de overheid zorgt ervoor dat de burger betere, diversere dienstverlening kan verwachten. Door minder afhankelijk te zijn van sessies en gemakkelijke SSO ondersteuning door steeds met te behouden tokens aan te kunnen kloppen bij userinfo endpoints komt de burger minder vaak voor “u bent uitgelogd” momenten te staan (zie bijv. [blogpost]https://darutk.medium.com/native-sso-0137f9431782). Met OIDC kan bijv. DigiD eenvoudiger native mobiele apps ondersteunen zonder browser-hacks voor speciale situaties, zoals nu met app2app nog wel eens wordt gedaan. Er is daarnaast een heel duidelijke “consent” laag in OIDC waar de eigenaar van de data toestemming kan geven op het gebruik van zijn gegevens, zodat de burger transparantie ervaart en zelf in controle blijft. Ook de toekomstige aansluiting op Europese verordeningen zoals de eIDAS 2.0 wallet, die weliswaar geen OIDC(4VC/4VP) vereist maar wel erop toegespitst is om hiervan gebruik te gaan maken (zie deze publicatie en hier de roadmap), zullen hierdoor versimpeld worden, wat minder verstoring in gebruik voor burgers oplevert (en natuurlijk een soepeler proces voor de instanties die het implementeren). Kortom, er zijn veel voordelen voor iedereen aan verbonden om OIDC aan te gaan bieden voor de Nederlandse Identiteitsdiensten.

Alternatief, geen vervanging

Dit alles is geen pleidooi voor “SAML eruit, OIDC erin”. Dit is een pleidooi om OIDC als volwaardig alternatief aan te bieden. Door beiden aan te gaan bieden zorgen de Nederlande Identiteitsdiensten juist dat ze alle use-cases kunnen bedienen, en niet alleen situaties waar de browser centraal staat. Naast SAML ook OIDC mogelijk maken kan ervoor zorgen dat aansluitingen voor nieuwe diensten eenvoudiger worden, we als Nederlandse Overheid beter aansluiten op internationale ontwikkelingen, en er ruimte ontstaat voor innovatie zonder de basis te verstoren. Het laten staan zoals het er nu bij staat is niet voldoende; OIDC verlaagt in cases waar het wel aan de orde is structureel de integratielast, maakt het hergebruik van identiteitsdiensten eenvoudiger, versterkt het de positie van publieke voorzieningen in een API-gedreven ecosysteem en verkleint het de afhankelijkheid van complex maatwerk en legacy tooling.

Conclusie

SAML heeft ons allemaal ver gebracht, en blijft voorlopig ook relevant. Echter, als we DigiD, eHerkenning en eIDAS klaar willen maken voor de komende jaren dan is OIDC geen nice-to-have. Het is een logische vervolgstap die we als alternatief aan moeten gaan bieden. Het OIDC NLGov profiel is immers op de “Pas toe of leg uit” lijst van standaarden gezet (hier te vinden); laten we het dan ook mogelijk gaan maken om die te gaan gebruiken.