MCP server: i-validate ang token, huwag ipasa sa API

Para i-secure ang authentication ng remote MCP server, itakda ang canonical resource URI nito, ipasama iyon sa authorization at token request, at tanggapin lamang ang access token na inilaan sa server. Inaatasan ng MCP authorization specification ang client na magpadala ng resource parameter sa parehong request at ang server na tiyaking ito ang intended audience ng token bago iproseso ang protektadong tawag.

Kapag kailangang tumawag sa upstream API, kumuha ang MCP server ng hiwalay na token para sa API na iyon. Tahasang ipinagbabawal ng mga tuntunin sa seguridad ng MCP ang pagpasa ng natanggap na client token sa upstream; dapat ding gumamit ang client ng PKCE at eksaktong tumugma ang redirect URI sa rehistradong halaga. Kung tatanggap ng token para sa ibang serbisyo at ipapasa pa ito, maaaring kumilos ang server bilang confused deputy: nagagamit ang pahintulot sa kontekstong hindi inilaan ng nagbigay nito.

Itakda ang audience sa simula ng daloy

Daloy ng request: MCP client → authorization server → MCP client → MCP server → upstream API. Sa unang protektadong tawag, maaaring sumagot ang MCP server ng HTTP 401 na may lokasyon ng protected resource metadata. Mula sa metadata, natutukoy ng client ang resource at ang kaugnay na authorization server; bago mag-redirect, kailangan nitong patunayan ang metadata ng napiling authorization server at itabi ang issuer para sa mismong authorization attempt.

Sa authorization request, ipadala ang canonical URI ng MCP server bilang resource parameter. Ipadala muli ang parehong target sa token request pagkabalik ng authorization code. Kung maraming MCP endpoint sa iisang host, piliin ang URI na sapat ang pagiging tiyak upang makilala ang server na gagamit ng token; ang magkaparehong host lamang ay hindi awtomatikong nangangahulugang magkapareho ang resource.

Ang resource parameter ay pahayag ng hinihinging target, hindi kapalit ng validation sa tumatanggap na server. Dapat siyasatin ng MCP server kung para talaga rito ang token na ibinalik ng authorization server. Kung hindi sinusuportahan ng authorization server ang resource indicator o hindi maipakita ng token validation na para sa MCP server ang token, huwag ipagpalagay na ligtas ito dahil lamang nagtagumpay ang pag-login.

Ihigpit ang authorization request at callback

Bago simulan ang authorization, tingnan ng client ang metadata ng authorization server para sa suportadong PKCE code challenge method. Kung wala ang kinakailangang impormasyon, ihinto ang flow. Gumawa ng code verifier para sa bawat authorization attempt, ipadala ang kaugnay na challenge sa authorization request, at gamitin ang S256 kapag teknikal na kaya. Sa token request lamang ibigay ang verifier; dapat mabigo ang palitan kung hindi ito tumutugma sa challenge.

Irehistro ang redirect URI at ipasuri sa authorization server ang eksaktong halaga nito sa bawat authorization request. Hindi sapat ang parehong domain kung iba ang path o may idinagdag na redirect target. Inirerekomenda ring gumawa ang client ng state para sa bawat attempt at ihambing ito sa callback; kung ginamit ang state, itapon ang resultang walang tugma. Magkakaiba ang tungkulin ng mga kontrol: pinoprotektahan ng PKCE ang paggamit ng code, tinatakdaan ng redirect URI kung saan ito babalik, at iniuugnay ng state ang callback sa sinimulang request.

Sa rebisyon noong 2026-07-28, inilalarawan ng opisyal na paliwanag ng MCP ang rekomendasyong magbalik ang authorization server ng iss at ang obligasyon ng client na i-validate ito bago i-redeem ang code. Ihambing ang iss sa issuer na nakuha mula sa na-validate na metadata at itinabi bago ang redirect; eksaktong paghahambing ng string ang kailangan, kahit sa error response. Kung ipinahayag sa metadata na sinusuportahan ang iss, tanggihan ang callback kapag wala ito. Kung may iss ngunit iba ang halaga, tanggihan din ito; pinapayagan pa ang kawalan nito kapag hindi ipinahayag ang suporta.

Patunayan ang inbound token bago patakbuhin ang tool

Ang MCP server ay resource server sa daloy na ito. Sa bawat protektadong HTTP request, dapat nasa Authorization header ang bearer token, at kailangang suriin ng server ang bisa nito, ang pinagmulang authorization server, ang intended audience at ang pahintulot para sa hinihinging operasyon. Hindi sapat ang matagumpay na signature check kung para sa ibang API ang token. Para sa JWT, maaaring suriin ang kaugnay na claims at signature; para sa opaque token, kailangan ng validation na naaayon sa issuer.

Gawin ang pagsusuri bago patakbuhin ang tool o magbalik ng protektadong data, kabilang ang mga request matapos ang unang matagumpay na authorization. Ang nawawala, hindi balido o paso nang token ay dahilan para sa HTTP 401. Kung balido ang token ngunit kulang ang scope o pahintulot, HTTP 403 ang angkop na sagot; maaaring ilagay sa challenge ang scope na kailangan para sa kasalukuyang operasyon upang makahingi ang client ng sapat na pahintulot.

Gumamit ng hiwalay na credential sa upstream API

Ang inbound token ay pahintulot para sa MCP resource. Kapag kumokonekta ang server sa upstream API, gumamit ito ng authorization flow na sinusuportahan ng upstream provider at kumuha ng access token na inilaan para sa upstream API, na may kinakailangang scope at angkop na user o service context. Panatilihing magkahiwalay ang pag-iimbak at paggamit ng inbound credential at upstream credential.

May dalawang posibleng sintomas ang shortcut na token passthrough. Kung mahigpit ang upstream audience check, tatanggihan ng API ang token na para sa MCP server. Kung tatanggapin ito sa maling konteksto, maaaring malampasan ang hangganang naghihiwalay sa pahintulot para sa MCP server at pahintulot para sa upstream API. Hindi lunas ang pagluwag ng audience validation; kailangang ayusin ang hiwalay na upstream authorization.

Subukan ang pagtanggi sa bawat hangganan

Sa integration tests, mahalagang makita kung aling component ang tumanggi at kung may naganap nang token exchange, tool execution o upstream call bago iyon. Gumamit ng sinadyang maling input sa bawat yugto ng daloy:

Magpadala sa MCP server ng token na balido ang signature ngunit para sa ibang audience. Dapat itong tanggihan bago patakbuhin ang tool o tawagin ang upstream API.
Magpadala ng paso nang token, pagkatapos ay balidong token na kulang ang scope. Asahan ang HTTP 401 sa una at HTTP 403 sa ikalawa.
Baguhin kahit ang path lamang ng rehistradong redirect URI. Dapat pigilan ng authorization server ang redirect sa hindi tugmang halaga.
Gumamit ng maling PKCE verifier. Dapat mabigo ang code exchange; dapat ding huminto ang client bago mag-redirect kung hindi nito makumpirma ang PKCE support sa metadata.
Magbalik ng maling state o ng iss na iba sa itinabing issuer. Dapat huminto ang client bago ipadala ang code sa token endpoint. Subukan din ang nawawalang iss kapag ipinahayag ng metadata na sinusuportahan ito.
Sa matagumpay na upstream call, tiyaking iba ang ipinadalang credential sa inbound client token at para ito sa upstream API.

Basahin din: