Безпечні масштабовані віддалені МСР-сервери своїми руками

MCP (Model Context Protocol) — це протокол, який дає можливість AI-агентам підключатися до різних інструментів і даних. Без складного коду та десятків конекторів. 

Наприклад, можна автоматично витягувати дані з інвойсів, шукати шматки коду в проєкті чи підсумовувати сапорт-квитки. І все це — у єдиному та уніфікованому форматі. 

Звучить зручно — і воно дійсно так. Але є нюанс: чим більше можливостей, тим більшою є поверхня атаки.

MCP-сервер може відкривати доступ до важливих внутрішніх ресурсів компанії. А це значить, що будь-який прорахунок у безпеці — це не просто «упс». Це ризик втрати даних, контролю, або навіть можливість впливати на поведінку штучного інтелекту.

Тому безпека — не опція, а фундамент. Її потрібно закладати ще до першого запиту. І саме про це ми зараз поговоримо.

Як працює авторизація в MCP?

MCP не вигадує свій велосипед — він використовує OAuth 2.1. Це добре, бо замість написання кастомних механізмів перевірки доступу, можна просто взяти надійні інструменти й бібліотеки.

Коли AI-агент хоче звернутись до захищеного MCP-сервера, йому потрібен токен доступу. Але все відбувається автоматично і за правилами, які добре відомі кожному, хто працював з OAuth.

Ось як виглядає типовий флоу:

1. AI-агент (MCP-клієнт) звертається до MCP-сервера без токена.
2. Сервер каже: «Сорі, 401 Unauthorized» і додає в заголовок посилання, де взяти метадані для авторизації.
3. Клієнт читає ці метадані й дізнається, через який авторизаційний сервер треба йти.
4. Якщо підтримується, реєструється автоматично (так званий Dynamic Client Registration).
5. Далі — класичний OAuth-флоу: з підтвердженням доступу, токеном і всім іншим.
6. Клієнт отримує токен і надсилає його з кожним наступним запитом до MCP-сервера.

Що важливо, цей флоу повністю стандартний. MCP просто дотримується нормальної специфікації, а не вводить свої вимоги. Тобто:

• можна використовувати наявні OAuth-сервери (типу Auth0, Azure AD, Keycloak, Google Identity)
• не потрібно вигадувати нові протоколи
• можна швидко почати без зайвих налаштувань

Що має бути реалізовано на MCP-сервері?

Просто увімкнути OAuth недостатньо. Щоб авторизація працювала, MCP-сервер має вміти розпізнавати, перевіряти й правильно обробляти токени.

Тому ось які речі треба реалізувати на сервері:

PRM endpoint

Сервер має показувати клієнтам, з яким авторизаційним сервером він працює. Для цього він публікує endpoint із метаданими за стандартною адресою:

/.well-known/oauth-protected-resource

Там клієнт знайде всю потрібну інфу для авторизації: URL авторизаційного сервера, підтримувані scope, вимоги до токена тощо.

У деяких SDK (наприклад, у TypeScript-версії від MCP) це вже реалізовано.

Перевірка токенів

Прийняти токен — ще не значить, що він валідний. Потрібно:

• дістати токен із заголовка Authorization: 

Bearer <token>

• перевірити підпис через JWKS (JSON Web Key Set)
• переконатися, що токен не протух (перевірити exp)

перевірити аудиторію (aud) — тобто токен має бути виданий саме для цього сервера, а не якогось іншого

Можна використовувати бібліотеки типу PyJWT, jsonwebtoken, oauthlib — вони вміють усе це робити.

Обробка помилок

Коли щось іде не так, сервер має чітко пояснювати, що саме сталося:

• відсутній токен: 401 Unauthorized + WWW-Authenticate заголовок;
• токен неправильний або прострочений: теж 401;
• токен є, але доступ до ресурсу заборонено: 403 Forbidden.

Це важливо, бо від цього залежить, чи клієнт зможе зрозуміти, в чому проблема, і що з нею робити.

Підтримка Dynamic Client Registration

Тобто можливість автоматично реєструвати клієнтів через OAuth, без ручного додавання їх в адмінці.

На жаль, не всі провайдери це підтримують, але з часом ситуація покращується. Якщо хочеш бути на крок попереду — варто подумати про цю функцію вже зараз.

Багатокористувацькі сценарії

Коли MCP-сервер працює з багатьма користувачами одночасно, важливо чітко розмежовувати, хто до чого має доступ. 

Один промах, і користувач «А» випадково побачить або змінить дані користувача «Б». Це і є confused deputy — коли система виконує запит, не розібравшись, від чийого імені й для кого.

Перевіряй користувача

• перевір підпис токена та його дійсність
• діставай ID (sub) і переконайся, що токен для твого сервера (aud)

Знати права

• зв’язуй користувача з профілем
• перевір, що дозволено робити
• пам’ятай: автентифікація ≠ авторизація

Ізоляція даних

• кожен запит до бази, API чи логів — тільки в межах користувача
• не довіряй токену без перевірок
• користуйся готовими бібліотеками для токенів і сесій

Навіщо потрібен AI gateway?

Коли MCP-сервер працює з великою кількістю AI-запитів, на нього звалюється купа технічних завдань. Щоб не перевантажувати сервер зайвим, їх краще винести в AI gateway — проміжну ланку між клієнтом і сервером.

Замість тебе він буде робити:

1. перевірку токенів
2. рейт-лімітинг 
3. кешування відповідей
4. трансформацію запитів/відповідей
5. базовий захист (CORS, заголовки безпеки)

Секрети в MCP: де зберігати й чого не робити

У більшості проєктів усе починається з .env. Але коли MCP-сервер виходить у продакшен і стає точкою входу до внутрішніх систем, такий підхід стає небезпечним.

Секрети — це ключі до всього (баз даних, зовнішніх API, OAuth-серверів). І якщо на них забити, зловмисник отримає доступ не тільки до MCP, а й до всього, що за ним стоїть.

Надійний варіант — зберігати секрети у спеціалізованих сховищах типу AWS Secrets Manager, Azure Key Vault або HashiCorp Vault. Вони дають шифрування, аудит, контроль доступу й автоматичну ротацію. 

Ще краще — взагалі не передавати паролі, а використовувати так звану ідентифікацію навантаження (workload identity), коли твій застосунок отримує права напряму від хмари, без явних ключів.

І найголовніше: кожен MCP-сервер має бачити лише ті секрети, які йому реально потрібні. Якщо щось піде не так, менший доступ означає менші наслідки.

Спостереження й моніторинг

Запустити MCP-сервер — лише пів справи. Складніше бачити, що відбувається, і вчасно реагувати. Для цього варто зосередитися на трьох речах:

1. Логи з унікальними ID
   Кожен запит отримує свій ідентифікатор (correlation ID). Це дозволяє відстежити його шлях через сервер і зовнішні сервіси, навіть якщо стався збій.
2. Трейси
   Хочеш знати, де система тупить? Трейси (наприклад, через OpenTelemetry) показують, як запит проходить крок за кроком і де виникають вузькі місця.
3. Метрики та алерти
   Слідкуй за основними показниками: кількість запитів, затримки, помилки авторизації. Автоматичні алерти та дашборди допомагають помітити проблеми перш ніж вони вплинуть на користувачів.

Підсумок

Безпечний і масштабований MCP-сервер — це не тільки код, а структура, яка продумала права користувачів, захист секретів і контроль за запитами. 

Якщо правильно налаштувати авторизацію, ізоляцію даних і спостереження, сервер зможе працювати з тисячами користувачів і інструментів одночасно, без хаосу і сюрпризів.

І в тебе однозначно все вийде!