Autentizace je nejkritičtější bezpečnostní vrstvou pro vzdálené MCP servery. Zjistěte, proč je OAuth 2.1 s OIDC povinný, jak delegace tokenů předchází útoku Zmateného zástupce a proč je předávání tokenů jedním z nejnebezpečnějších vzorů v AI integracích.
Autentizace je strážcem, který určuje, zda jsou výkonné schopnosti MCP serveru dostupné legitimním uživatelům nebo útočníkům. Pokud to uděláte špatně, všechny ostatní bezpečnostní kontroly se stanou irelevantními — neautentizovaný nebo špatně autentizovaný MCP server s přístupem k e-mailu, souborům a databázím je kritickou zranitelností bez ohledu na to, jak dobře jste vše ostatní zabezpečili.
Průvodce projektu OWASP GenAI Security identifikuje autentizaci a autorizaci jako jednu z osmi základních bezpečnostních domén pro MCP servery, se specifickými požadavky, které jdou nad rámec toho, co většina vývojářů implementuje ve výchozím nastavení. Tento příspěvek vysvětluje, proč tyto požadavky existují a jak je správně implementovat.
MCP servery čelí složitější autentizační krajině než tradiční služby, protože zprostředkovávají mezi více principály:
Každý z těchto vztahů vyžaduje vlastní autentizační a autorizační kontroly. Slabina v jakémkoli článku může být zneužita k obejití ostatních.
Pro vzdálené MCP servery — ty, ke kterým se přistupuje přes síť spíše než prostřednictvím lokálního STDIO nebo Unix socketů — je průvodce OWASP GenAI jednoznačný: OAuth 2.1 s OIDC je povinný, nikoli volitelný.
Tento požadavek existuje, protože:
OAuth 2.1 poskytuje explicitní kontrolu rozsahu. Každý přístupový token deklaruje přesně, které zdroje a akce autorizuje. MCP server může při vyvolání nástroje ověřit, že prezentovaný token má konkrétní rozsah potřebný pro tuto akci — nejen že je uživatel autentizován, ale že je autorizován pro tuto konkrétní operaci.
OIDC poskytuje kryptografickou identitu. OpenID Connect přidává identity assertions (ID token), které může MCP server ověřit bez round-tripu k poskytovateli identity. Server validuje iss (issuer), aud (audience), exp (expiry) a podpis při každém požadavku.
OAuth 2.1 tokeny jsou navrženy jako krátkodobé. Moderní OAuth specifikace (která konsoliduje a nahrazuje osvědčené postupy OAuth 2.0) zdůrazňuje krátkodobé přístupové tokeny, které musí být pravidelně obnoveny. To omezuje okno škody, pokud je token kompromitován.
Nevalidujte tokeny pouze při vytvoření relace. Validujte při každém vyvolání nástroje:
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
Nikdy necachujte výsledky validace napříč požadavky. Token, který byl platný na začátku relace, může být uprostřed relace odvolán.
V prostředích, kde se MCP klienti často mění (např. různí AI asistenti se připojují ke stejnému serveru), jsou statické API klíče nebo předsdílené tajemství nedostatečné. Použijte dynamickou registraci klientů s OAuth 2.1 nebo OIDC k ověření identity klienta v době připojení. Allowlisty, hardcoded připojovací politiky nebo vzájemný TLS (mTLS) jsou vhodné pro známé statické vztahy mezi konkrétními klienty a servery.
Začněte svou bezplatnou zkušební verzi ještě dnes a viďte výsledky během několika dní.
Zmatený zástupce je klasická autorizační zranitelnost s obzvláště nebezpečnou manifestací v MCP architekturách. Útok zneužívá nejednoznačnost čí autoritou MCP server jedná.
Zvažte tento scénář:
Když Alice požádá AI asistenta, aby “shrnul můj projektový adresář,” server použije Alicin token pro přístup k jejím souborům — správné chování. Ale pokud útočník oklame server, aby provedl požadavek pomocí vlastních servisních přihlašovacích údajů (možná prostřednictvím útoku otrávení nástroje nebo nepřímé prompt injection), jsou použita zvýšená oprávnění serveru pro přístup k souborům, ke kterým Alice nemá oprávnění vidět.
Server je “zmatený zástupce” — byl oklamán k použití své autority jménem někoho, kdo tuto autoritu nemá, působí jako proxy pro eskalaci oprávnění.
Mnoho MCP implementací předává token klienta do downstream API pro jednoduchost. To se zdá intuitivní — token uživatele reprezentuje oprávnění uživatele, takže jeho použití pro všechna downstream volání udržuje správnou kontrolu přístupu.
Problém: downstream API, která rozpoznávají MCP server jako důvěryhodného prostředníka, mohou udělit požadavky na úrovni identity serveru, nikoli na úrovni předaného uživatelského tokenu. A pokud MCP server někdy jedná z vlastní iniciativy — prostřednictvím AI rozhodování, které uživatel explicitně nepožadoval — může použít vlastní přihlašovací údaje místo tokenu uživatele.
Předávání uživatelských tokenů také:
Místo předávání klientských tokenů by měl MCP server získat vlastní tokeny pro přístup k downstream službám pomocí OAuth On-Behalf-Of (OBO) flow:
Uživatel se autentizuje na MCP klientovi → klient získá uživatelský přístupový token
MCP klient prezentuje uživatelský token MCP serveru
MCP server vymění uživatelský token za serverový token prostřednictvím OBO flow:
POST /token
grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
assertion=<user_access_token>
scope=<minimum_required_scope>
MCP server používá vlastní OBO token pro downstream volání
OBO token:
Průvodce OWASP GenAI dává konkrétní doporučení: vydávejte přístupové tokeny s životností měřenou v minutách, nikoli hodinách. To platí jak pro tokeny, které MCP server přijímá od klientů, tak pro tokeny, které získává pro přístup k downstream službám.
Ukradený přístupový token je platný po celou svou životnost bez ohledu na to, zda se legitimní uživatel odhlásil, změnil heslo nebo odvolal svou relaci. 24hodinový token ukradený na začátku relace dává útočníkovi 24 hodin trvalého přístupu. 5minutový token ukradený uprostřed relace dává maximálně 5 minut.
Krátkodobé tokeny také vynucují pravidelné re-autentizační události, které poskytují příležitosti k:
Každý token by měl nést pouze rozsahy potřebné pro konkrétní prováděnou operaci. Nevydávejte token s rozsahem read:files write:files delete:files, když aktuální volání nástroje potřebuje pouze read:files. To omezuje škodu, pokud je token zachycen nebo model je manipulován k neočekávaným voláním nástrojů.
def get_tool_token(user_id: str, tool_name: str) -> str:
# Mapování nástroje na minimální požadované rozsahy
required_scopes = TOOL_SCOPE_MAP[tool_name]
return oauth_client.get_token(
subject=user_id,
scopes=required_scopes,
lifetime_seconds=300 # 5minutová životnost
)
Získejte nejnovější tipy, trendy a nabídky zdarma.
Běžná chyba je používání ID relací jako autorizačních proxy: pokud požadavek nese platné ID relace, server předpokládá, že je autorizován. To zaměňuje správu stavu s ověřením identity.
Správný model: ID relací spravují konverzační stav. Autorizace je ověřována nezávisle při každém požadavku validací claims OAuth tokenu. I požadavek nesoucí platné ID relace musí prezentovat platný, neexpirovaný, správně vymezený OAuth token před tím, než je povoleno jakékoli vyvolání nástroje.
To je důležité, protože ID relací mohou být ukradena, uhodnuta nebo přehrána způsoby, kterými OAuth tokeny — které nesou kryptografické záruky integrity — nemohou.
Místo implementace autorizačních kontrol roztroušených v jednotlivých handlerech nástrojů doporučuje průvodce OWASP GenAI centralizovanou policy gateway, která:
Centralizace zajišťuje, že politiky jsou konzistentně aplikovány napříč všemi nástroji a agenty. Autorizační kontrola specifická pro nástroj může být zapomenuta nebo obejita během vývoje; kontrola gateway ne.
Pro vzdálené MCP servery je minimální bezpečnostní laťka autentizace:
OAuth 2.1 je vyžadován pro vzdálené MCP servery, protože poskytuje delegovanou autorizaci s explicitní kontrolou rozsahu, krátkodobé tokeny, kryptografické ověření a standardizované identity assertions (prostřednictvím OIDC). Jednodušší metody jako API klíče nebo session cookies postrádají granularitu rozsahu potřebnou k implementaci přístupu s nejmenšími oprávněními, neposkytují kryptografické záruky identity a je obtížné je granulárně odvolat, když relace skončí.
Zmatený zástupce je útok eskalace oprávnění, kdy je MCP server oklamán k použití svých vlastních (vyšších) oprávnění k provádění akcí, ke kterým žádající uživatel nemá oprávnění. Dochází k němu, když je použito předávání tokenů — server předává token uživatele do downstream API, které může uživateli udělit přístup, který by neměl mít na základě důvěryhodného statusu serveru. Řešením je použití On-Behalf-Of token flows, kde jsou tokeny explicitně vydány pro konkrétní přístupový rozsah MCP serveru.
Předávání tokenů znamená, že MCP server předává autentizační token klienta přímo do downstream API, místo použití vlastních serverem vydaných přihlašovacích údajů. To je nebezpečné, protože: (1) narušuje to audit trails — downstream systémy vidí uživatelský token, nikoli MCP server, což znemožňuje připsat akce serveru; (2) obchází to vlastní přístupové politiky MCP serveru; (3) vytváří to zranitelnost Zmateného zástupce, pokud downstream API důvěřuje identitě MCP serveru více než uživatelskému tokenu; a (4) pokud je MCP server kompromitován, útočník získá přístup k předávaným uživatelským tokenům pro všechny připojené downstream služby.
Průvodce OWASP GenAI doporučuje tokeny s životností měřenou v minutách, nikoli hodinách nebo dnech. Kratší životnost tokenů omezuje okno pro zneužití, pokud je token ukraden nebo relace unese. Každé vyvolání nástroje by mělo znovu validovat podpis tokenu, audience a expiraci — nespoléhat se na cache validaci od začátku relace.
Arshia je inženýr AI pracovních postupů ve FlowHunt. Sxa0vzděláním vxa0oboru informatiky a vášní pro umělou inteligenci se specializuje na vytváření efektivních workflow, které integrují AI nástroje do každodenních úkolů a zvyšují tak produktivitu i kreativitu.
Náš bezpečnostní tým hodnotí MCP autentizační konfigurace, zpracování tokenů a autorizační toky podle standardů OWASP GenAI. Identifikujte mezery dříve, než je najdou útočníci.
MCP servery vystavují jedinečnou útočnou plochu kombinující tradiční API rizika s hrozbami specifickými pro AI. Naučte se 6 kritických zranitelností identifikov...
Server Authenticator App MCP umožňuje AI agentům bezpečně přistupovat k 2FA kódům a heslům, zjednodušuje automatizované přihlašování a správu přihlašovacích úda...
Projekt OWASP GenAI Security definuje pět kategorií minimálního standardu pro bezpečné nasazení MCP serveru. Použijte tento kontrolní seznam k posouzení vašeho ...