Model Context Protocol (MCP) sin autorisasjonsmodell er i endring. Dynamic Client Registration (DCR), som lenge har vært standard for dynamisk klientregistrering, regnes nå som en legacy-løsning. To nye ressurser, en fra Microsoft og en fra Auth0, forklarer hvorfor og hva som kommer i stedet.
Hva er DCR og hva er problemet?
Dynamic Client Registration lar klienter registrere seg dynamisk hos en autorisasjonsserver uten å være forhåndsregistrert. Det høres fleksibelt ut, men problemet er at stadig flere autorisasjonsservere ikke støtter det, og at det introduserer utfordringer rundt tillit og sikkerhet.
Microsoft Entra er et konkret eksempel. Entra støtter ikke DCR, noe som betyr at alle som vil bruke Entra som autorisasjonsserver for MCP-servere ikke kan bruke DCR. Det er ikke et lite unntak. Entra er den dominerende identitetsplattformen i enterprise-markedet.
Resultatet er at DCR aldri vil fungere som en universell løsning for MCP-autorisasjon. I stedet fases den ut til fordel for to alternative tilnærminger.
CIMD: Client ID Metadata Documents
Client ID Metadata Documents (CIMD) er den nye anbefalte tilnærmingen fra MCP-økosystemet. I stedet for at en klient dynamisk registrerer seg hos autorisasjonsserveren, publiserer klienten et metadata-dokument som beskriver hvem den er. Autorisasjonsserveren leser dette dokumentet og etablerer tillit basert på det.
CIMD er posisjonert som fremtiden for MCP-klientregistrering. Auth0 har skrevet om overgangen, og konklusjonen er tydelig: CIMD gir bedre sikkerhetsprofil for MCP-klienter som etablerer tillit og legitimasjon.
Den praktiske fordelen er at CIMD-tilnærmingen er mer kompatibel med eksisterende enterprise-infrastruktur, der autorisasjonsservere typisk forventer en forhåndsregistrert relasjon til klienter.
Forhåndsregistrering med Entra ID
For de som jobber med Microsoft-infrastruktur, er alternativet forhåndsregistrering. Tilnærmingen innebærer at MCP-serveren registreres i Entra via app registration, og spesifikke klienter forhåndsautoriseres eksplisitt.
For eksempel kan VS Code, med klient-ID aebc6443-996d-45c2-90f0-388ff96faa56, autoriseres som en pre-authorized klient. OAuth 2.1 permission scopes som user_impersonation konfigureres, og tilgang styres gjennom det.
For produksjonsmiljøer på Azure er anbefalingen Managed Identity as Federated Identity Credential (MI-as-FIC). Det lagres ingen hemmeligheter, ingen sertifikater trenger rotasjon, og autentiseringen håndteres av Azure-infrastrukturen. Det reduserer behovet for credential-administrasjon betydelig.
Forhåndsregistrering vs CIMD: to svar på samme problem
Både forhåndsregistrering og CIMD adresserer det samme problemet: at DCR ikke fungerer i praksis for mange produksjonsscenarioer.
Forhåndsregistrering passer best for miljøer der du har kontroll over autorisasjonsserveren, vet hvilke klienter som skal ha tilgang, og kan konfigurere dette eksplisitt. Typisk enterprise-bruk med Entra.
CIMD passer bedre for åpnere scenarioer der klienter ikke er kjent på forhånd, men der de kan publisere et metadata-dokument som autorisasjonsserveren kan verifisere. Det er mer fleksibelt, men krever at autorisasjonsserveren støtter CIMD-modellen.
Hva betyr dette i praksis?
Hvis du bygger MCP-servere i dag, er det viktig å forstå at DCR ikke er en trygg antagelse å planlegge rundt. Autorisasjonsservere som Entra støtter det ikke, og standarden er på vei bort fra det.
Tre ting er verdt å ta med seg:
- Sjekk om autorisasjonsserveren din støtter DCR. Mange gjør det ikke.
- Mye tyder på at standarden beveger seg mot CIMD. Vurder det for nye implementasjoner.
- For Azure og Entra-miljøer er forhåndsregistrering med MI-as-FIC den anbefalte tilnærmingen i dag.
MCP som protokoll modnes raskt. Autorisasjonsmodellen er ett av de områdene som har vært underutviklet, og CIMD er et tegn på at det tas tak i.
Ressurser: