Autentificering er det mest kritiske sikkerhedslag for fjern-MCP-servere. Lær hvorfor OAuth 2.1 med OIDC er obligatorisk, hvordan token-delegering forhindrer Confused Deputy-angrebet, og hvorfor token passthrough er et af de farligste mønstre i AI-integrationer.
Autentificering er vagten, der bestemmer, om en MCP-servers kraftfulde funktioner er tilgængelige for legitime brugere eller for angribere. Gør det forkert, og alle andre sikkerhedskontroller bliver irrelevante — en uautentificeret eller dårligt autentificeret MCP-server med adgang til e-mail, filer og databaser er en kritisk sårbarhed uanset hvor godt du har hærdet alt andet.
OWASP GenAI Security Project’s guide identificerer autentificering og autorisation som et af de otte kernesikkerhedsdomæner for MCP-servere, med specifikke krav, der går ud over, hvad de fleste udviklere implementerer som standard. Dette indlæg forklarer, hvorfor disse krav eksisterer, og hvordan man implementerer dem korrekt.
MCP-servere står over for et mere komplekst autentificeringslandskab end traditionelle tjenester, fordi de formidler mellem flere principaler:
Hver af disse relationer kræver sine egne autentificerings- og autorisationskontroller. En svaghed i et hvilket som helst led kan udnyttes til at omgå de andre.
For fjern-MCP-servere — dem, der tilgås over et netværk i stedet for gennem lokal STDIO eller Unix-sockets — er OWASP GenAI-guiden utvetydig: OAuth 2.1 med OIDC er obligatorisk, ikke valgfrit.
Dette krav eksisterer, fordi:
OAuth 2.1 giver eksplicit scope-kontrol. Hvert adgangstoken erklærer præcis, hvilke ressourcer og handlinger det autoriserer. En MCP-server kan verificere på værktøjsinvokeringstidspunktet, at det præsenterede token har det specifikke scope, der er nødvendigt for den handling — ikke kun at brugeren er autentificeret, men at de er autoriseret til denne specifikke operation.
OIDC giver kryptografisk identitet. OpenID Connect tilføjer identitetsbekræftelser (ID-tokenet), som MCP-serveren kan verificere uden at roundtrip til identitetsudbyderen. Serveren validerer iss (issuer), aud (audience), exp (expiry) og signatur ved hver anmodning.
OAuth 2.1-tokens er kortvarige by design. Den moderne OAuth-specifikation (som konsoliderer og erstatter OAuth 2.0 best practices) lægger vægt på kortvarige adgangstokens, der skal opdateres regelmæssigt. Dette begrænser skadevinduet, hvis et token kompromitteres.
Valider ikke tokens kun ved sessionsetablering. Valider ved hver værktøjsinvokation:
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
Cache aldrig valideringsresultater på tværs af anmodninger. Et token, der var gyldigt ved sessionens start, kan være tilbagekaldt midt i sessionen.
I miljøer, hvor MCP-klienter skifter hyppigt (f.eks. forskellige AI-assistenter, der forbinder til den samme server), er statiske API-nøgler eller foruddelte hemmeligheder utilstrækkelige. Brug dynamisk klientregistrering med OAuth 2.1 eller OIDC til at verificere klientidentitet ved forbindelsestidspunktet. Allowlists, hardkodede forbindelsespolitikker eller mutual TLS (mTLS) er passende for kendte statiske relationer mellem specifikke klienter og servere.
Start din gratis prøveperiode i dag og se resultater inden for få dage.
Confused Deputy er en klassisk autorisationssårbarhed med en særligt farlig manifestation i MCP-arkitekturer. Angrebet udnytter tvetydigheden af hvis autoritet en MCP-server handler med.
Overvej dette scenario:
Når Alice beder AI-assistenten om at “opsummere min projektmappe,” bruger serveren Alices token til at få adgang til hendes filer — korrekt adfærd. Men hvis en angriber narrer serveren til at lave en anmodning ved hjælp af sine egne servicelegitimationsoplysninger (måske gennem et tool poisoning-angreb eller indirekte prompt injection), bruges serverens forhøjede tilladelser til at få adgang til filer, som Alice ikke er autoriseret til at se.
Serveren er den “confused deputy” — den er blevet narret til at bruge sin autoritet på vegne af nogen, der ikke har den autoritet, og fungerer som en proxy for privilege escalation.
Mange MCP-implementeringer videresender klientens token til downstream-API’er for enkelthedens skyld. Dette virker intuitivt — brugerens token repræsenterer brugerens tilladelser, så brug af det til alle downstream-kald opretholder korrekt adgangskontrol.
Problemet: downstream-API’er, der genkender MCP-serveren som en betroet mellemmand, kan give anmodninger ved hjælp af serverens identitetsniveau, ikke det videresendte brugertokens niveau. Og hvis MCP-serveren nogensinde handler på eget initiativ — gennem AI-beslutningstagning, som brugeren ikke eksplicit anmodede om — kan den bruge sine egne legitimationsoplysninger i stedet for brugerens token.
Videresendelse af brugertokens:
I stedet for at videresende klienttokens bør MCP-serveren hente sine egne tokens til downstream-tjenesteadgang ved hjælp af OAuth’s On-Behalf-Of (OBO)-flow:
Bruger autentificerer til MCP-klient → klient får brugeradgangstoken
MCP-klient præsenterer brugertoken til MCP-server
MCP-server udveksler brugertoken til et servertoken via OBO-flow:
POST /token
grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
assertion=<user_access_token>
scope=<minimum_required_scope>
MCP-server bruger sit eget OBO-token til downstream-kald
OBO-tokenet:
OWASP GenAI-guiden giver en specifik anbefaling: udsted adgangstokens med levetider målt i minutter, ikke timer. Dette gælder både for de tokens, MCP-serveren accepterer fra klienter, og de tokens, den indhenter til downstream-tjenesteadgang.
Et stjålet adgangstoken er gyldigt for hele sin levetid, uanset om den legitime bruger har logget ud, ændret sin adgangskode eller tilbagekaldt deres session. Et 24-timers token stjålet i begyndelsen af en session giver en angriber 24 timers vedvarende adgang. Et 5-minutters token stjålet midt i sessionen giver højst 5 minutter.
Kortvarige tokens håndhæver også regelmæssige genautentificeringshændelser, som giver muligheder for at:
Hvert token skal kun bære de scopes, der er nødvendige for den specifikke operation, der udføres. Udsted ikke et token med read:files write:files delete:files scope, når det aktuelle værktøjskald kun har brug for read:files. Dette begrænser skaden, hvis tokenet opfanges, eller modellen manipuleres til uventede værktøjskald.
def get_tool_token(user_id: str, tool_name: str) -> str:
# Map værktøj til minimum påkrævede scopes
required_scopes = TOOL_SCOPE_MAP[tool_name]
return oauth_client.get_token(
subject=user_id,
scopes=required_scopes,
lifetime_seconds=300 # 5 minutters levetid
)
Få de seneste tips, trends og tilbud gratis.
En almindelig fejl er at bruge sessions-ID’er som autorisationsproxies: hvis en anmodning bærer et gyldigt sessions-ID, antager serveren, at den er autoriseret. Dette sammenblander state management med identitetsverifikation.
Den korrekte model: sessions-ID’er administrerer samtaletilstand. Autorisation verificeres uafhængigt ved hver anmodning ved at validere OAuth-tokenets claims. Selv en anmodning, der bærer et gyldigt sessions-ID, skal præsentere et gyldigt, ikke-udløbet, korrekt scoped OAuth-token, før nogen værktøjsinvokation tillades.
Dette betyder noget, fordi sessions-ID’er kan stjæles, gættes eller genafspilles på måder, som OAuth-tokens — der bærer kryptografiske integritetsgarantier — ikke kan.
I stedet for at implementere autorisationstjek spredt ud over individuelle værktøjshandlere anbefaler OWASP GenAI-guiden en centraliseret politikgateway, der:
Centralisering sikrer, at politikker anvendes konsekvent på tværs af alle værktøjer og agenter. Et værktøjsspecifikt autorisationstjek kan blive glemt eller omgået under udvikling; et gateway-tjek kan ikke.
For fjern-MCP-servere er den minimale autentificeringssikkerhedsstandard:
OAuth 2.1 er påkrævet for fjern-MCP-servere, fordi det giver delegeret autorisation med eksplicit scope-kontrol, kortvarige tokens, kryptografisk verifikation og standardiserede identitetsbekræftelser (via OIDC). Enklere metoder som API-nøgler eller sessionscookies mangler den scope-granularitet, der er nødvendig for at implementere least-privilege-adgang, giver ikke kryptografiske identitetsgarantier og er svære at tilbagekalde granulært, når en session slutter.
Confused Deputy er et privilege escalation-angreb, hvor MCP-serveren narres til at bruge sine egne (højere) privilegier til at udføre handlinger, som den anmodende bruger ikke er autoriseret til at udføre. Det opstår, når token passthrough bruges — serveren videresender en brugers token til downstream-API'er, som kan give brugeren adgang, de ikke burde have baseret på serverens betroede status. Løsningen er at bruge On-Behalf-Of token-flows, hvor tokens udstedes eksplicit til MCP-serverens specifikke adgangsscope.
Token passthrough betyder, at MCP-serveren videresender klientens autentificeringstoken direkte til downstream-API'er, i stedet for at bruge sine egne server-udstedte legitimationsoplysninger. Dette er farligt, fordi: (1) det bryder revisionsspor — downstream-systemer ser brugerens token, ikke MCP-serveren, hvilket gør det umuligt at tilskrive handlinger til serveren; (2) det omgår MCP-serverens egne adgangspolitikker; (3) det skaber en Confused Deputy-sårbarhed, hvis downstream-API'en stoler mere på MCP-serverens identitet end brugerens; og (4) hvis MCP-serveren kompromitteres, får angriberen adgang til videresendte brugertokens for alle tilsluttede downstream-tjenester.
OWASP GenAI-guiden anbefaler tokens med levetider målt i minutter, ikke timer eller dage. Kortere token-levetider begrænser udnyttelsesvinduet, hvis et token bliver stjålet, eller en session bliver kapret. Hver værktøjsinvokation bør genvalidere tokenets signatur, audience og udløb — ikke stole på cachelagret validering fra sessionens start.
Arshia er AI Workflow Engineer hos FlowHunt. Med en baggrund inden for datalogi og en passion for AI, specialiserer han sig i at skabe effektive workflows, der integrerer AI-værktøjer i daglige opgaver og øger produktivitet og kreativitet.
Vores sikkerhedsteam vurderer MCP-autentificeringskonfigurationer, token-håndtering og autorisationsflows i forhold til OWASP GenAI-standarderne. Identificer huller før angriberne gør det.
MCP servere udsætter en unik angrebsflade, der kombinerer traditionelle API-risici med AI-specifikke trusler. Lær de 6 kritiske sårbarheder identificeret af OWA...
Authenticator App MCP Server gør det muligt for AI-agenter at få sikker adgang til 2FA-koder og adgangskoder, hvilket strømliner automatiserede loginprocesser o...
OWASP GenAI Security Project definerer en minimumsstandard i fem kategorier for sikker MCP server-udrulning. Brug denne tjekliste til at vurdere din nuværende s...