Identitete, dostop in zaupanje
ŽETON ZA NAPAČNEGA PREJEMNIKA
Kako lahko pristno OAuth-pooblastilo odpove pri napačnem API-ju in zakaj mora strežnik MCP za zaledni klic urediti novo avtorizacijsko razmerje.
Odjemalec pošlje strežniku MCP dostopni žeton, ki ga je izdal zaupanja vreden avtorizacijski strežnik. Podpis je pravilen, žeton še velja, zahtevani obseg dovoljenj je videti primeren. Toda v podatku o prejemniku je naveden drug API. Sprejem takšnega zahtevka bi pomenil, da strežnik prizna pooblastilo, ki ni bilo izdano zanj.
V nadaljevanju gre za izmišljeno integracijo, ne za opis dejanskega incidenta ali opravljenega laboratorijskega preskusa. Razlika, na katero opozarja, je določena v standardih OAuth in v avtorizacijskih zahtevah protokola Model Context Protocol (MCP): zaščiteni vir mora imeti podlago za sklep, da je dostopni žeton namenjen prav njemu. Pri povezovanju več storitev je takšno preverjanje odločilno že pred prvim dostopom do zalednih podatkov. [1][2]
Podpis je pravilen, naslovnik pa drug
Zamislimo si odjemalca C, strežnik MCP M in zaledni API D. Podatke za prikaz pri C zagotavlja D, vendar C dostopa do njih prek M. Avtorizacijski strežnik AS je v primeru skupen obema zaščitenima viroma, kar olajša ponazoritev napake: oba lahko prepoznata istega izdajatelja in njegove podpisne ključe. M s tem še ne pridobi pravice, da sprejme vsak žeton, ki ga AS izda za D.
C zaprosi za žeton, s katerim bo poklical M. V ustreznem avtorizacijskem toku lahko zahtevo usmeri z navedbo resource=https://m.example.test/mcp. Če bi C želel neposredno dostopati do D, bi bil cilj https://d.example.test/api. Oba naslova sta izmišljena. RFC 8707 za parameter resource predpisuje absolutni URI brez fragmenta; izdajatelj sme tako navedeno identiteto vira preslikati v drug dogovorjen identifikator, ki ga prejemnik pozneje prepozna kot svojega. [3]
Splošni OAuth po RFC 8707 uporabo tega parametra dopušča, ne zahteva pa njegove prisotnosti pri vsaki avtorizacijski zahtevi. Specifikacija MCP z dne 28. julija 2026 določa strožje pravilo za implementacije, ki uporabljajo njen mehanizem avtorizacije prek HTTP: odjemalec mora resource navesti tako v avtorizacijski zahtevi kot v zahtevi za izdajo žetona in z njim označiti kanonični URI strežnika MCP. To velja tudi takrat, ko odjemalec še ne ve, ali izbrani AS parameter podpira. [1][3]
Avtorizacija je sicer v osnovnem MCP izbirna. Za HTTP je skladnost z opisanim avtorizacijskim mehanizmom priporočena, za povezave prek standardnega vhoda in izhoda (STDIO) pa specifikacija priporoča pridobivanje poverilnic iz okolja. Zahteve za avtorizirani HTTP-MCP zato ne predstavljajo univerzalnega pravila za vsak lokalni strežnik, ki uporablja MCP. [1]
Kaj preveri M in česa iz žetona ne more izvedeti
Za opisani primer naj AS izdaja dostopne žetone JWT po profilu RFC 9068. Tak žeton ima poleg drugih podatkov trditev iss za izdajatelja in aud za predvidenega prejemnika. Strežnik M mora preveriti ustreznost izdajatelja, podpis z zaupanja vrednimi ključi in dovoljenim algoritmom, čas veljavnosti ter ujemanje aud s svojo registrirano identiteto. Profil zahteva tudi ustrezno označeno vrsto žetona typ (at+jwt oziroma application/at+jwt) in zavrnitev nepodpisanega algoritma none. [4]
C lahko povsem zakonito pridobi žeton za D. Poimenujmo ga T_D,C: izdal ga je AS, podpis je pravilen in aud vsebuje samo identifikator D. Če C ta žeton predloži strežniku M, ga mora M zavrniti. Za tako odločitev ni treba dokazati, da je C napadalec ali da je žeton ponarejen. Zadostuje ugotovitev, da M ni eden njegovih dovoljenih prejemnikov. Veljaven žeton za D lahko ostane neprimeren za M ves čas svoje veljavnosti. [2][4]
Ta primer pa ne pomeni, da ima vsak dostopni žeton vidno polje aud. OAuth ne predpisuje, da morajo biti dostopni žetoni zapisani kot JWT. Nekateri so neprosojni nizi, katerih pomen je poznan izdajatelju. Pri njih lahko M uporabi introspekcijo po RFC 7662 ali drug dogovorjeni, zanesljiv način preverjanja. Introspekcijski odgovor mora vsebovati active, medtem ko so podatki, kot sta aud in scope, odvisni od izdajateljeve izvedbe. Pozitiven active brez dodatne zanesljive podlage za ugotovitev namembnosti ne dokazuje, da žeton velja pri M. [5]
Tudi OpenID Connect uporablja žetone JWT, vendar njegov ID token potrjuje informacije o avtentikaciji za odjemalca OIDC. Ni zamenjava za dostopni žeton zaščitenega API-ja. Tipizacija v RFC 9068 med drugim zmanjšuje nevarnost, da bi strežnik po pomoti sprejel identitetni žeton kot dostopno pooblastilo. Podobnost formata, skupni izdajatelj in enak zapis uporabniškega identifikatorja za tako zamenjavo ne zadoščajo. [4][6]
Obseg scope odgovarja na drugačno vprašanje od aud. V našem primeru lahko žeton za D vsebuje dovoljenje records.read, vendar M iz tega ne more sklepati, da ga sme sprejeti. Če je žeton namenjen M in je obseg zadosten, mora M po potrebi še vedno preveriti, ali C sme izvesti zahtevano dejanje nad konkretnim objektom. Namembnost omejuje uporabo pooblastila na vir, avtorizacijska pravila pa določajo dovoljene operacije znotraj tega vira. [3][4]
Ko M odpre povezavo proti D
Odjemalec zdaj uporabi pravi žeton T_M, izdan samo za M. M ga sprejme in začne pripravljati zaledni klic proti D. Če razvijalec iz dohodne zahteve prekopira glavo Authorization: Bearer ... v izhodni zahtevek, D prejme T_M. Odjemalčevo pooblastilo je s tem zapustilo povezavo C–M in pristalo pri storitvi, za katero ni bilo izdano.
Pravilno konfiguriran D mora T_M zavrniti zaradi neustreznega prejemnika. Zavrnitev na strani D pa ne popravi arhitekturnega ravnanja M. Specifikacija avtorizacije MCP zahteva, da M sprejema samo žetone za svoje zaščitene vire, in prepoveduje sprejemanje oziroma nadaljnje posredovanje drugih žetonov. Varnostne smernice MCP opozarjajo na vzorec token passthrough, pri katerem posrednik brez pravilne omejitve prejemnika prenaša odjemalčevo poverilnico do zaledne storitve. [1][7]
V taki povezavi morata obstajati dve ločeni odločitvi. Prva zadeva zahtevek C pri M, druga dostop M do D. M lahko uporablja odobreno storitveno identiteto ali pa po podprtem delegacijskem postopku pridobi nov žeton za D. Poimenujmo ga T_D,M. Ta označuje pooblastilo, izdano za uporabo M pri D; kakšne pravice nosi in v čigavem imenu se uporabi, mora določiti dejanski avtorizacijski postopek. D ga sme sprejeti šele po svojih preverjanjih. [7][8]
RFC 8693 opisuje eno od možnih poti, izmenjavo žetonov. M lahko ob predpisani avtentikaciji in odobritvi pri avtorizacijskem strežniku predloži obstoječe dokazilo kot subject_token ter zaprosi za novo pooblastilo, namenjeno D. Pomembno je, kam je prvotni žeton poslan: pooblaščenemu izdajatelju v postopku izmenjave, ne nespremenjen kot dostopna poverilnica zalednemu API-ju. Standard ne zagotavlja, da izdajatelj izmenjavo podpira ali da bo zahtevani cilj, obseg in delegiranje odobril. [8]
Štirje zahtevki imajo zato različne izide. T_M je pri M lahko sprejet; T_D,C, ki je izdan samo za D, mora M zavrniti. Če M isti vhodni T_M predloži D, krši predvideno ločitev in mora pravilno konfiguriran D zavrniti napačno namembnost. Klic D s posebej pridobljenim T_D,M pa lahko uspe, če poleg prejemnika ustrezajo tudi dovoljenja in dejanski kontekst operacije. To so pričakovani izidi zamišljene implementacije, ne rezultati izvedenega preskusa.
V praksi položaj ni vedno omejen na enega prejemnika. RFC 8707 dovoljuje navedbo več ciljnih virov, JWT pa lahko vsebuje več vrednosti aud. Večprejemniški žeton torej ni avtomatično napačen. Vendar RFC 8707 opozarja, da je pri takem pooblastilu potrebna visoka stopnja zaupanja med prejemniki: storitev, ki prejme nosilski žeton, bi ga lahko uporabila tudi pri drugi navedeni storitvi. Izdajatelj mora razmejiti dovoljenja, prejemniki pa vedeti, kaj jim posamezni scope dejansko daje. Večvrednostni aud sam po sebi tudi ne upraviči nepremišljenega posredovanja vhodne poverilnice skozi MCP. [3][4][7]
Od tod izhaja še drugačna, pogosto spregledana nevarnost. Tudi če M za D pravilno pridobi novo pooblastilo, lahko z njim prekorači namen uporabnikove zahteve, če ima M širše pravice in ne preverja, kaj sme storiti v imenu C. Takšno izkoriščanje posrednikove lastne pristojnosti sodi med možne oblike napada confused deputy. Toda napačni aud in confused deputy nista sinonima; pri slednjem bi bilo treba pokazati, katero tujo pristojnost je C uspel izrabiti. Varnostna dokumentacija MCP opisuje tudi poseben scenarij takšnega napada, povezan s posredniško avtorizacijo in privolitvijo. [7]
Negativen preskus brez napačnega sklepa
Preverjanje se začne z dvema ločeno registriranima testnima viroma, M in D, ter testnim izdajateljem. Žetoni so neprodukcijski, operacije pa omejene na vnaprej določene podatke brez poslovnih posledic. Dokumentirati je treba identifikatorja obeh virov, pravila preslikave resource v aud in način, kako posamezni API dejansko preverja pooblastilo. Brez teh podatkov rezultat zavrnitve ni zanesljivo pripisljiv namembnosti žetona.
Prva kontrola je uspešen klic M z T_M. Izdajatelj, podpis, potek veljavnosti, obseg in zahtevana operacija morajo biti usklajeni, da je mogoče naslednjo zavrnitev primerjati z delujočo potjo. Nato C pri M predloži T_D,C, pri katerem je odločilna razlika prejemnik. Če M vrne 401, je treba iz varovanega zapisa avtorizacijske odločitve ugotoviti, ali je zahtevo res zavrnil zaradi aud. Sama koda 401 ne loči napačnega prejemnika od potečenega žetona, nepravilnega podpisa ali nezaupanja vrednega izdajatelja. [1][4]
Drugi negativni preskus opazuje izhodno zahtevo iz M proti D. Preveriti je treba, da M ne prekopira T_M in da zavrnjen klic v D ne povzroči spremembe testnega podatka. Za to zadošča ustrezno označevanje preskusnih zahtev in nadzorovan zajem avtorizacijskega rezultata; celotnih žetonov ali glav Authorization ni treba shranjevati v dnevnike. Če D napačni T_M zavrne, je potrjena njegova kontrola namembnosti v danem primeru, vprašanje nedovoljenega posredovanja pri M pa je še vedno ločeno odprto.
Pri pozitivni zaledni kontroli M pridobi novo pooblastilo T_D,M in z njim dostopa do neškodljive operacije v D. Koristno je posebej preskusiti še zavrnitev ob manjkajočem obsegu: MCP za neveljavne žetone določa HTTP 401, pri nezadostnem obsegu med izvajanjem pa priporoča HTTP 403 z opisom insufficient_scope v glavi WWW-Authenticate. Iz odgovorov je treba razlikovati med neustreznim žetonom, manjkajočim dovoljenjem in poslovno zavrnitvijo, ki jo lahko implementacija ureja dodatno. [1][9]
Tudi uspeh vseh štirih kontrol ne dokazuje celotne varnosti povezave. Preskus namembnosti ne pokrije upravljanja uporabniških pravic, pravil posameznih objektov, predpomnjenih avtorizacijskih odločitev ali vseh alternativnih poti do D. Za te lastnosti bi bili potrebni ločeni preizkusi. Smisel tega preskusa je ožji in merljiv: veljaven žeton za D ne sme odpreti M, vhodni žeton za M pa ne sme postati bližnjica do zalednega API-ja.
Pri pregledu obstoječe integracije je zato dovolj začeti s preprosto sledjo: kateri resource je bil zahtevan, za katerega prejemnika je AS izdal žeton, kateri strežnik ga je dejansko sprejel in s katero novo poverilnico je posrednik nadaljeval klic. Če tega zaporedja ni mogoče rekonstruirati, zgolj uspešna prijava in pravilno preverjen podpis ne pojasnita, kje se je končalo prvo pooblastilo in začelo drugo.
EVIDENCE PROFILE
Dokazni profil članka
Profil pokaže vrsto dokazne podlage in omejitve osrednjega argumenta.
Viri
- 01PRIMARY DOCUMENTATIONModel Context ProtocolModel Context Protocol — Authorization
[1] Različica/datum: 2026-07-28; Relevantni razdelki: Protocol Requirements; Resource Parameter Implementation; Token Handling; Error Handling
Odpri vir ↗ - 02PRIMARY DOCUMENTATIONModel Context ProtocolModel Context Protocol — Authorization Security Considerations
[2] Različica/datum: 2026-07-28; Relevantni razdelki: Token Audience Binding and Validation
Odpri vir ↗ - 03STANDARDIETF / RFC EditorRFC 8707 — Resource Indicators for OAuth 2.0
[3] Relevantni razdelki: §§ 2, 2.1–2.2, 3
Odpri vir ↗ - 04STANDARDIETF / RFC EditorRFC 9068 — JWT Profile for OAuth 2.0 Access Tokens
[4] Relevantni razdelki: §§ 2, 4, 5
Odpri vir ↗ - 05STANDARDIETF / RFC EditorRFC 7662 — OAuth 2.0 Token Introspection
[5] Relevantni razdelki: § 2.2
Odpri vir ↗ - 06STANDARDOpenID FoundationOpenID Connect Core 1.0 incorporating errata set 2
[6] Relevantni razdelki: §§ 2, 3.1.3.7
Odpri vir ↗ - 07PRIMARY DOCUMENTATIONModel Context ProtocolModel Context Protocol — Security Best Practices
[7] Različica/datum: 2026-07-28; Relevantni razdelki: Token Passthrough; Confused Deputy Problem
Odpri vir ↗ - 08STANDARDIETF / RFC EditorRFC 8693 — OAuth 2.0 Token Exchange
[8] Relevantni razdelki: §§ 2.1, 2.3
Odpri vir ↗ - 09STANDARDIETF / RFC EditorRFC 6750 — The OAuth 2.0 Authorization Framework: Bearer Token Usage
[9] Relevantni razdelki: § 3.1
Odpri vir ↗