Autentisering är det mest kritiska säkerhetslagret för fjärr-MCP-servrar. Lär dig varför OAuth 2.1 med OIDC är obligatoriskt, hur tokendelegering förhindrar attacken med den förvirrade ställföreträdaren, och varför token passthrough är ett av de farligaste mönstren i AI-integrationer.
Autentisering är den grindvakt som avgör om en MCP-servers kraftfulla funktioner är tillgängliga för legitima användare eller för angripare. Gör fel, och alla andra säkerhetskontroller blir irrelevanta — en oautentiserad eller dåligt autentiserad MCP-server med åtkomst till e-post, filer och databaser är en kritisk sårbarhet oavsett hur väl du har härdat allt annat.
OWASP GenAI Security Projects guide identifierar autentisering och auktorisering som en av de åtta kärndomänerna för säkerhet för MCP-servrar, med specifika krav som går bortom vad de flesta utvecklare implementerar som standard. Detta inlägg förklarar varför dessa krav finns och hur man implementerar dem korrekt.
MCP-servrar står inför ett mer komplext autentiseringslandskap än traditionella tjänster eftersom de förmedlar mellan flera huvudmän:
Var och en av dessa relationer kräver sina egna autentiserings- och auktoriseringskontroller. En svaghet i någon länk kan utnyttjas för att kringgå de andra.
För fjärr-MCP-servrar — de som nås över ett nätverk snarare än genom lokala STDIO- eller Unix-sockets — är OWASP GenAI-guiden otvetydig: OAuth 2.1 med OIDC är obligatoriskt, inte valfritt.
Detta krav finns eftersom:
OAuth 2.1 tillhandahåller explicit scopekontroll. Varje åtkomsttoken deklarerar exakt vilka resurser och åtgärder den auktoriserar. En MCP-server kan vid verktygsanropstillfället verifiera att den presenterade token har det specifika scope som behövs för den åtgärden — inte bara att användaren är autentiserad, utan att de är auktoriserade för just denna specifika operation.
OIDC tillhandahåller kryptografisk identitet. OpenID Connect lägger till identitetsförsäkringar (ID-token) som MCP-servern kan verifiera utan att göra en rundtur till identitetsleverantören. Servern validerar iss (utfärdare), aud (målgrupp), exp (utgång) och signatur vid varje begäran.
OAuth 2.1-tokens är kortlivade av design. Den moderna OAuth-specifikationen (som konsoliderar och ersätter OAuth 2.0 bästa praxis) betonar kortlivade åtkomsttokens som måste uppdateras regelbundet. Detta begränsar skadans fönster om en token komprometteras.
Validera inte tokens endast vid sessionsupprättande. Validera vid varje verktygsanrop:
def validate_token(token: str, required_scope: str) -> TokenClaims:
claims = jwt.decode(
token,
key=get_public_key(claims_preview['kid']),
algorithms=["RS256", "ES256"]
)
assert claims['iss'] == EXPECTED_ISSUER
assert EXPECTED_AUDIENCE in claims['aud']
assert claims['exp'] > time.time()
assert required_scope in claims['scope'].split()
return claims
Cacha aldrig valideringsresultat över förfrågningar. En token som var giltig vid sessionens start kan återkallas mitt i sessionen.
I miljöer där MCP-klienter ändras ofta (t.ex. olika AI-assistenter som ansluter till samma server) är statiska API-nycklar eller fördelade hemligheter otillräckliga. Använd dynamisk klientregistrering med OAuth 2.1 eller OIDC för att verifiera klientidentitet vid anslutningstillfället. Tillåtna listor, hårdkodade anslutningspolicyer eller ömsesidig TLS (mTLS) är lämpliga för kända statiska relationer mellan specifika klienter och servrar.
Starta din kostnadsfria provperiod idag och se resultat inom några dagar.
Den förvirrade ställföreträdaren är en klassisk auktoriseringssårbarhet med en särskilt farlig manifestation i MCP-arkitekturer. Attacken utnyttjar tvetydigheten i vems auktoritet en MCP-server agerar med.
Tänk dig detta scenario:
När Alice ber AI-assistenten att “sammanfatta min projektmapp” använder servern Alices token för att komma åt hennes filer — korrekt beteende. Men om en angripare lurar servern att göra en begäran med sina egna tjänsteautentiseringsuppgifter (kanske genom en verktygsförgiftningsattack eller indirekt prompt-injektion), används serverns förhöjda behörigheter för att komma åt filer som Alice inte är auktoriserad att se.
Servern är den “förvirrade ställföreträdaren” — den har lurat sig att använda sin auktoritet på uppdrag av någon som inte har den auktoriteten, och agerar som en proxy för privilegieeskalering.
Många MCP-implementeringar vidarebefordrar klientens token till nedströms-API:er för enkelhetens skull. Detta verkar intuitivt — användarens token representerar användarens behörigheter, så att använda den för alla nedströmsanrop upprätthåller korrekt åtkomstkontroll.
Problemet: nedströms-API:er som känner igen MCP-servern som en betrodd mellanhand kan bevilja förfrågningar med serverns identitetsnivå, inte den vidarebefordrade användartokens nivå. Och om MCP-servern någonsin agerar på eget initiativ — genom AI-beslutsfattande som användaren inte uttryckligen begärde — kan den använda sina egna autentiseringsuppgifter snarare än användarens token.
Att vidarebefordra användartokens:
Istället för att vidarebefordra klienttokens bör MCP-servern erhålla sina egna tokens för nedströms tjänståtkomst med hjälp av OAuths On-Behalf-Of (OBO)-flöde:
Användaren autentiserar till MCP-klienten → klienten får användaråtkomsttoken
MCP-klienten presenterar användartoken för MCP-servern
MCP-servern byter ut användartoken mot en servertoken via OBO-flöde:
POST /token
grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
assertion=<user_access_token>
scope=<minimum_required_scope>
MCP-servern använder sin egen OBO-token för nedströmsanrop
OBO-token:
OWASP GenAI-guiden ger en specifik rekommendation: utfärda åtkomsttokens med livslängder mätta i minuter, inte timmar. Detta gäller både de tokens som MCP-servern accepterar från klienter och de tokens den erhåller för nedströms tjänståtkomst.
En stulen åtkomsttoken är giltig under hela sin livslängd oavsett om den legitima användaren har loggat ut, ändrat sitt lösenord eller återkallat sin session. En 24-timmars token som stulits i början av en session ger en angripare 24 timmars ihållande åtkomst. En 5-minuters token som stulits mitt i sessionen ger högst 5 minuter.
Kortlivade tokens upprätthåller också regelbundna återautentiseringshändelser, som ger möjligheter att:
Varje token bör endast bära de scopes som behövs för den specifika operationen som utförs. Utfärda inte en token med read:files write:files delete:files scope när det aktuella verktygsanropet bara behöver read:files. Detta begränsar skadan om token fångas upp eller modellen manipuleras till oväntade verktygsanrop.
def get_tool_token(user_id: str, tool_name: str) -> str:
# Mappa verktyg till minimalt nödvändiga scopes
required_scopes = TOOL_SCOPE_MAP[tool_name]
return oauth_client.get_token(
subject=user_id,
scopes=required_scopes,
lifetime_seconds=300 # 5 minuters livslängd
)
Få de senaste tipsen, trenderna och erbjudandena gratis.
Ett vanligt misstag är att använda sessions-ID som auktoriseringsproxyer: om en begäran bär ett giltigt sessions-ID antar servern att den är auktoriserad. Detta blandar ihop tillståndshantering med identitetsverifiering.
Den korrekta modellen: sessions-ID hanterar konversationstillstånd. Auktorisering verifieras oberoende vid varje begäran genom att validera OAuth-tokens anspråk. Även en begäran som bär ett giltigt sessions-ID måste presentera en giltig, icke-utgången, korrekt scopad OAuth-token innan något verktygsanrop tillåts.
Detta spelar roll eftersom sessions-ID kan stjälas, gissas eller spelas upp igen på sätt som OAuth-tokens — som bär kryptografiska integritetsgarantier — inte kan.
Snarare än att implementera auktoriseringskontroller utspridda genom enskilda verktygshanterare, rekommenderar OWASP GenAI-guiden en centraliserad policygateway som:
Centralisering säkerställer att policyer tillämpas konsekvent över alla verktyg och agenter. En verktygsspecifik auktoriseringskontroll kan glömmas bort eller kringgås under utvecklingen; en gateway-kontroll kan inte.
För fjärr-MCP-servrar är den minsta säkerhetsnivån för autentisering:
Arshia är en AI-arbetsflödesingenjör på FlowHunt. Med en bakgrund inom datavetenskap och en passion för AI, specialiserar han sig på att skapa effektiva arbetsflöden som integrerar AI-verktyg i vardagliga uppgifter, vilket förbättrar produktivitet och kreativitet.
Vårt säkerhetsteam bedömer MCP-autentiseringskonfigurationer, tokenhantering och auktoriseringsflöden mot OWASP GenAI-standarder. Identifiera luckor innan angripare gör det.
OWASP GenAI Security Project definierar en minimistandard i fem kategorier för säker MCP-serverdistribution. Använd denna checklista för att bedöma din nuvarand...
MCP-servrar exponerar en unik attackyta som kombinerar traditionella API-risker med AI-specifika hot. Lär dig de 6 kritiska sårbarheterna som identifierats av O...
Authenticator App MCP-server möjliggör för AI-agenter att säkert komma åt 2FA-koder och lösenord, vilket förenklar automatiserade inloggningsprocesser och hante...
Cookie-samtycke
Vi använder cookies för att förbättra din surfupplevelse och analysera vår trafik. See our privacy policy.