OAuth за MCP: чужд audience превръща токена в универсален ключ

Отдалеченият MCP сървър трябва да отхвърля токен, издаден за друг ресурс, както изискват правилата за сигурност на MCP. Ако приема токен с чужд audience, сървърът може да даде достъп до своите инструменти въз основа на право, предоставено за друг API. Валиден подпис или подходящ scope не поправя грешния получател.

Изградете защитата по пътя на заявката: регистрирайте точния адрес за връщане, обвържете кода за разрешаване с PKCE, поискайте токен за конкретния MCP ресурс и проверявайте всеки достъп до защитен инструмент. Когато инструментът извиква външна услуга, той използва отделен токен за нея; входящият токен на MCP клиента остава при MCP сървъра.

Започнете с клиента и точния redirect URI

Регистрирайте при сървъра за разрешаване конкретния redirect URI на клиента. При условен пример с регистриран https://client.example/callback заявка за https://client.example/callback е допустима, а https://client.example/callback/ и https://client.example/other трябва да бъдат отхвърлени. Наклонената черта в края и различният път означават друг URI. Сравнение само по домейн или по префикс може да изпрати кода за разрешаване към адрес, който клиентът не е регистрирал.

За отдалечен уеб клиент използвайте HTTPS адрес за връщане. При локален клиент е допустим localhost според приложимите правила за регистрация, но това не отменя проверката на адреса. Клиентът трябва също да свърже стойността state с конкретния опит за разрешаване и да отхвърли отговор, в който тя липсва или не съвпада. Така отговор от друга сесия няма да бъде приет като продължение на текущата заявка.

Обвържете кода за разрешаване с PKCE

Преди да отвори страницата за разрешаване, клиентът генерира нов случаен code_verifier и извежда от него code_challenge чрез S256. В заявката за разрешаване изпраща code_challenge и code_challenge_method=S256. Когато обменя получения код за токен, изпраща първоначалния code_verifier, а сървърът за разрешаване проверява дали той съответства на предишната заявка. При несъответствие кодът не бива да води до издаване на токен.

Преди потока клиентът проверява метаданните на сървъра за разрешаване. Ако code_challenge_methods_supported липсва, той трябва да прекрати разрешаването; ако полето е налично, трябва да установи поддръжка на необходимия метод. Използвайте нов verifier за всеки опит и го пазете до размяната на кода. Не го поставяйте в redirect URI, където стойността може да попадне в историята на браузъра или в записи на заявки.

PKCE защитава размяната на кода: прихванат код сам по себе си не стига за получаване на токен без съответния verifier. Получателят на издадения токен обаче се определя отделно. Затова успешният PKCE поток не е основание MCP сървърът да пропусне проверката за кой ресурс е предназначен токенът.

Посочете MCP ресурса и проверете получателя на токена

Клиентът изпраща параметъра resource както в заявката за разрешаване, така и в заявката за токен. Стойността идентифицира каноничния URI на конкретния MCP сървър; например https://mcp.example.com/mcp е подходяща, когато този път различава сървъра от други ресурси на същия хост. Спецификацията за разрешаване в MCP изисква параметъра и в двете заявки, включително когато сървърът за разрешаване не го поддържа.

Изпратеният resource е искане, а не доказателство за съдържанието на върнатия токен. Преди да обработи заявката, MCP сървърът проверява валидността на токена и дали самият той е предвиденият получател. За JWT това означава проверка на подписа, срока, очаквания издател и audience според конфигурацията на издаващия сървър. За непрозрачен токен е нужен доверен механизъм, който потвърждава същите съществени условия за употреба.

Условен отрицателен тест: токенът е издаден за https://api.example.com, а заявката пристига на https://mcp.example.com/mcp. MCP сървърът трябва да я отхвърли преди изпълнение на инструмент, дори токенът да е неизтекъл и да принадлежи на същия потребител. Проверете и положителния случай с токен, предназначен за MCP ресурса: той може да продължи към проверката на правата за конкретното действие.

Проверявайте правата при всяка защитена заявка

След установяване на валиден токен и правилен получател проверявайте дали предоставените права позволяват точно поисканата операция. Поставете тази проверка преди обработката на всяка защитена HTTP заявка, включително извикването на инструмент. Успешното свързване на клиента или предишно разрешено извикване не дава автоматично право за следващото действие.

Насоките на OWASP за MCP препоръчват проверка на разрешението при всяка защитена заявка и минимални права за сървъра и инструментите. Разграничете и причината за отказ: невалиден или изтекъл токен води до HTTP 401, докато валиден токен с недостатъчни права води до HTTP 403. Така клиентът може да поиска права за конкретната операция, без предварително да получава широк достъп до всички инструменти.

Спрете токена на границата с външния API

Входящият Bearer токен дава право за достъп до MCP сървъра. Ако инструментът чете данни от друг API, копирането на същия Authorization хедър в изходящата заявка е забранено препращане на токен. При условен поток клиентът изпраща токен към MCP, а MCP го подава без промяна към външната услуга. Дори тя да го приеме, правата за единия ресурс вече се използват при друг.

За такова извикване MCP сървърът действа като отделен OAuth клиент към външната услуга и използва токен, издаден за нейния ресурс и необходимите операции. Конфигурацията трябва да държи двата токена разделени при съхранение и при съставяне на заявките. Проверете изходящите HTTP повиквания на инструментите: входящият Bearer токен не трябва да се появява в тях, в логовете или в резултатите, върнати към модела.

Последната проверка на потока съчетава двете граници. Подайте към MCP валиден токен за чужд ресурс и установете, че заявката е отхвърлена преди изпълнение на инструмент; после извикайте инструмент с допустим MCP токен и установете, че външният API получава собствен, предназначен за него токен. Така решението за достъп остава при ресурса, за който правото действително е издадено.

Прочетете също:

• Meta превръща един prompt в игра — но достъпът още е ограничен
• Ключ за достъп в Google: не го създавайте на споделен компютър