Guide för att implementera MCP-serverautentisering: enligt den senaste specifikationen

För några dagar sedan (18 juni 2025) släppte MCP-teamet (Model Context Protocol) den senaste versionen av MCP-specifikationen (2025-06-18). Denna uppdatering innehåller en viktig förändring i auth-specifikationen. MCP-servrar kommer inte längre att utfärda åtkomsttoken som en Authorization Server. Istället kommer de att konsumera åtkomsttoken och tillhandahålla resurser som en Resource Server.

Som en av underhållarna till MCP Auth (ett plug-and-play MCP-serverbibliotek för autentisering) har jag implementerat stöd för den senaste MCP-auth-specifikationen i detta projekt. Baserat på min praktiska erfarenhet kommer jag visa dig hur du implementerar autentiseringsfunktioner för din MCP-server som uppfyller de senaste specifikationerna.

Denna artikel hjälper dig att:

• Förstå hur MCP-auth fungerar enligt den nya MCP-auth-specifikationen
• Klargöra vad MCP-servrar behöver implementera som Resource Servers enligt MCP-auth-specens krav
• Ge vägledning för att implementera auth-stöd som uppfyller de senaste MCP-auth-specifikationskraven för din MCP-server
• Identifiera förbisedda aspekter och säkerhetsproblem när MCP-auth-specen implementeras

Observera att denna artikel:

• Förutsätter att läsaren har grundläggande kunskaper om JWT (JSON Web Token). Artikeln går inte in på JWT-struktur, signaturverifiering, och andra basala begrepp i detalj. För mer detaljer, se Auth Wiki - JWT
• Går inte djupt in på olika RFC:er som MCP-auth-specen bygger på. Den ger endast implementationer som följer dessa RFC-krav
• Täcker inte detaljer kring implementation och interaktion för MCP-klient och auktorisering. Dessa implementeras vanligtvis av LLM-klienter och auktoriseringsserverleverantörer som stöder MCP enligt MCP-specifikationer. MCP-serverutvecklare behöver och kan inte lägga sig i dessa implementationer. För mer detaljer, se OAuth Client och Authorization Server
• Alla åtkomsttoken som nämns i artikeln antas vara JWT, vilket är det mest använda formatet på marknaden. Om du använder andra former av token, använd dokumentationen från din auktoriseringsserver-leverantör.

Hur fungerar MCP-auth?#

Enligt den senaste MCP-auth-specen, ser MCP-auth-flödet ut enligt följande diagram:

1. MCP-klienten begär resurser från MCP-servern på https://github-tools.com. Eftersom användaren inte är inloggad än innehåller inte denna förfrågans HTTP-authorization-header en åtkomsttoken för användaren.

2. MCP-servern kan inte hämta någon åtkomsttoken från authorization-header i MCP-klientens förfrågan. Den returnerar ett HTTP 401-fel till MCP-klienten. Detta felmeddelande innehåller en WWW-Authenticate-header där serverns resource metadata-URL anges (värdet för fältet resource_metadata).

3. MCP-klienten extraherar värdet för resource_metadata från den mottagna WWW-Authenticate-headern (t.ex. https://github-tools.com/.well-known/oauth-protected-resource). Sedan begär MCP-klienten resursmetadata från MCP-servern som en Resource Server på denna adress. Denna metadata innehåller t.ex. authorization_servers och scopes_supported, vilket hjälper klienten förstå hur den kan få en åtkomsttoken som krävs för att komma åt MCP-servern och från vilken auktoriseringsserver den kan få en token med vissa behörigheter.

4-8. MCP-klienten begär auktoriseringsserverns metadata baserat på metadata-URLen från resursmetadatan. Därefter genomför MCP-klienten ett OAuth 2.1-auktoriseringsflöde och hämtar en åtkomsttoken efter slutförd auktorisering.

9. MCP-klienten använder åtkomsttoken från auktoriseringsservern och gör en ny resursförfrågan till MCP-servern.

10. MCP-servern svarar med resursen efter att ha verifierat att token är giltig. Därefter fortsätter kommunikationen mellan MCP-klienten och MCP-servern med giltig token.

Härnäst kommer vi steg för steg gå igenom hur du implementerar MCP-serverns auth-mekanik utifrån MCP-auth-flödet.

Hantera obehöriga förfrågningar: returnera 401-fel och WWW-Authenticate-header#

Som visas ovan, när MCP-klienten skickar en förfrågan utan åtkomsttoken till MCP-servern, skall MCP-servern returnera ett HTTP 401 Unauthorized meddelande med en WWW-Authenticate-header som innehåller en URL till serverns resursmetadata.

Enligt MCP-auth-specens felhantering ska, förutom förfrågningar som saknar åtkomsttoken, MCP-servern också returnera ett 401-fel med en WWW-Authenticate-header när den får en ogiltig åtkomsttoken.

När vi nu vet när 401 ska returneras – hur bygger vi då den returnerade WWW-Authenticate-headern?

Enligt RFC9728 Avsnitt 5.1 måste WWW-Authenticate-headern innehålla en resource_metadata-parameter som pekar på URL:en till den skyddade resursmetadatan.

Dess basformat är:

Här är Bearer autentiseringsschemat, vilket betyder att en bearer token krävs för att komma åt OAuth 2.0-skyddade resurser (se: MDN-dokumentation). Värdet för resource_metadata är den fullständiga URL:en till resursmetadata-endpointen som tillhandahålls av din MCP-server.

Den faktiska kodimplementationen kan se ut så här:

När MCP-klienten får detta 401-fel kommer den att begära MCP-serverns resursmetadata via värdet resource_metadata från WWW-Authenticate-headern. Med denna metadata kan den sedan starta en auktoriseringsbegäran till angiven auktoriseringsserver för att hämta en åtkomsttoken för MCP-servern.

Nu vet vi när vi ska returnera ett 401-fel, och att vi behöver returnera en resource_metadata-URL. Men vi vet ännu inte hur denna URL byggs upp och vilket innehåll som krävs i metadatan – det går vi igenom nu.

Implementera mekanism för upptäckt av resursmetadata#

Enligt MCP-auth-flödet frågar MCP-klienten direkt efter resursmetadata från MCP-servern efter ett 401-fel. MCP-servern ska alltså implementera en mekanism för upptäckt av resursmetadata som Resource Server.

Bestäm URL-sökvägen för metadata-endpoint#

Inom OAuth-systemet används URL:er för att identifiera resurser. Denna adress kallas "resource indicator". Enligt RFC9728 ska resursmetadata exponeras under en specifik /.well-known-sökväg.

Om din MCP-server (som https://github-tools.com) endast erbjuder en tjänst, bör metadatapunkten vara:

Om du erbjuder flera olika MCP-tjänster på samma värd bör varje tjänst ha en egen metadata-endpoint. Exempelvis erbjuder företagsplattformen https://api.acme-corp.com följande tjänster:

• https://api.acme-corp.com/github – GitHub-integrering
• https://api.acme-corp.com/slack – Slack-integrering
• https://api.acme-corp.com/database – Databassökningstjänst

Matchande metadata-endpoints bör då vara:

• https://api.acme-corp.com/.well-known/oauth-protected-resource/github
• https://api.acme-corp.com/.well-known/oauth-protected-resource/slack
• https://api.acme-corp.com/.well-known/oauth-protected-resource/database

Denna design möjliggör olika behörighetsområden och konfigurationer för auktoriseringsservrar för varje tjänst. Till exempel:

• GitHub-tjänsten använder GitHub OAuth-server, och kräver github:read, github:write
• Slack-tjänsten använder Slack OAuth-server, och kräver slack:channels:read, slack:messages:write
• Databastjänsten använder företagets interna auktoriseringsserver, och kräver db:query

Därför följer adresser till metadata-endpoints detta mönster:

Du kan skapa metadata-endpoint-URL för en resurs baserat på dess identifierare på detta sätt:

Bygg svar för resursmetadata#

Efter att ha fastslagit endpoint-URL behöver vi göra så att endpointen returnerar JSON-metadata som följer RFC9728.

I praktiken är fyra kärnfält viktiga.

Först: resource-fältet, som ska vara resursens identifierare, och matcha resursadressen klienten vill nå.

Därefter: authorization_servers-fältet, en array som anger från vilka auktoriseringsservrar klienten ska hämta access tokens. Enligt OAuth 2.0 Protected Resource Metadata (RFC 9728) är detta valfritt – men MCP-auth-specen kräver det för att klienten ska veta vilken auktoriseringsserver den ska begära auktorisering från.

Sedan: scopes_supported, en lista över alla behörighetsområden som stöds av denna Resource Server.

Slutligen: bearer_methods_supported, som talar om för klienten på vilket sätt MCP-servern accepterar access tokens. Vanligen sätts detta till ["header"], vilket indikerar att token ska skickas via HTTP Authorization-headern.

Exempel: Om du vill konfigurera resursmetadata för https://github-tools.com MCP-servern:

Med denna konfiguration får klienten reda på: Den vill nå resursen https://github-tools.com, måste be om en token från https://auth.github-tools.com, de tillgängliga permissions är github:read, github:write, repo:admin, och tokenen ska skickas i HTTP Authorization-headern.

För de allra flesta användningsfall räcker det att konfigurera dessa fyra basala fält för att MCP-klienten ska fungera korrekt. Om du behöver mer avancerad konfiguration, se hela fältlistan i RFC9728.

Validera åtkomsttoken#

När MCP-klienten fått en åtkomsttoken från auktoriseringsservern använder den tokenen för att komma åt MCP-servern.

Vid validering av access tokens i MCP-servrar, tänk på detta:

1. Vid grundläggande tokenvalidering ska valideringen utgå från MCP-serverns egen konfiguration, inte efter uppgifter i tokenen
2. Kontrollera att tokenens målgrupp (audience) är MCP-servern själv, så att tokenen verkligen ska användas till denna servers resurser
3. Hantera scope-validering korrekt

Använd MCP-serverns konfiguration för att validera access tokens#

När MCP-servern får en access token – eftersom denna innehåller issuer-information – gör vissa utvecklare misstaget att utgå från tokenens issuer för att lista ut hur tokenen ska verifieras. Det är problematiskt om resursmetadatan stöder flera auktoriseringsservrar:

I detta fall kan en angripare skapa en falsk auktoriseringsserver och utfärda falska tokens. Om utvecklaren bara litar på den issuer som uppges i tokenen finns säkerhetsrisk: token kan valideras mot angriparens egna server.

Därför gäller:

• Om det bara finns en auktoriseringsserver konfigurerad, validera token utifrån denna
• Om flera servrar finns, jämför issuer från den otestade tokenen mot konfigurerade servrar och använd bara dessa för validering – om ingen match, förkasta tokenen

Validera alltid att tokenens issuer är korrekt.

Exempel med jose-JWT-biblioteket:

Validera tokenens audience#

Avsnittet Token Audience Binding and Validation i MCP-auth-specen säger att klienten måste ange resursen resource när token begärs från auktoriseringsservern. MCP-servern måste sedan kontrollera att denna tokens audience verkligen är sig själv.

Detta bygger på Resource Indicators for OAuth 2.0 (RFC 8707). Flödet:

1. Begäran: Klienten anger resource till auktoriseringsservern (t.ex. https://github-tools.com)
2. Token-utgivning: Auktoriseringsservern binder denna adress till tokenen (i JWT är detta aud i payload)
3. Validering: MCP-servern verifierar att JWT:s aud matchar sin egen identifierare

Exempel:

Denna audience-validering är en central säkerhetsåtgärd mot tokenmissbruk. Utan denna prövning kan angripare försöka använda tokens avsedda för andra tjänster mot din MCP-server.

Scope-validering#

Vissa MCP-servrar hanterar åtkomst för interna resurser, där olika användare har olika behörigheter.

När access tokenen klarat valideringen behöver du kontrollera att tokenen innefattar rätt scope. Detta görs vanligtvis så här:

Obs: MCP-auth-specen kräver att 403 Forbidden returneras när tokenen saknar access scope för önskad resurs.

Slutsats#

Efter denna genomgång kan du implementera autentiseringsfunktioner enligt den senaste specen för din MCP-server. Kom ihåg: validera tokens säkert, konfigurera metadata korrekt och verifiera audience strikt.

Om du bygger en MCP-server, prova biblioteket MCP Auth. Det har redan implementerat allt som diskuterats i artikeln, och hjälper dig integrera auth-stöd snabbt.

Välkommen att diskutera frågor på GitHub. Låt oss bygga MCP-ekosystemet tillsammans.