Diepgaande beoordeling van de MCP-autorisatiespecificatie (editie 2025-03-26)

MCP (Model Context Protocol) is een open standaard die AI-modellen in staat stelt om te communiceren met externe tools en diensten. Het wordt breed geadopteerd door de industrie. Aangezien MCP HTTP-gebaseerde transportmethodes ondersteunt, zal Remote MCP Server een steeds belangrijkere rol spelen in het MCP-ecosysteem.

In tegenstelling tot Local MCP Server, waar elke gebruiker zijn eigen serverinstantie kan draaien, vereist Remote MCP Server dat alle gebruikers dezelfde MCP Server-service delen. Dit roept het kernprobleem op dat MCP Authorization Spec probeert op te lossen: hoe MCP Server toegang kan geven tot gebruikersbronnen namens de gebruiker.

Dit artikel zal de MCP Authorization Spec diepgaand analyseren. Het zal je helpen de ontwerpprincipes van de MCP Authorization Spec te begrijpen en enkele richtingen voor de implementatie van MCP Authorization. Aangezien deze Spec nog in ontwikkeling is, zal ik enkele gedachten delen op basis van mijn persoonlijke ervaring met het implementeren van Authenticator, waaronder:

• Voordelen en beperkingen van OAuth 2.1 als autorisatieframework
• Uitdagingen van de dubbele rollen van MCP Server als zowel Authorization Server als Resource Server
• Praktische complexiteit van het implementeren van een volledige Authorization Server
• Analyse van geschikte scenario's voor gedelegeerde derde partij autorisatie
• Praktische afwegingen van Dynamische Clientregistratie
• Belang van het duidelijk definiëren van de resourcegrenzen van MCP Server

Overzicht van de MCP Authorization Spec#

MCP Authorization Spec definieert het authenticatieproces tussen MCP Server (Remote) en MCP Client.

Ik denk dat het baseren van deze Spec op OAuth 2.1 een zeer redelijke keuze is. OAuth als een autorisatieprotocolframework lost het probleem op van hoe gebruikers derde partij applicaties kunnen autoriseren om gebruikersbronnen namens hen te benaderen. Als je niet bekend bent met OAuth, kun je AuthWiki-OAuth raadplegen voor meer informatie.

In het scenario van MCP Client en MCP Server gaat het erom dat "gebruikers MCP Client autoriseren om gebruikersbronnen op MCP Server te benaderen". De "gebruikersbronnen op MCP Server" verwijzen momenteel voornamelijk naar tools die door MCP Server worden aangeboden of bronnen die door de backend-services van MCP Server worden geleverd.

Om het OAuth 2.1-authenticatieproces te implementeren, vereist het protocol dat een MCP Server de volgende interfaces biedt om samen te werken met MCP Client voor het voltooien van het OAuth 2.1-authenticatieproces:

• /.well-known/oauth-authorization-server: OAuth-servermetadata
• /authorize: Autorisatie-eindpunt, gebruikt voor autorisatieverzoeken
• /token: Token-eindpunt, gebruikt voor tokenuitwisseling & vernieuwing
• /register: Clientregistratie-eindpunt, gebruikt voor dynamische clientregistratie

Het authenticatieproces verloopt als volgt:

De Spec specificeert ook hoe MCP Server gedelegeerde autorisatie ondersteunt via derde partij autorisatieservers.

De voorbeeldstroom in de Spec is als volgt (uit de Spec-inhoud):

In dit scenario, hoewel MCP Server autorisatie delegeert aan een derde partij autorisatieserver, fungeert MCP Server nog steeds als een autorisatieserver voor MCP Client. Dit komt omdat MCP Server zijn eigen toegangstoken moet uitgeven aan MCP Client.

In mijn opinie lijkt dit scenario meer geschikt voor situaties waarin MCP Server MCP Client (gebruiker) proxy om toegang te krijgen tot derde partij bronnen (zoals Github-repo's), in plaats van MCP Server MCP Client proxy voor toegang tot zijn eigen bronnen.

Samenvattend doet MCP Server volgens het protocol dienst als zowel Authorization Server als Resource Server binnen OAuth.

Laten we vervolgens de verantwoordelijkheden van MCP Server als Authorization Server en Resource Server bespreken.

MCP Server als autorisatiedienst#

Wanneer MCP Server fungeert als Authorization Server, betekent dit dat de eindgebruiker van MCP Client zijn eigen identiteit heeft op MCP Server. MCP Server is verantwoordelijk voor het authenticeren van deze eindgebruiker en het uitgeven van een toegangstoken aan deze eindgebruiker voor toegang tot MCP Server-bronnen.

De autorisatiegerelateerde interfaces die door MCP Authorization Spec hierboven worden vermeld, betekenen dat MCP Server een implementatie van Authorization Server moet bieden.

Het implementeren van Authorization Server-functionaliteit op MCP Server is echter een aanzienlijke uitdaging voor ontwikkelaars. Aan de ene kant zijn de meeste ontwikkelaars mogelijk niet bekend met OAuth-gerelateerde concepten. Aan de andere kant zijn er veel details om rekening mee te houden bij het implementeren van Authorization Server. Als een ontwikkelaar niet uit een gerelateerd veld komt, kunnen ze problemen introduceren, zoals beveiligingsproblemen tijdens de implementatie.

Het protocol zelf beperkt MCP Server echter niet tot alleen de functionaliteit van Authorization Server zelf implementeren. Ontwikkelaars kunnen deze autorisatiegerelateerde eindpunten volledig doorverwijzen of proxieren naar andere autorisatieservers. Dit is voor MCP Client niet anders dan wanneer MCP Server zelf de functionaliteit van Authorization Server implementeert.

Je zou je kunnen afvragen, zou deze aanpak de hierboven genoemde methode van gedelegeerde derde partij autorisatie moeten gebruiken?

Vanuit mijn perspectief hangt dit voornamelijk af van of de gebruikers van de derde partij autorisatiedienst waar je op vertrouwt dezelfde zijn als de eindgebruikers van MCP Server. Dit betekent dat het toegangstoken dat aan jou wordt uitgegeven door de derde partij autorisatiedienst direct door je MCP Server zal worden geconsumeerd.

• Als dat zo is, kun je alle Auth-gerelateerde interfaces in je MCP Server volledig doorverwijzen naar derde partij autorisatiediensten.

• Als dit niet het geval is, moet je de gedelegeerde derde partij autorisatiemethode zoals gespecificeerd in de Spec gebruiken. Je moet in MCP Server een mappingrelatie onderhouden tussen de toegangstokens die door MCP Server zelf worden uitgegeven en die worden uitgegeven door derde partij autorisatiediensten.

Ik denk dat de gedelegeerde derde partij autorisatie-aanpak die in het protocol wordt gespecificeerd in praktische toepassingsscenario's enigszins vaag is. Het protocol lijkt erop te vertrouwen dat derden MCP Server helpen het autorisatieproces te voltooien, maar vereist nog steeds dat MCP Server zijn eigen Access Token uitgeeft. Dit betekent eigenlijk dat MCP Server nog steeds de verantwoordelijkheid heeft om Access Tokens uit te geven als Authorization Server, wat niet per se handiger is voor ontwikkelaars. Ik denk dat het waarschijnlijk is omdat de auteurs van het protocol hebben overwogen dat het direct retourneren van derde partij toegangstokens aan MCP Client enkele beveiligingsproblemen met zich mee zou brengen (zoals lekkage/misbruik, etc.).

Uit mijn ervaring blijkt dat het meest geschikte scenario voor de gedelegeerde derde partij autorisatie die in het protocol wordt gespecificeerd het scenario zou moeten zijn van "gebruikers die MCP Server autoriseren om toegang te krijgen tot derde partij bronnen". Bijvoorbeeld, een MCP Server moet toegang krijgen tot de Github-repo van een gebruiker en de code van de repo inzetten naar een code implementatieplatform. In dit geval moet de gebruiker MCP Server autoriseren om toegang te krijgen tot hun Github-repo en het code implementatieplatform.

In dit scenario is MCP Server een Authorization Server voor MCP Client, omdat eindgebruikers hun eigen identiteit hebben in MCP Server. MCP Server is een derde partij Client voor derde partij bronnen (in dit geval, Github). Het moet gebruikers toestemming krijgen om toegang te krijgen tot gebruikersbronnen op Github. Tussen MCP Client en MCP Server, en tussen MCP Server en derde partij bronnen, zijn gebruikersidentiteiten gescheiden. Dit maakt het zinvol om een mappingrelatie te onderhouden tussen toegangstokens die door MCP Server zelf worden uitgegeven en toegangstokens die door derde partij autorisatiediensten in MCP Server worden uitgegeven.

Dus het gedelegeerde derde partij autorisatieprotocol in het protocol zou het probleem moeten oplossen van "hoe gebruikers MCP Server autoriseren om toegang te krijgen tot gebruikersbronnen op derde partij Resource Servers".

MCP Server als Resource Server#

Wanneer MCP Server fungeert als Resource Server, moet MCP Server verifiëren of het verzoek van MCP Client een geldig toegangstoken meedraagt. MCP Server zal beslissen of MCP Client toegang mag krijgen tot specifieke bronnen op basis van de scope van het toegangstoken.

Vanuit de definitie van MCP zou de bron die door MCP Server wordt geleverd tools moeten zijn voor MCP Client om te gebruiken. In dit scenario hoeft MCP Server alleen te beslissen of het gebruikers toegang verleent tot bepaalde tools.

Maar in echte scenario's moeten deze tools die door MCP Server worden geleverd ook communiceren met de Resource Server van de MCP Server-dienstverlener zelf. Op dit moment moet het toegangstoken verkregen door MCP Server van het clientverzoek worden gebruikt om toegang te krijgen tot zijn eigen Resource Server. In de meeste gevallen zijn MCP Server en de Resource Server achter de tools van dezelfde ontwikkelaar. MCP Server is slechts een interface die door zijn eigen backend resources voor MCP Client wordt geleverd. Op dit moment kan MCP Server hetzelfde toegangstoken delen dat door één Authorization Server wordt uitgegeven met backend resources.

In dit geval, in plaats van te zeggen dat MCP Server een Resource Server is, door tools en zijn eigen bron van de service te leveren, is het beter om te zeggen dat de bestaande Resource Server een MCP Server wordt door tools te bieden voor MCP Client om aan te roepen.

Het opnemen van resources geleverd door zijn eigen Resource Server in de Resource verstrekt door MCP Server is meer vanuit overweging van echte scenario's. Maar persoonlijk geef ik er de voorkeur aan dat de Resource verstrekt door MCP Server alleen tools zijn die worden gebruikt door MCP Client, en dat de resources waar tools afhankelijk van zijn, resources zijn die MCP Server verkrijgt van andere Resource Servers (inclusief eigen en derde partij). Op deze manier kunnen alle echte scenario's worden gedekt.

Hoe MCP-autorisatie werkt#

Na het begrijpen van de verantwoordelijkheden van MCP Server als Authorization Server en Resource Server, kunnen we weten hoe MCP Authorization specifiek werkt:

Dynamische Clientregistratie#

De Spec definieert ook hoe Authorization Server Clients identificeert. OAuth 2.1 biedt Dynamische Clientregistratieprotocol, waarmee MCP Client automatisch een OAuth-client ID kan verkrijgen zonder handmatige gebruikersinterventie.

Volgens de Spec moet MCP Server het Dynamische Clientregistratieprotocol van OAuth 2.0 ondersteunen. Op deze manier kan MCP Client automatisch registreren bij nieuwe servers om een OAuth-client ID te verkrijgen. Deze aanpak wordt aanbevolen in MCP-scenario's, voornamelijk omdat:

• MCP Client kan niet van tevoren alle mogelijke servers kennen
• Handmatige registratie zou gebruikers problemen bezorgen
• Het maakt verbinding met nieuwe servers naadloos
• Servers kunnen hun eigen registratiebeleid implementeren

Echter, vanuit praktisch perspectief heb ik enkele gedachten over de toepassing van Dynamische Clientregistratie in MCP-scenario's:

• In praktische OAuth-servicepraktijken komt Client meestal één-op-één overeen met een specifieke business App. Dynamisch een Client aanmaken kan niet bevorderlijk zijn voor het effectief beheren van gerelateerde resources (gebruikers, App, etc.) in OAuth-services. OAuth-dienstverleners hopen meestal duidelijk controle te hebben over aangesloten Clients, in plaats van dat elke client zich willekeurig kan registreren als een Client.
• Veel OAuth-diensten raden niet aan of staan gebruikers niet toe om dynamisch Clients aan te maken, omdat dit kan leiden tot misbruik van de service. De meeste volwassen OAuth-dienstverleners (zoals GitHub, Google, etc.) vereisen dat ontwikkelaars Clients handmatig registreren via hun ontwikkelaarsconsole, en kunnen ook gedetailleerde informatie over de applicatie, terugroep-URL, etc. vereisen.
• Het handmatig registreren van OAuth Client is eigenlijk een eenmalige taak tijdens de ontwikkeling, niet iets dat elke eindgebruiker moet doen. Het zal geen grote belasting vormen voor ontwikkelaars.
• Voor Public Client (zoals native applicaties, single-page applicaties, etc.) hebben we veiligere manieren om OAuth-stroom te implementeren zonder dynamische registratie. Client ID gecombineerd met PKCE (Proof Key for Code Exchange) kan een beveiligde genoeg OAuth-stroom bieden voor Public Client zonder dynamisch een Client aan te maken.
• Hoewel het protocol aangeeft dat het gebruik van Dynamische Clientregistratie kan voorkomen dat clients Client ID van tevoren moeten kennen, moet MCP Client in feite altijd het adres van de Remote MCP Server van tevoren kennen. Als dat zo is, zal het specificeren van Client ID terwijl het doorgeven van het Remote MCP Server-adres niet veel extra problemen veroorzaken. Of, we kunnen ook een conventie creëren voor MCP Client om MCP Server om Client ID te vragen, wat geen moeilijke taak is.

Hoewel Dynamische Clientregistratie theoretisch flexibiliteit biedt voor het MCP-ecosysteem, moeten we in de praktijk overwegen of we dit dynamische registratiemechanisme echt nodig hebben. Voor de meeste dienstverleners kan het handmatig aanmaken en beheren van OAuth Client een meer controleerbare en veilige manier zijn.

Samenvatting#

Dit artikel analyseert diepgaand de ontwerpfilosofie en implementatie-uitdagingen van de MCP Authorization Spec. Als een autorisatieframework gebaseerd op OAuth 2.1, is deze specificatie bedoeld om het kernprobleem op te lossen van hoe Remote MCP Server toegang krijgt tot gebruikersbronnen namens gebruikers.

Door gedetailleerde discussie over de dubbele rollen van MCP Server als Authorization Server en Resource Server, evenals de voor- en nadelen van mechanismen zoals Dynamische Clientregistratie en derde partij autorisatie, biedt dit artikel gedachten en suggesties vanuit persoonlijke ervaring in het implementeren van Authenticator.

Het is vermeldenswaard dat de MCP-autorisatiespecificatie nog steeds in ontwikkeling is. Als lid van het Logto-team zullen we de laatste ontwikkelingen van deze specificatie blijven volgen en voortdurend onze implementatie-oplossingen in de praktijk optimaliseren om bij te dragen aan de veilige interactie tussen AI-modellen en externe diensten.