Autentisering er det mest kritiske sikkerhetslaget for eksterne MCP-servere. Lær hvorfor OAuth 2.1 med OIDC er obligatorisk, hvordan token-delegering forhindrer Confused Deputy-angrep, og hvorfor token-videreføring er et av de farligste mønstrene i AI-integrasjoner.
Autentisering er portvakten som avgjør om en MCP-servers kraftige kapasiteter er tilgjengelige for legitime brukere eller for angripere. Gjør det feil, og alle andre sikkerhetskontroller blir irrelevante — en uautentisert eller dårlig autentisert MCP-server med tilgang til e-post, filer og databaser er en kritisk sårbarhet uavhengig av hvor godt du har sikret alt annet.
OWASP GenAI Security Project-guiden identifiserer autentisering og autorisasjon som ett av de åtte kjernesikkerhetsområdene for MCP-servere, med spesifikke krav som går utover det de fleste utviklere implementerer som standard. Dette innlegget forklarer hvorfor disse kravene eksisterer og hvordan man implementerer dem riktig.
MCP-servere står overfor et mer komplekst autentiseringslandskap enn tradisjonelle tjenester fordi de formidler mellom flere prinsipper:
Hvert av disse forholdene krever sine egne autentiserings- og autorisasjonskontroller. En svakhet i noen lenke kan utnyttes til å omgå de andre.
For eksterne MCP-servere — de som er tilgjengelige over et nettverk i stedet for gjennom lokale STDIO- eller Unix-sokler — er OWASP GenAI-guiden utvetydig: OAuth 2.1 med OIDC er obligatorisk, ikke valgfritt.
Dette kravet eksisterer fordi:
OAuth 2.1 gir eksplisitt scope-kontroll. Hvert tilgangstoken deklarerer nøyaktig hvilke ressurser og handlinger det autoriserer. En MCP-server kan verifisere ved verktøykall-tidspunktet at tokenet som presenteres har det spesifikke scopet som trengs for den handlingen — ikke bare at brukeren er autentisert, men at de er autorisert for denne spesifikke operasjonen.
OIDC gir kryptografisk identitet. OpenID Connect legger til identitetsbekreftelser (ID-tokenet) som MCP-serveren kan verifisere uten rundtur til identitetsleverandøren. Serveren validerer iss (utsteder), aud (målgruppe), exp (utløp) og signatur på hver forespørsel.
OAuth 2.1-tokens er kortlivede ved design. Den moderne OAuth-spesifikasjonen (som konsoliderer og erstatter OAuth 2.0 beste praksis) vektlegger kortlivede tilgangstokens som må fornyes regelmessig. Dette begrenser skadevinduet hvis et token blir kompromittert.
Ikke valider tokens bare ved sesjonsopprettelse. Valider ved hvert verktøykall:
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
Aldri bufre valideringsresultater på tvers av forespørsler. Et token som var gyldig ved sesjonsstart kan være tilbakekalt midt i sesjonen.
I miljøer der MCP-klienter endres ofte (f.eks. forskjellige AI-assistenter som kobler til samme server), er statiske API-nøkler eller forhåndsdelte hemmeligheter utilstrekkelige. Bruk dynamisk klientregistrering med OAuth 2.1 eller OIDC for å verifisere klientidentitet ved tilkoblingstidspunktet. Hvitelister, hardkodede tilkoblingspolicyer eller gjensidig TLS (mTLS) er passende for kjente statiske forhold mellom spesifikke klienter og servere.
Start din gratis prøveperiode i dag og se resultater i løpet av få dager.
Confused Deputy er en klassisk autorisasjonssårbarhet med en spesielt farlig manifestasjon i MCP-arkitekturer. Angrepet utnytter tvetydigheten av hvis autoritet en MCP-server handler med.
Vurder dette scenariet:
Når Alice ber AI-assistenten om å “oppsummere min prosjektmappe”, bruker serveren Alices token for å få tilgang til filene hennes — korrekt atferd. Men hvis en angriper lurer serveren til å gjøre en forespørsel ved å bruke sine egne tjenestekredisjoner (kanskje gjennom et verktøyforgiftningsangrep eller indirekte prompt-injeksjon), brukes serverens utvidede tillatelser til å få tilgang til filer Alice ikke er autorisert til å se.
Serveren er den “forvirrede fullmektigen” — den har blitt lurt til å bruke sin autoritet på vegne av noen som ikke har den autoriteten, og opptrer som en proxy for privilegieeskalering.
Mange MCP-implementeringer videresender klientens token til nedstrøms-APIer for enkelhets skyld. Dette virker intuitivt — brukerens token representerer brukerens tillatelser, så å bruke det for alle nedstrømskall opprettholder korrekt tilgangskontroll.
Problemet: nedstrøms-APIer som gjenkjenner MCP-serveren som en pålitelig mellommann kan innvilge forespørsler ved å bruke serverens identitetsnivå, ikke det videreførte bruker-tokenets nivå. Og hvis MCP-serveren noen gang handler på eget initiativ — gjennom AI-beslutningstaking som brukeren ikke eksplisitt ba om — kan den bruke sine egne legitimasjoner i stedet for brukerens token.
Videreføring av brukertokens:
I stedet for å videresende klienttokens, bør MCP-serveren innhente sine egne tokens for nedstrømstjenestetilgang ved å bruke OAuths On-Behalf-Of (OBO)-flyt:
Bruker autentiserer til MCP-klient → klient får brukertilgangstoken
MCP-klient presenterer brukertoken til MCP-server
MCP-server bytter brukertoken mot et servertoken via OBO-flyt:
POST /token
grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
assertion=<user_access_token>
scope=<minimum_required_scope>
MCP-server bruker sitt eget OBO-token for nedstrømskall
OBO-tokenet:
OWASP GenAI-guiden gir en spesifikk anbefaling: utsted tilgangstokens med levetider målt i minutter, ikke timer. Dette gjelder både tokens som MCP-serveren aksepterer fra klienter og tokens den innhenter for nedstrømstjenestetilgang.
Et stjålet tilgangstoken er gyldig i hele sin levetid uavhengig av om den legitime brukeren har logget ut, endret passordet sitt eller tilbakekalt sesjonen sin. Et 24-timers token stjålet i begynnelsen av en sesjon gir en angriper 24 timers vedvarende tilgang. Et 5-minutters token stjålet midt i sesjonen gir maksimalt 5 minutter.
Kortlivede tokens håndhever også regelmessige reautentiseringshendelser, som gir muligheter til å:
Hvert token bør bare bære scopene som trengs for den spesifikke operasjonen som utføres. Ikke utsted et token med read:files write:files delete:files scope når det gjeldende verktøykallet bare trenger read:files. Dette begrenser skaden hvis tokenet blir avlyttet eller modellen manipuleres til uventede verktøykall.
def get_tool_token(user_id: str, tool_name: str) -> str:
# Koble verktøy til minimum nødvendige 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 siste tipsene, trendene og tilbudene gratis.
En vanlig feil er å bruke sesjons-IDer som autorisasjonsproxyer: hvis en forespørsel bærer en gyldig sesjons-ID, antar serveren at den er autorisert. Dette sammenblander tilstandsstyring med identitetsverifisering.
Den korrekte modellen: sesjons-IDer håndterer samtaletilstand. Autorisasjon verifiseres uavhengig ved hver forespørsel ved å validere OAuth-tokenets krav. Selv en forespørsel som bærer en gyldig sesjons-ID må presentere et gyldig, ikke-utløpt, riktig scopet OAuth-token før noe verktøykall tillates.
Dette er viktig fordi sesjons-IDer kan bli stjålet, gjettet eller spilt av på nytt på måter som OAuth-tokens — som bærer kryptografiske integritetsgarantier — ikke kan.
I stedet for å implementere autorisasjonskontroller spredt utover individuelle verktøyhåndterere, anbefaler OWASP GenAI-guiden en sentralisert policygateway som:
Sentralisering sikrer at policyer anvendes konsekvent på tvers av alle verktøy og agenter. En verktøyspesifikk autorisasjonskontroll kan bli glemt eller omgått under utvikling; en gatewaykontroll kan ikke.
For eksterne MCP-servere er minimum autentiseringssikkerhetsstandard:
OAuth 2.1 er påkrevd for eksterne MCP-servere fordi det gir delegert autorisasjon med eksplisitt scope-kontroll, kortlivede tokens, kryptografisk verifisering og standardiserte identitetsbekreftelser (via OIDC). Enklere metoder som API-nøkler eller sesjonscookies mangler scope-granulariteten som trengs for å implementere tilgang med minste privilegium, gir ikke kryptografiske identitetsgarantier, og er vanskelige å tilbakekalle granulært når en sesjon avsluttes.
Confused Deputy er et privilegieeskaleringsangrep der MCP-serveren lures til å bruke sine egne (høyere) privilegier til å utføre handlinger som den forespørrende brukeren ikke er autorisert til å utføre. Det oppstår når token-videreføring brukes — serveren videresender en brukers token til nedstrøms-APIer, som kan gi brukeren tilgang de ikke burde ha basert på serverens pålitelige status. Løsningen er å bruke On-Behalf-Of token-flyter der tokens eksplisitt utstedes for MCP-serverens spesifikke tilgangsomfang.
Token-videreføring betyr at MCP-serveren videresender klientens autentiseringstoken direkte til nedstrøms-APIer, i stedet for å bruke sine egne serverutstedte legitimasjoner. Dette er farlig fordi: (1) det bryter revisjonsspor — nedstrømssystemer ser bruker-tokenet, ikke MCP-serveren, noe som gjør det umulig å tilskrive handlinger til serveren; (2) det omgår MCP-serverens egne tilgangspolicyer; (3) det skaper en Confused Deputy-sårbarhet hvis nedstrøms-APIet stoler mer på MCP-serverens identitet enn brukerens; og (4) hvis MCP-serveren blir kompromittert, får angriperen tilgang til videreførte brukertokens for alle tilkoblede nedstrømstjenester.
OWASP GenAI-guiden anbefaler tokens med levetider målt i minutter, ikke timer eller dager. Kortere token-levetider begrenser utnyttelsesvinduet hvis et token blir stjålet eller en sesjon blir kapret. Hver verktøykall bør revalidere tokenets signatur, målgruppe og utløp — ikke stole på bufret validering fra sesjonsstart.
Arshia er en AI Workflow Engineer hos FlowHunt. Med bakgrunn i informatikk og en lidenskap for kunstig intelligens, spesialiserer han seg på å lage effektive arbeidsflyter som integrerer AI-verktøy i daglige oppgaver, og dermed øker produktivitet og kreativitet.
Vårt sikkerhetsteam vurderer MCP-autentiseringskonfigurasjoner, token-håndtering og autorisasjonsflyter mot OWASP GenAI-standardene. Identifiser hull før angripere gjør det.
MCP-servere eksponerer en unik angrepsflade som kombinerer tradisjonelle API-risikoer med AI-spesifikke trusler. Lær om de 6 kritiske sårbarhetene identifisert ...
Authenticator App MCP-serveren gjør det mulig for AI-agenter å få sikker tilgang til 2FA-koder og passord, og effektiviserer automatiserte innloggingsprosesser ...
Integrer FlowHunt med Attesterbar MCP-server for å muliggjøre sikker, ekstern attestasjon og verifiserbar kodeintegritet ved bruk av Intel SGX og RA-TLS. Oppnå ...