In een eerdere blogpost zijn de eerste bevindingen van de werkgroep AsyncAPI gedeeld na het uitwerken van een tweetal use cases waarin asynchrone API’s van OAS naar AsyncAPI werden omgezet. Daarbij werd duidelijk dat AsyncAPI op zichzelf geen wondermiddel is, maar vooral een krachtig instrument dat helpt om asynchrone communicatie inzichtelijk en beheersbaar te maken. De overkoepelende vraag is nog echter niet behandeld: wanneer gaan we het dan wel, en wanneer niet gebruiken? In deze blog ga ik dieper in op de situaties waarin AsyncAPI wel geschikt lijkt, en in welke situaties het van weinig toegevoegde waarde lijkt te zijn.

De afgelopen periode hebben we binnen developer.overheid.nl samen met de Werkgroep AsyncAPI geëxperimenteerd met het toepassen van AsyncAPI in een aantal concrete casussen. Het doel van deze werkgroep is om te onderzoeken in welke mate AsyncAPI als nieuwe standaard voor de Nederlandse overheid geaccepteerd dient te worden. Niet zozeer om vast te stellen of het werkt, maar vooral om te begrijpen waar het in de praktijk daadwerkelijk waarde toevoegt, en waar het vooral extra werk introduceert zonder duidelijke meerwaarde. De technische werkbaarheid van de specificatie is door diverse use cases aangetoond; de vraag wanneer we het zouden moeten gebruiken is op dit moment dé kernvraag. Ik wil jullie in een reeks aan blogposts graag meenemen in waar de werkgroep nu staat m.b.t. AsyncAPI en hoe we de toekomst voor ons zien.

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.