MCP-autorisaatiomäärittelyn syvällinen tarkastelu (26.3.2025)

MCP (Model Context Protocol) on avoin standardi, joka mahdollistaa tekoälymallien vuorovaikutuksen ulkoisten työkalujen ja palveluiden kanssa. Se on laajalti otettu käyttöön teollisuudessa. MCP:n tukemien HTTP-pohjaisten kuljetusmenetelmien myötä etä-MCP-palvelimella tulee olemaan yhä tärkeämpi rooli MCP-ekosysteemissä.

Toisin kuin paikallinen MCP-palvelin, joka sallii jokaisen käyttäjän ajaa omaa palvelininstanssiaan, etä-MCP-palvelin vaatii kaikkia käyttäjiä jakamaan saman MCP-palvelimen. Tämä tuo esiin MCP-autorisaatiomäärittelyn (https://spec.modelcontextprotocol.io/specification/2025-03-26/basic/authorization) ydinkysymyksen: miten sallia MCP-palvelimen käyttää käyttäjän resursseja käyttäjän puolesta.

Tässä artikkelissa analysoidaan syvällisesti MCP-autorisaatiomäärittelyä. Se auttaa ymmärtämään MCP-autorisaatiomäärittelyn suunnitteluperiaatteita ja antaa suuntaviivoja MCP:n valtuutuksen toteuttamiseen. Koska tämä määrittely on vielä kehittyvä, jaan joitakin ajatuksia perustuen omaan kokemukseeni autentikointipalveluiden toteuttamisessa, mukaan lukien:

• OAuth 2.1:n edut ja rajoitukset valtuutuskehyksenä
• MCP-palvelimen kaksoisroolin haasteet valtuutus- ja resurssipalvelimena
• Täydellisen valtuutuspalvelimen toteuttamisen käytännön monimutkaisuus
• Analyysi sopivista tilanteista kolmannen osapuolen valtuutukseen
• Dynaamisen asiakasrekisteröinnin käytännön kompromissit
• MCP-palvelimen resurssirajojen selkeän määrittelyn tärkeys

MCP-autorisaatiomäärittelyn yleiskatsaus#

MCP-autorisaatiomäärittely määrittää todennusprosessin etä-MCP-palvelimen ja MCP-asiakkaan välillä.

Mielestäni tämän määrittelyn perustaminen OAuth 2.1:een on erittäin järkevä valinta. OAuth valtuutusprotokollakehyksenä ratkaisee ongelman, miten sallia käyttäjien valtuuttaa kolmannen osapuolen sovellukset käyttämään käyttäjän resursseja heidän puolestaan. Jos et ole perehtynyt OAutheen, voit tutustua AuthWiki-OAuth saadaksesi lisätietoja.

MCP-asiakkaan ja MCP-palvelimen skenaariossa kyse on "käyttäjien valtuutuksesta MCP-asiakkaalle käyttää käyttäjän resursseja MCP-palvelimella". "Käyttäjän resurssit MCP-palvelimella" viittaa nykyisin pääasiassa MCP-palvelimen tarjoamiin työkaluihin tai MCP-palvelimen taustapalveluiden tarjoamiin resursseihin.

OAuth 2.1 -todennusprosessin toteuttamiseksi protokolla vaatii MCP-palvelinta tarjoamaan seuraavat liittymät toimiakseen yhdessä MCP-asiakkaan kanssa OAuth 2.1 -todennusprosessin täydentämiseksi:

• /.well-known/oauth-authorization-server: OAuth-palvelimen metadata
• /authorize: valtuutuspäätepiste, käytetään valtuutuspyynnöissä
• /token: token-päätepiste, käytetään tokenin vaihdossa ja päivityksessä
• /register: asiakasrekisteröintipäätepiste, käytetään dynaamiseen asiakasrekisteröintiin

Todennusprosessi on seuraava:

Määrittely kuvaa myös, miten MCP-palvelin tukee valtuutusta valtuutuksen siirtämisen kautta kolmansille osapuolille.

Esimerkki tapahtumaketjusta määrittelyssä on seuraava (määrittelyn sisällöstä):

Tässä skenaariossa, vaikka MCP-palvelin valtuuttaa kolmannen osapuolen valtuutuspalvelimen avulla, MCP-palvelin toimii silti MCP-asiakkaan valtuutuspalvelimena. Tämä johtuu siitä, että MCP-palvelimen täytyy myöntää oma käyttötunnus MCP-asiakkaalle.

Näkemykseni mukaan tämä skenaario vaikuttaa sopivammalta tilanteisiin, joissa MCP-palvelin toimii MCP-asiakkaan välittäjänä (käyttäjä) pääsyssä kolmannen osapuolen resursseihin (kuten Githubin repoihin), eikä niinkään silloin, kun MCP-palvelin toimii MCP-asiakkaan (käyttäjän) välittäjänä pääsyssä MCP-palvelimen omiin resursseihin.

Yhteenvetona, protokollan mukaan MCP-palvelin toimii sekä valtuutuspalvelimena että resurssipalvelimena OAuth:ssa.

Seuraavaksi keskustellaan MCP-palvelimen roolista valtuutuspalveluna ja resurssipalveluna.

MCP-palvelin valtuutuspalveluna#

Kun MCP-palvelin toimii valtuutuspalvelimena, se tarkoittaa, että MCP-asiakkaan loppukäyttäjällä on oma identiteettinsä MCP-palvelimella. MCP-palvelin vastaa tämän loppukäyttäjän todennuksesta ja myöntää käyttötunnuksen tälle käyttäjälle MCP-palvelimen resurssien käyttöä varten.

Edellä mainitut MCP-autorisaatiomäärittelyn edellyttämät valtuutukseen liittyvät rajapinnat tarkoittavat, että MCP-palvelimen on tarjottava valtuutuspalvelimen toteutus.

Kuitenkin valtuutuspalvelimen toiminnallisuuden toteutus MCP-palvelimella on merkittävä haaste kehittäjille. Toisaalta, suurin osa kehittäjistä ei ehkä ole tuttu OAuth:hen liittyvistä käsitteistä. Toisaalta on monia yksityiskohtia, jotka on otettava huomioon valtuutuspalvelimen toteuttamisessa. Jos kehittäjä ei ole alaan liittyvältä alalta, he voivat aiheuttaa ongelmia, kuten turvallisuusongelmia toteutuksessa.

Protokollahan ei kuitenkaan sinänsä rajoita MCP-palvelinta toteuttamaan valtuutuspalvelimen toiminnallisuutta itse. Kehittäjät voivat täysimääräisesti uudelleenohjata tai välittää nämä valtuutukseen liittyvät päätepisteet muille valtuutuspalvelimille. Tämä ei eroa miten MCP-asiakas näkee MCP-palvelimen valtuutuspalvelimen toiminnallisuuden toteuttamisen itse.

Saatat kysyä, pitäisikö tätä lähestymistapaa käyttää yllä mainitun kolmannen osapuolen valtuutusmenetelmän kanssa?

Näkäkulmastani tämä riippuu pääasiassa siitä, ovatko riippumasi kolmannen osapuolen palvelun käyttäjät samoja kuin MCP-palvelimen loppukäyttäjät. Tämä tarkoittaa, että käyttötunnus, jonka kolmannen osapuolen valtuutuspalvelusi myöntää sinulle, kulutetaan suoraan MCP-palvelimellasi.

• Jos kyllä, niin voit täysimääräisesti välittää kaikki valtuutukseen liittyvät liittymät MCP-palvelimellasi kolmannen osapuolen valtuutuspalveluille.

• Jos ei, sinun tulisi käyttää määrittelyssä määriteltyä kolmannen osapuolen valtuutuksen delegointitapaa. Sinun on ylläpidettävä vastaavuus MCP-palvelimen itsensä myöntämien käyttötunnusten ja kolmannen osapuolen valtuutuspalveluiden myöntämien käyttötunnusten välillä MCP-palvelimella.

Mielestäni määrittelyssä esitetty kolmannen osapuolen valtuutuksen delegointitapa on käytännön sovelluskohteissa hieman epämääräinen. Protokolla vaikuttaa siltä, että kolmannet osapuolet auttaisivat MCP-palvelimen valtuutusprosessin toteutuksessa, mutta silti vaatii MCP-palvelimen myöntämään oman käyttötunnuksen. Tämä tarkoittaa, että MCP-palvelin kantaa edelleen vastuun käyttötunnuksen myöntämisestä valtuutuspalvelimena, mikä ei ole kehittäjille merkittävästi kätevämpää. Uskon, että protokollan kirjoittajat ovat todennäköisesti miettineet, että kolmannen osapuolen käyttötunnusten suora palauttaminen MCP-asiakkaalle voisi aiheuttaa tiettyjä turvallisuusongelmia (kuten vuoto/kehnot käyttöolosuhteet jne.).

Kokemukseni mukaan määrittelyssä mainitun kolmannen osapuolen valtuutuksen delegoinnin sopivin skenaario on "kuinka käyttäjät valtuuttavat MCP-palvelimen käyttämään käyttäjän resursseja kolmannen osapuolen resurssipalvelimilla". Esimerkiksi, jos MCP-palvelimen täytyy käyttää käyttäjän Github-repoa ja sijoittaa repon koodia koodin käyttöönottamisalustalle. Tällöin käyttäjän täytyy valtuuttaa MCP-palvelimen käyttämään Github-repoaan sekä pääsemaan käsittelemään koodin käyttöönottopalvelualustaa.

Tässä skenaariossa MCP-palvelin toimii MCP-asiakkaalle valtuutuspalvelimena, koska loppukäyttäjillä on oma identiteettinsä MCP-palvelimella. MCP-palvelin on kolmannen osapuolen asiakas kolmannen osapuolen resursseille (tässä tapauksessa Github), ja sen on saatava käyttäjävaltuutus päästäkseen käsiksi käyttäjäresursseihin Githubissa. MCP-asiakkaan ja MCP-palvelimen välillä ja MCP-palvelimen ja kolmannen osapuolen resurssien välillä käyttäjäidentiteetit ovat erillisiä. Tämä tekee käyttäjäidentiteettien ylläpitämisestä järkevää MCP-palvelimen itsensä myöntämien käyttötunnusten ja kolmansien osapuolten valtuutuspalveluiden kanssa.

Joten protokollan määrittelemän kolmannen osapuolen valtuutuksen delegointimenetelmän pitäisi ratkaista "kuinka käyttäjät valtuuttavat MCP-palvelimen käyttämään käyttäjäresursseja kolmansien osapuolten resurssipalvelimilla".

MCP-palvelin resurssipalvelimena#

Kun MCP-palvelin toimii resurssipalvelimena, MCP-palvelimen on varmennettava, kulkeeko MCP-asiakkaan pyyntö mukana kelvollinen käyttötunnus. MCP-palvelin päättää, sallitaanko MCP-asiakkaalle pääsy tiettyihin resursseihin käyttötunnuksen laajuuden perusteella.

MCP:n määritelmän mukaan MCP-palvelimen tarjoama resurssi tulisi olla MCP-asiakkaan käyttämät työkalut. Tässä skenaariossa MCP-palvelimen tarvitsee vain päättää, tarjoaako se käyttäjälle pääsyn tiettyihin työkaluihin.

Mutta todellisissa tilanteissa nämä MCP-palvelimen tarjoamat työkalut tarvitsevat myös olla vuorovaikutuksessa MCP-palvelimen palveluntarjoajan oman resurssipalvelimen kanssa. Tässä tilanteessa MCP-palvelimen asiakaskyselystä saatu käyttötunnus on käytettävä resurssipalvelimen omaan käyttöön. Useimmissa tapauksissa MCP-palvelimen ja työkalujen takana olevan resurssipalvelimen kehittäjä on sama. MCP-palvelin on vain antama rajapinta omille taustaresursseille MCP-asiakkaan käytettäväksi. Tässä tilanteessa MCP-palvelin voi jakaa saman käyttötunnuksen, joka on myönnetty yhdeltä valtuutuspalvelimelta omien resurssien kanssa.

Tässä tilanteessa, ennemmin kuin sanoisin MCP-palvelimen olevan resurssipalvelin, tarjoamassa työkaluja ja omia palveluresursseja, on parempi sanoa, että olemassa oleva resurssipalvelin muuttuu MCP-palvelimeksi tarjoamalla työkaluja MCP-asiakkaan kutsuttavaksi.

Tähän sisältyy, että resurssis niiden resurssipalvelimen tarjoamista, joka itsessään muuttaa MCP-palvelimen tarjoajansa MCP-asiakkaan käytettäväksi. Tämä johtuu käytännön huomioista todellisista skenaarioista. Mutta henkilökohtaisesti mieluummin sanoisin, että MCP-palvelimen tarjoama resurssi sisältää vain MCP-asiakkaan käyttämän työkalun, ja työkalujen vaatimat resurssit ovat resursseja, joita MCP-palvelin saa muilta resurssipalvelimilta (mukaan lukien ensisijaiset ja kolmannet osapuolet). Näin kaikki todelliset käyttökohteet voidaan kattaa.

Miten MCP-valtuutus toimii#

Kun ymmärrämme MCP-palvelimen vastuut valtuutuspalvelimena ja resurssipalvelimena, voimme tietää, miten MCP-valtuutus toimii erityisesti:

Dynaaminen asiakasrekisteröinti#

Määrittelyssä myös määritellään, miten valtuutuspalvelin tunnistaa asiakkaat. OAuth 2.1 tarjoaa dynaamisen asiakasrekisteröintiprotokollan, joka sallii MCP-asiakkaan automaattisesti hankkia OAuth-asiakas-ID:n ilman manuaalista käyttäjän puuttumista.

Määrittelyn mukaan MCP-palvelimen tulisi tukea OAuth 2.0:n dynaamista asiakasrekisteröintiprotokollaa. Näin MCP-asiakas voi automaattisesti rekisteröityä uusille palvelimille saadakseen OAuth-asiakas-ID:n. Tämä lähestymistapa on suositeltavaa MCP-konteksteissa pääasiassa seuraavien syiden vuoksi:

• MCP-asiakas ei voi tietää kaikkia mahdollisia palvelimia etukäteen
• Manuaalinen rekisteröinti aiheuttaisi käyttäjinä vaivaa
• Yhteyden luominen uusiin palvelimiin on saumatonta
• Palvelimet voivat toteuttaa omat rekisteröitymiskäytännöt

Kuitenkin käytännön näkökulmasta minulla on joitain ajatuksia dynaamisen asiakasrekisteröinnin soveltamisesta MCP-skenaarioissa:

• Käytännön OAuth-palveluissa asiakas vastaa yleensä yksi-yhteen tiettyyn liiketoimintasovellukseen. Asiakkaan dynaaminen luominen ei ehkä edistä tehokkaasti siihen liittyvien resurssien (käyttäjät, sovellukset jne.) hallintaa OAuth-palveluissa. OAuth-palveluntarjoajat yleensä haluavat pitää selkeän kontrollin yhdistetyistä asiakkaista, eikä sallia minkään asiakkaan rekisteröityä asiakkaaksi mielivaltaisesti.
• Monet OAuth-palvelut eivät suosittele tai salli käyttäjien luoda asiakasta dynaamisesti, koska se voi johtaa palvelun väärinkäyttöön. Useimmat kypsät OAuth-palveluntarjoajat (kuten GitHub, Google jne.) vaativat kehittäjiä rekisteröimään asiakkaat manuaalisesti kehittäjäkonsolinsa kautta ja voivat myös edellyttää yksityiskohtaisia tietoja sovelluksesta, palautus-URL:stä jne.
• Manuaalinen OAuth-asiakkaan rekisteröinti on itse asiassa yhden kerran työ kehityksen aikana, ei jotain, mitä jokaisen loppukäyttäjän tarvitsee tehdä. Se ei aiheuta suurta rasitusta kehittäjille.
• Julkiselle asiakkaalle (kuten natiivisovelluksille, yksisivuisille sovelluksille jne.), meillä on turvallisempia tapoja toteuttaa OAuth-virtaus ilman dynaamista rekisteröintiä. Asiakas-ID yhdessä PKCE:n (Proof Key for Code Exchange) kanssa voi tarjota riittävän turvallisen OAuth-virtauksen julkiselle asiakkaalle ilman asiakkeen dynaamista luontia.
• Vaikka protokolla mainitsee, että käyttämällä dynaamista asiakasrekisteröintiä asiakas voi välttää tarpeen tietää asiakas-ID etukäteen, itse asiassa MCP-asiakkaan on aina tiedettävä etä-MCP-palvelimen osoite etukäteen. Jos näin on, asiakkeen ID:n määrittäminen samalla kun välittää etä-MCP-palvelimen osoitteen ei aiheuta paljon ylimääräistä vaivaa. Tai voimme myös luoda konvention, jossa MCP-asiakas kysyy MCP-palvelimelta asiakas-ID:n, mikä ei ole vaikea tehtävä.

Vaikka dynaaminen asiakasrekisteröinti tarjoaa teoreettista joustavuutta MCP-ekosysteemissä, käytännön toteutuksessa saatamme tarvita harkita, tarvitsemmeko todella tätä dynaamista rekisteröintimekanismia. Useimmille palveluntarjoajille manuaalinen OAuth-asiakkaan luonti ja hallinta voi olla hallittavampi ja turvallisempi tapa.

Yhteenveto#

Tämä artikkeli analysoi syvällisesti MCP-autorisaatiomäärittelyn suunnitteluajattelua ja toteutuksen haasteita. OAuth 2.1:een perustuvana valtuutuskehyksenä tämä määrittely pyrkii ratkaisemaan keskeisen kysymyksen, miten etä-MCP-palvelin pääsee käsiksi käyttäjäresursseihin käyttäjien puolesta.

Käymällä läpi yksityiskohtaisesti MCP-palvelimen rooleja valtuutuspalvelimena ja resurssipalvelimena sekä dynaamisten asiakasrekisteröinnin ja kolmannen osapuolen valtuutuksen delegoinnin etuja ja haittoja, tämä artikkeli tarjoaa henkilökohtaisia kokemuksia ja ideoita autentikoinnin toteuttamisesta.

On huomattava, että MCP:n valtuutusmäärittely on vielä kehittyvä. Logto-tiimin jäsenenä tulemme jatkossakin seuraamaan määrittelyn viimeisimpiä kehityksiä ja jatkuvasti optimoimaan toteutusratkaisujamme käytännössä edistäen tietoturvallista vuorovaikutusta tekoälymallien ja ulkoisten palveluiden välillä.