MCP-clientregistratie: DCR eruit, CIMD erin

Kan uw AI-agent geen verbinding maken met een bedrijfssysteem en staat er in het log Incompatible auth server: does not support dynamic client registration? Dan is de oplossing in 2026 meestal niet om een server te zoeken die het wel ondersteunt. De MCP-specificatie van 28 juli 2026 heeft Dynamic Client Registration afgeschreven ten gunste van Client ID Metadata Documents. De foutmelding wijst naar een route die verdwijnt, niet naar een defect dat u moet oplossen.

Wat veranderde er op 28 juli 2026 aan MCP-clientregistratie?

MCP had vanaf het begin een lastig probleem: een agent en een bedrijfssysteem die elkaar nooit eerder hebben gezien, moeten toch samen een OAuth-flow doorlopen. Het oorspronkelijke antwoord was Dynamic Client Registration, RFC 7591. De client stuurt tijdens het draaien zijn naam en redirect-URI's naar een registratie-endpoint, de autorisatieserver legt een record aan en geeft een nieuwe client_id terug.

Dat werkte in demo's en schaalde slecht. Elke installatie van dezelfde desktopclient wordt een aparte regel. Het endpoint /register staat voor iedereen open, wat het een aantrekkelijk doelwit maakt, en de naam op het formulier is precies wat de client zelf invulde. De specificatie van 28 juli loste dit op door DCR te degraderen en een mechanisme te promoveren dat de richting van het vertrouwen omdraait.

Het hoofdstuk over clientregistratie noemt nu drie mechanismen en een strikte volgorde. Een client gebruikt eerst vooraf geregistreerde gegevens, dan Client ID Metadata Documents als de autorisatieserver aangeeft die te ondersteunen, dan DCR als terugvaloptie, en pas daarna vraagt hij het aan de gebruiker. Ook de verplichtingsniveaus verschoven. CIMD is een SHOULD, DCR is een MAY, en op de spec-pagina staat expliciet dat DCR is afgeschreven en dat nieuwe implementaties het niet meer moeten gebruiken.

Waarom blijft "does not support dynamic client registration" terugkomen?

Omdat veel clienttooling DCR nog steeds als het enige automatische pad behandelt, en veel autorisatieservers het nooit hebben ondersteund. Die combinatie levert een zelfverzekerde foutmelding op die naar de verkeerde partij wijst.

Het patroon ligt open en bloot. Claude Code kreeg al in juli 2025 een issue over MCP-servers die DCR niet implementeren, en latere meldingen noemen Slack, het MCP-endpoint van GitHub Copilot, Box, Azure DevOps en AWS Cognito als autorisatieservers waar het misgaat. Wij zagen deze week beide varianten in onze eigen tooling: de ene server meldde "does not support dynamic client registration", de andere weigerde de registratie-POST met een HTTP 403.

Lees die twee fouten goed en ze zeggen iets verschillends. De eerste betekent dat de autorisatieserver nooit een registration_endpoint in zijn metadata heeft gepubliceerd. De tweede betekent dat hij er wel een heeft, maar u niet bedient, meestal omdat registratie alleen aan beheerders is voorbehouden. Opnieuw proberen lost geen van beide op. Een ander registratiemechanisme kiezen wel.

Wat is een Client ID Metadata Document precies?

Een CIMD is een statisch JSON-bestand dat de client op zijn eigen domein publiceert, en de HTTPS-URL van dat bestand is de client_id. In plaats van dat de client een registratie de database van de server in duwt, haalt de server de identiteit van de client op bij een URL die hij kan controleren. Het mechanisme komt uit SEP-991 en volgt het IETF-concept OAuth Client ID Metadata Document.

Het minimum uit de specificatie is klein. Het document moet via https worden aangeboden, de URL moet een padcomponent bevatten, en het bestand moet client_id, client_name en redirect_uris bevatten, waarbij de client_id in het bestand exact overeenkomt met de URL waar het vandaan kwam. Een publieke client zet er token_endpoint_auth_method: none bij en leunt op PKCE. Een vertrouwelijke client kiest private_key_jwt en publiceert een jwks_uri, waarmee het gedeelde geheim helemaal uit de relatie verdwijnt.

Drie gevolgen zijn het onthouden waard. Ten eerste wordt impersonatie tegengehouden door de lijst met redirect_uris: een phishingsite kan de client_id-URL van een ander citeren, maar de autorisatieserver haalt het echte document op, ziet dat de callback van de aanvaller er niet in staat en breekt af. Ten tweede geeft de autorisatieserver zijn ondersteuning aan met client_id_metadata_document_supported: true in zijn OAuth-metadata, zodat een client de mogelijkheid kan detecteren in plaats van ernaar te raden. Ten derde, en dat wordt het minst besproken: CIMD-client_ids zijn overdraagbaar tussen autorisatieservers. DCR-gegevens niet. Dezelfde release koppelde clientgegevens vast aan de issuer die ze uitgaf, dus als een leverancier van autorisatieserver wisselt, moet elke via DCR geregistreerde client zich opnieuw registreren terwijl elke CIMD-client gewoon blijft werken.

Welke autorisatieservers ondersteunen CIMD vandaag?

De adoptie is echt maar ongelijk, en de scheidslijn is belangrijker dan de techniek. Identity providers voor ontwikkelaarsplatforms hebben het geleverd. Enterprise identity providers niet.

Pull quote from Crux Digits: De foutmelding zegt dat de server een functie mist. De specificatie zegt dat die functie op weg naar buiten is.

Geleverd of onderweg. De OAuth-provider van Clerk voegde CIMD op 6 augustus 2026 in beta toe, met een dashboardtab om clients per client_id-URL toe te laten en een schakelaar voor de vraag of onbekende clients überhaupt mogen verbinden. Better Auth levert het als CIMD-plug-in. Stytch en WorkOS hebben implementaties gepubliceerd. Auth0 heeft het model uitgebreid beschreven maar het niet geleverd.
Niet beschikbaar. Microsoft Entra ID ondersteunt CIMD noch DCR. Okta ondersteunt DCR en heeft CIMD nog niet geleverd.

Die asymmetrie is het praktische verhaal. Zit het systeem dat uw agent moet bereiken achter een IdP van een ontwikkelaarsplatform, dan is CIMD nu beschikbaar en is de migratie één statisch bestand. Zit het achter de identity provider die een Nederlands of Belgisch bedrijf daadwerkelijk draait, dan bestaat geen van beide automatische opties.

Waarom weigert Microsoft Entra ID allebei?

Niet uit nalatigheid. Een ontwerpnotitie over MCP-authenticatie met Entra zet de redenering uiteen, en die is samenhangend, ook al is ze onhandig. Het model van Entra is dat een beheerder elke app-registratie in de tenant kan zien: wie hem aanmaakte, wat hij mag en wanneer hij voor het laatst inlogde. Beide automatische mechanismen doorbreken dat, elk op hun eigen manier: DCR maakt app-objecten aan die niemand heeft goedgekeurd, en CIMD maakt aan de serverkant helemaal geen object, dus er is niets voor Conditional Access om tegen te toetsen en niets in het auditspoor behalve het ophalen van een externe URL die daarna nog kan veranderen.

De notitie noemt ook de kosten van CIMD zelf, en dat zijn de kosten die een architect moet afwegen. Het ophalen van andermans URL maakt van de autorisatieserver een HTTP-client, en dat is een aanvalsvlak voor server-side request forgery en een mogelijke DDoS-versterker; de beveiligingsoverwegingen van MCP dragen implementeerders op die fetcher te harden met blokkades op interne IP-reeksen, korte timeouts en een limiet op de responsgrootte. Redirect-URI's op localhost kunnen twee processen op dezelfde poort niet uit elkaar houden. En het onderliggende IETF-document is nog een Internet-Draft en geen vastgestelde RFC, wat voor een grote identity provider een normale reden is om te wachten.

De brug van Entra is vooraf registreren, aangevuld met het zelf vooraf registreren van de meest gebruikte clients. Dat is optie één op de prioriteitenlijst van de specificatie zelf, dus een bedrijf dat die route volgt zit niet fout. Het doet het werk alleen met de hand.

Welke registratieroute kiest u?

Vier situaties, en het antwoord volgt uit de vraag welke kant van de verbinding van u is.

U koopt een agent die op een SaaS-systeem aansluit. Controleer of de autorisatieserver van de leverancier client_id_metadata_document_supported adverteert. Zo niet, en er is ook geen registration_endpoint, dan is het antwoord een vooraf geregistreerde client-ID. Vraag daarom vóór het tekenen om die ID, en niet na de eerste mislukte verbinding.
U bouwt een MCP-client. Publiceer een CIMD op een vaste URL op uw eigen domein en houd DCR voorlopig als terugval. Dat is een kleine, aanvullende wijziging: een statisch JSON-bestand plus een codepad dat een URL-client_id verkiest zodra de server ondersteuning aangeeft.
U ontsluit uw eigen systeem als MCP-server achter Entra of Okta. Vooraf registreren is vandaag uw route. Leg vast welke client-ID's u toestaat en behandel die lijst als een toegangsbeslissing, niet als een configuratiedetail.
U draait zelf een autorisatieserver. Hard eerst de fetcher, zet CIMD dan aan en adverteer het. Geef uzelf een toelatingsbeleid zodat u kunt beslissen of onbekende clients mogen verbinden, precies de knop die Clerk naast de functie meeleverde.

Wat u ook kiest: bewaar DCR-gegevens niet langer over autorisatieservers heen. Dat is nu expliciet verboden, en het is precies het soort ding dat een jaar lang stilletjes werkt en dan stukloopt bij een migratie van de leverancier.

Wat dit betekent voor een Nederlands of Belgisch bedrijf

Voor een bedrijf van ruwweg 20 tot 250 medewerkers op Microsoft 365 is het praktische antwoord kort: uw identity provider is Entra, dus de automatische routes staan niet voor u open, en elke MCP-koppeling die u toevoegt is een beheerderstaak. Dat is geen omweg. Het is het governance-model dat u al op elke andere app-registratie toepast, doorgetrokken naar agents.

Plan ervoor in plaats van het te ontdekken. Als u een agent uitwerkt die een ERP- of boekhoudpakket moet bereiken, zet dan "welke client-ID's heeft dit nodig en wie keurt ze goed" in hetzelfde gesprek als de rechten die de server mag uitoefenen. Die twee vragen hebben dezelfde eigenaar en dezelfde toetsingscyclus, en ze horen allebei thuis in het koppelingsontwerp en niet in een supportticket na livegang.

Over het tempo: de release van 28 juli 2026 introduceerde een formeel deprecatiebeleid met een minimumvenster van twaalf maanden. Daarmee ligt de vroegst mogelijke verwijdering van DCR op zijn vroegst in de tweede helft van 2027, en alleen in een toekomstige revisie van de specificatie. Er is geen haast. Er is een richting, en nieuwe koppelingen bouwen op een mechanisme dat de specificatie al voor verwijdering heeft aangemerkt, is een keuze waarvoor u later betaalt in plaats van nu.

Loopt u nog achter op de rest van die release? De stateless kern en het extensieraamwerk veranderden meer aan het protocol dan de autorisatie deed, en die twee migraties zijn meestal samen de moeite waard. Wilt u liever dat iemand uw eigen koppelingen hiertegen uitzet, dan is dat waar een traject rond agentkoppelingen mee begint.

Veelgestelde vragen

Wanneer stopt Dynamic Client Registration echt met werken?

Niemand heeft een verwijderdatum gepubliceerd. De release van 28 juli 2026 introduceerde een formeel deprecatiebeleid met een minimumvenster van twaalf maanden, en DCR wordt beschreven als afgeschreven en bestemd voor verwijdering in een toekomstige revisie, niet in deze. Bij elkaar genomen ligt de vroegst realistische verwijdering in de tweede helft van 2027, en dan alleen in een versie die u bewust zou moeten overnemen. Het risico is intussen niet dat DCR ophoudt te werken. Het is dat steeds minder autorisatieservers de moeite nemen om het te implementeren, waardoor een route waar u op ontwierp steeds smaller wordt.

Heb ik een CIMD nodig als mijn MCP-servers allemaal lokaal via stdio draaien?

Nee. Clientregistratie is een OAuth-kwestie, en een lokale stdio-server die u zelf start doorloopt helemaal geen OAuth-flow. De vraag speelt alleen bij MCP-servers op afstand die via HTTP bereikbaar zijn, waar een autorisatieserver tussen de agent en de data staat. In de praktijk komen de meeste bedrijven bij allebei uit: een paar lokale servers voor ontwikkeltooling, en servers op afstand voor de SaaS-systemen waar de echte bedrijfsgegevens staan. Alleen die tweede groep vraagt om een registratiekeuze.

Is de CIMD-URL geheim, en wat gebeurt er als we het bestand wijzigen?

De URL is niet geheim. Het is een openbaar identificatiemiddel, bewust gepubliceerd zodat elke autorisatieserver het kan ophalen, en de veiligheid van de flow rust op de lijst met redirect_uris en op PKCE, niet op onbekendheid van de URL. Wijzigingen worden actief zodra een server het bestand opnieuw ophaalt; servers wordt opgedragen te cachen met inachtneming van HTTP-cacheheaders, dus geef het bestand verstandige cacheheaders als u verwacht het te bewerken. Behandel de URL als permanent: het is overal uw client_id, en hem wijzigen betekent dat elke toestemming die een gebruiker gaf, aan een andere client is gegeven.

Verandert een Client ID Metadata Document wat onze gebruikers zien als zij toegang goedkeuren?

Ja, en in een nuttige richting. Bij DCR toonde het toestemmingsscherm de naam die de client zelf in zijn registratieverzoek had gezet, en juist daardoor kon een client zich voordoen als iets anders. Bij CIMD haalt de autorisatieserver client_name en logo_uri op uit een document dat wordt aangeboden door een domein waarvan de client aantoonbaar eigenaar is, en toont die. Het bewijst nog steeds alleen wie het domein bezit, niet dat die eigenaar te vertrouwen is, dus een server kan er een vertrouwensbeleid overheen leggen: bekende client_id-URL's expliciet toestaan, en apart bepalen of onbekende überhaupt mogen verbinden.