Djupgående granskning av MCP-auktoriseringsspecifikationen (2025-03-26 års utgåva)

MCP (Model Context Protocol) är en öppen standard som tillåter AI-modeller att interagera med externa verktyg och tjänster. Den är allmänt antagen av industrin. Eftersom MCP stödjer HTTP-baserade transportmetoder, kommer den fjärr-MCP-servern att spela en allt viktigare roll i MCP-ekosystemet.

Till skillnad från lokal MCP-Server, som tillåter varje användare att köra sin egen serverinstans, kräver fjärr-MCP-Server att alla användare delar samma MCP-server-tjänst. Detta tar upp det centrala problemet som MCP-auktoriseringsspecifikationen syftar till att lösa: hur man tillåter MCP-servern att komma åt användarresurser på användarens vägnar.

Denna artikel kommer att analysera MCP-auktoriseringsspecifikationen på djupet. Den kommer att hjälpa dig att förstå designprinciperna för MCP-auktoriseringsspecifikation och vissa riktningar för att implementera MCP-auktorisering. Eftersom denna specifikation fortfarande utvecklas, kommer jag att dela med mig av några tankar baserat på min personliga erfarenhet av att implementera Authenticator, inklusive:

• Fördelar och begränsningar hos OAuth 2.1 som en auktoriseringsram
• Utmaningar med MCP-serverns dubbla roller som både auktoriseringsserver och resursserver
• Praktisk komplexitet i att implementera en fullständig auktoriseringsserver
• Analys av lämpliga scenarier för delegerad auktorisering från tredje part
• Praktiska kompromisser med dynamisk klientregistrering
• Viktighet av att tydligt definiera MCP-serverns resursgränser

Översikt över MCP-auktoriseringsspecifikationen#

MCP-auktoriseringsspecifikationen definierar autentiseringsprocessen mellan MCP-server (fjärr) och MCP-klient.

Jag tycker att basera denna specifikation på OAuth 2.1 är ett mycket rimligt val. OAuth som en auktoriseringsprotokollram löser problemet med hur man tillåter användare att auktorisera tredjepartsapplikationer för att få tillgång till användarresurser på deras vägnar. Om du inte är bekant med OAuth, kan du kolla AuthWiki-OAuth för mer information.

I scenariot med MCP-klient och MCP-server handlar det om "användare som auktoriserar MCP-klienten att komma åt användarresurser på MCP-servern". "Användarresurserna på MCP-servern" avser för närvarande främst verktyg som tillhandahålls av MCP-servern eller resurser tillhandahållna av MCP-serverns backend-tjänster.

För att implementera OAuth 2.1 autentiseringsprocessen kräver protokollet att en MCP-server tillhandahåller följande gränssnitt för att arbeta med MCP-klient för att slutföra OAuth 2.1 autentiseringsprocessen:

• /.well-known/oauth-authorization-server: OAuth-servicemetadata
• /authorize: auktoriseringsslutpunkt, används för auktoriseringsförfrågningar
• /token: token-slutpunkt, används för tokenutbyte och förnyelse
• /register: klientregistreringsslutpunkt, används för dynamisk klientregistrering

Autentiseringsprocessen är som följer:

Specifikationen anger också hur MCP-servern stödjer delegerad auktorisering genom tredjepartts-auktoriseringsservrar.

Exempelflödet i specifikationen är som följer (från specifikationsinnehållet):

I detta scenario, även om MCP-servern delegerar auktorisering till en tredjeparts-auktoriseringsserver, agerar MCP-servern fortfarande som en auktoriseringsserver för MCP-klienten. Detta beror på att MCP-servern behöver utfärda sin egen åtkomsttoken till MCP-klienten.

Enligt min mening verkar detta scenario mer lämpligt för att hantera situationer där MCP-servern proxyar MCP-klient (användare) för att komma åt tredjepartsresurser (såsom Github-repos), snarare än att MCP-servern proxyar MCP-klient (användare) för att komma åt MCP-serverns egna resurser.

Sammanfattningsvis, enligt protokollet, har MCP-servern både rollerna som auktoriseringsserver och resursserver i OAuth.

Nästa, låt oss diskutera MCP-serverns ansvar som auktoriseringsserver och resursserver.

MCP Server som auktoriseringstjänst#

När MCP-servern agerar som auktoriseringsserver, betyder det att slutanvändaren av MCP-klienten har sin egen identitet på MCP-servern. MCP-servern ansvarar för att autentisera denna slutanvändare och utfärda en åtkomsttoken till denna slutanvändare för att få tillgång till MCP-serverresurser.

De auktoriseringsrelaterade gränssnitt som krävs av MCP-auktoriseringsspecifikationen nämnda ovan innebär att MCP-servern måste tillhandahålla en implementation av en auktoriseringsserver.

Men att implementera funktionaliteten för auktoriseringsserver på MCP-servern är en betydande utmaning för utvecklare. Å ena sidan, är de flesta utvecklare kanske inte bekanta med OAuth-relaterade koncept. Å andra sidan finns det många detaljer att ta hänsyn till vid implementeringen av en auktoriseringsserver. Om en utvecklare inte kommer från ett relaterat område kan de introducera problem såsom säkerhetsproblem under implementeringen.

Men protokollet själv begränsar inte MCP-server till att bara implementera sin egen funktionalitet som en auktoriseringsserver. Utvecklare kan helt enkelt omdirigera eller proxya dessa auktoriseringsrelaterade slutpunkter till andra auktoriseringsservrar. Detta är ingen skillnad för MCP-klient än MCP-servern implementerar funktionaliteten för auktoriseringsserver själv.

Du kanske undrar, borde denna metod använda det delegerade tredjepartsauktoriseringsmetoden som nämns ovan?

Från min synvinkel beror detta främst på om användarna av den tredjepartsauktoriseringstjänst du förlitar dig på är desamma som MCP-serverns slutanvändare. Detta betyder att åtkomsttoken som utfärdas till dig av tredjepartsauktoriseringstjänsten kommer att förbrukas direkt av din MCP-server.

• Om ja, då kan du helt vidarebefordra de auktoriseringsrelaterade gränssnitten i din MCP-server till tredjepartsauktoriseringstjänster.

• Om nej, då borde du använda det delegerade tredjepartsauktoriseringsmetoden som specificeras i specifikationen. Du behöver upprätthålla en korrelation mellan åtkomsttoken utfärdade av din egen MCP-server och åtkomsttoken utfärdade av tredjepartsauktoriseringstjänster i MCP-servern.

Jag tycker att det delegerade tredjepartsauktoriseringsmetoden som specificeras i protokollet är något vagt i praktiska tillämpningsscenarier. Protokollet verkar låta tredje parter hjälpa MCP-server att slutföra auktoriseringsprocessen, men kräver fortfarande att MCP-servern utfärdar sin egen åtkomsttoken. Detta betyder faktiskt att MCP-servern fortfarande bär ansvaret för att utfärda åtkomsttoken som auktoriseringsserver, vilket inte är mer bekvämt för utvecklare. Jag tror att det förmodligen är för att författarna av protokollet övervägde att direkt returnera tredjeparts åtkomsttoken till MCP-klienten skulle medföra vissa säkerhetsproblem (såsom läckage/missbruk, etc.).

Utifrån min erfarenhet, borde det mest lämpliga scenariot för det delegerade tredjepartsauktoriseringsmetoden i protokollet vara scenariot "hur användare auktoriserar MCP-servern att komma åt användarnas resurser på tredjepartsresursservrar". Till exempel behöver en MCP-server få tillgång till en användares Github-repo och distribuera repots kod till en koddistributionsplattform. I detta fall behöver användaren auktorisera MCP-servern att få tillgång till deras Github-repo och för att få tillgång till koddistributionsplattformen.

I detta scenario är MCP-servern en auktoriseringsserver för MCP-klienten, eftersom slutanvändare har sin egen identitet i MCP-servern. MCP-servern är en tredjepartsklient för tredjepartsresurser (i detta fall Github). Den behöver få användarauktorisering för att få tillgång till användares resurser på Github. Mellan MCP-klient och MCP-server, och mellan MCP-server och tredjepartsresurser, är användaridentiteter separerade. Detta gör det meningsfullt att upprätthålla en korrelation mellan åtkomsttoken utfärdade av MCP-servern själv och åtkomsttoken utfärdade av tredjepartsauktoriseringstjänster i MCP-servern.

Så den delegerade tredjepartsauktoriseringsmetoden i protokollet bör lösa problemet "hur användare auktoriserar MCP-server att komma åt användares resurser på tredjepartsresursservrar".

MCP-server som resursserver#

När MCP-servern agerar som resursserver, behöver MCP-servern verifiera om MCP-klientens förfrågan bär en giltig åtkomsttoken. MCP-servern kommer att bestämma om MCP-klienten får tillgång till specifika resurser baserat på omfattningen av åtkomsttoken.

Enligt MCP:s definition, bör de resurser som tillhandahålls av MCP-servern vara verktyg för MCP-klienten att använda. I detta scenario behöver MCP-servern bara bestämma om den ska tillhandahålla användare tillgång till vissa verktyg.

Men i verkliga scenarier, behöver dessa verktyg som tillhandahålls av MCP-servern också interagera med resursservern hos MCP-serverns tjänsteleverantör själv. Vid denna tidpunkt behöver åtkomsttoken erhållen av MCP-servern från klientens förfrågan användas för tillgång till sina egna resursservrar. I de flesta fall är MCP-servern och resursservern bakom verktygen samma utvecklare. MCP-servern är bara ett gränssnitt tillhandahållet av sina egna backendresurser för MCP-klienten att använda. Vid denna tidpunkt kan MCP-servern dela samma åtkomsttoken utfärdad av en auktoriseringsserver med backendresurser.

I detta fall, snarare än att säga MCP-servern är en resursserver, tillhandahållande verktyg och sin egen tjänsts resurs, är det bättre att säga att den befintliga resursservern blir en MCP-server genom att tillhandahålla verktyg för MCP-klienten att kalla.

Att inkludera resurser tillhandahållna av sin egen resursserver i resurser tillhandahållna av MCP-servern är mer från överväganden kring verkliga scenarier. Men jag personligen föredrar att resurser tillhandahållna av MCP-servern bara har verktyg som används av MCP-klienten, och resurser som verktygen är beroende av bör vara resurser erhållna av MCP-servern från andra resursservrar (inklusive egna och tredjepartsresurser). På detta sätt kan alla verkliga scenarier täckas.

Hur MCP-auktorisering fungerar#

Efter att ha förstått ansvaren för MCP-servern som auktoriseringsserver och resursserver, kan vi veta hur MCP-auktorisering specifikt fungerar:

Dynamisk klientregistrering#

Specifikationen definierar också hur auktoriseringsservern identifierar klienter. OAuth 2.1 tillhandahåller protokollet för dynamisk klientregistrering, vilket gör det möjligt för MCP-klienten att automatiskt erhålla OAuth-klient-ID utan manuell användarintervention.

Enligt specifikationen bör MCP-servern stödja protokollet för dynamisk klientregistrering av OAuth 2.0. På detta sätt kan MCP-klienten automatiskt registrera sig hos nya servrar för att erhålla OAuth-klient-ID. Denna metod rekommenderas i MCP-scenarier främst eftersom:

• MCP-klienten inte kan känna till alla möjliga servrar i förväg
• Manuell registrering skulle orsaka besvär för användarna
• Det gör anslutning med nya servrar sömlös
• Servrar kan implementera sina egna registreringspolicyer

Men från ett praktiskt perspektiv, har jag några tankar om tillämpningen av dynamisk klientregistrering i MCP-scenarier:

• I praktiska OAuth-servicetillämpningar, motsvarar en klient vanligtvis en specifik affärsapp. Att skapa klienter dynamiskt kanske inte är fördelaktigt för att effektivt hantera relaterade resurser (användare, app, etc.) i OAuth-tjänster. OAuth-tjänsteleverantörer hoppas vanligtvis ha tydlig kontroll över anslutna klienter, snarare än att låta vem som helst registrera sig som en klient vid vilja.
• Många OAuth-tjänster rekommenderar inte eller tillåter användare att dynamiskt skapa klienter, eftersom detta kan leda till missbruk av tjänsten. De flesta mogna OAuth-tjänsteleverantörer (såsom GitHub, Google, etc.) kräver att utvecklare manuellt registrerar klienter genom deras utvecklarkonsol, och kan också behöva tillhandahålla detaljerad information om applikationen, callback URL, etc.
• Manuell registrering av OAuth-klient är faktiskt ett engångsjobb under utvecklingen, inte något som varje slutanvändare behöver göra. Det kommer inte att vara en stor börda för utvecklare.
• För offentliga klienter (såsom inbyggda applikationer, en-sidiga applikationer, etc.), har vi säkrare sätt att implementera OAuth-flöde utan dynamisk registrering. Klient-ID kombinerat med PKCE (Proof Key for Code Exchange) kan tillhandahålla ett tillräckligt säkert OAuth-flöde för offentliga klienter utan att dynamiskt skapa klienter.
• Även om protokollet påpekar att användning av dynamisk klientregistrering kan undvika att klienter behöver känna till klient-ID i förväg, i själva verket behöver MCP-klienten alltid känna till adressen för fjärr-MCP-servern i förväg. Om så är fallet, kommer specificering av klient-ID samtidigt som man anger adressen för fjärr-MCP-servern inte medföra stora extra besvär. Eller, vi kan också skapa en konvention för MCP-klienten att be MCP-servern om klient-ID, vilket inte är en svår uppgift.

Även om dynamisk klientregistrering teoretiskt ger flexibilitet för MCP-ekosystemet, i praktisk implementation, kan vi behöva överväga om vi verkligen behöver denna dynamiska registreringsmekanism. För de flesta tjänsteleverantörer, kan manuell skapande och hantering av OAuth-klienter vara ett mer kontrollerbart och säkert sätt.

Sammanfattning#

Denna artikel analyserar på djupet designfilosofin och implementeringsutmaningarna för MCP-auktoriseringsspecifikationen. Som ett auktoriseringsramverk baserat på OAuth 2.1, syftar denna specifikation till att lösa det centrala problemet med hur fjärr-MCP-servern får tillgång till användarresurser på användarnas vägnar.

Genom en detaljerad diskussion om MCP-serverns dubbla roller som auktoriseringsserver och resursserver, samt för- och nackdelarna med mekanismer som dynamisk klientregistrering och delegerad auktorisering från tredje part, ger denna artikel tankar och förslag från personlig erfarenhet av att implementera Authenticator.

Det är värt att notera att MCP-auktoriseringsspecifikationen fortfarande utvecklas. Som medlem av Logto-teamet, kommer vi att fortsätta att uppmärksamma de senaste utvecklingarna av denna specifikation och kontinuerligt optimera våra implementationslösningar i praktiken för att bidra till säker interaktion mellan AI-modeller och externa tjänster.