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:
OAuth 2.1 krävs för fjärr-MCP-servrar eftersom det tillhandahåller delegerad auktorisering med explicit scopekontroll, kortlivade tokens, kryptografisk verifiering och standardiserade identitetsförsäkringar (via OIDC). Enklare metoder som API-nycklar eller sessionskakor saknar den scopegranularitet som behövs för att implementera åtkomst med minsta privilegium, tillhandahåller inte kryptografiska identitetsgarantier och är svåra att återkalla granulerat när en session avslutas.
Den förvirrade ställföreträdaren är en attack för privilegieeskalering där MCP-servern luras att använda sina egna (högre) privilegier för att utföra åtgärder som den begärande användaren inte är auktoriserad att utföra. Det inträffar när token passthrough används — servern vidarebefordrar en användares token till nedströms-API:er, vilket kan ge användaren åtkomst som de inte borde ha baserat på serverns betrodda status. Lösningen är att använda On-Behalf-Of-tokenflöden där tokens uttryckligen utfärdas för MCP-serverns specifika åtkomstscope.
Token passthrough innebär att MCP-servern vidarebefordrar klientens autentiseringstoken direkt till nedströms-API:er, snarare än att använda sina egna serverutfärdade autentiseringsuppgifter. Detta är farligt eftersom: (1) det bryter revisionsspår — nedströmssystem ser användartoken, inte MCP-servern, vilket gör det omöjligt att tillskriva åtgärder till servern; (2) det kringgår MCP-serverns egna åtkomstpolicyer; (3) det skapar en sårbarhet för den förvirrade ställföreträdaren om nedströms-API:et litar mer på MCP-serverns identitet än på användarens; och (4) om MCP-servern komprometteras, får angriparen åtkomst till vidarebefordrade användartokens för alla anslutna nedströmstjänster.
OWASP GenAI-guiden rekommenderar tokens med livslängder mätta i minuter, inte timmar eller dagar. Kortare tokenlivslängder begränsar utnyttjandefönstret om en token blir stulen eller en session kapas. Varje verktygsanrop bör återvalidera tokens signatur, målgrupp och utgång — inte förlita sig på cachad validering från sessionens start.
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.
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...
Den attesterbara MCP-servern tillför fjärrattestering och konfidentiell databehandling till FlowHunt-arbetsflöden, så att AI-agenter och klienter kan verifiera ...