У світі AI-інструментів для розробників Model Context Protocol (MCP) швидко стає стандартом для підключення агентів до зовнішніх сервісів — від Figma до Notion. Але разом із цим з’являється й знайома всім хвороба: нескінченні OAuth-екрани згоди, зламані сесії, «забуті» підключення та головний біль для IT-відділів.
Про те, чому саме поточна модель автентифікації MCP не масштабується для крос-додаткових AI-воркфлоу, розповідає Ґаррет Ґалоу, керівник продукту WorkOS. Він понад десять років будував enterprise-платформи для розробників у Microsoft Azure та Cloudflare, а зараз його компанія забезпечує автентифікацію для Anthropic, Cursor та OpenAI — тобто знаходиться прямо в центрі MCP- та агентної екосистеми.
Коли кожен MCP-сервер — це ще один OAuth-квест
Сьогодні MCP покладається на OAuth як базовий шар автентифікації. На папері це виглядає логічно: є клієнт (наприклад, Cursor чи Claude), є MCP-сервер (скажімо, Figma), між ними — стандартний OAuth-флоу з редіректом у браузер і consent screen, де користувач підтверджує доступ.
На практиці це перетворюється на рутину, яка швидко виходить з-під контролю. Щоб підключити MCP-сервери у тому ж Cursor, користувач додає їх у конфігурацію, а потім для кожного окремо натискає «Connect». Кожне підключення відкриває вікно браузера з черговим екраном згоди, який ніхто не читає, а просто натискає «ОК», чекаючи редіректу назад.
Проблема не лише в тому, що це потрібно робити для кожного інструмента окремо. Навіть після початкового налаштування користувачі стикаються з тим, що:
- іноді доводиться проходити флоу знову, без очевидної причини;
- клієнт «забуває», що доступ уже було надано;
- поведінка виглядає нестабільною й непередбачуваною.
Якщо одна людина підключає півдесятка MCP-серверів — це просто дратує. Але в команді з десятків розробників це означає сотні й тисячі кліків по однакових екранах згоди, які не додають жодної реальної безпеки, лише витрачають час.
Корінь проблеми — у тому, як історично задумувався OAuth. Він виходив з моделі, де два додатки не довіряють одне одному, і користувач має явно підтвердити: «Так, Cursor може мати доступ до мого акаунта Figma», «Так, Claude може читати мій Notion» тощо. У сучасних корпоративних середовищах ця модель дедалі гірше відповідає реальності.
Чому SSO не рятує, навіть якщо в компанії все «по-ентерпрайзному»
Більшість організацій уже живуть у світі Single Sign-On. Працівники заходять у всі свої інструменти через єдиний Identity Provider — Okta, Microsoft Entra чи іншу систему. З точки зору користувача це «один логін до всіх додатків», а з точки зору IT — централізований контроль доступу.
Здавалося б, якщо вже є SSO, проблема повторних входів мала б зникнути. Але в MCP-реальності цього не стається. Причина в тому, що SSO й OAuth працюють на різних рівнях:
- SSO забезпечує єдину сесію між користувачем і Identity Provider’ом;
- OAuth — окремі гранти доступу між кожною парою «MCP-клієнт ↔ MCP-сервер».
У результаті навіть якщо людина вже автентифікована через SSO, кожен MCP-клієнт усе одно змушений запускати власний OAuth-флоу з кожним MCP-сервером. SSO не скасовує потреби в окремих OAuth-грантах, а лише спрощує початковий логін до самих додатків.
Для кодувальних агентів це означає, що:
- підключення агента до кількох сервісів перетворюється на десяток OAuth-екранів згоди;
- кожне підключення створює власний життєвий цикл токенів — зі своїми строками дії, оновленням, можливими помилками;
- будь-яка зміна в конфігурації, політиках безпеки чи сесіях може «поламати» один із цих численних ланцюжків.
Фактично, SSO вирішує проблему «скільки разів я вводжу пароль», але не вирішує проблему «скільки разів я маю натискати “Allow” і скільки різних токенів живе у моїх інструментах».
Крихкі токени й сліпі зони для IT: як MCP ускладнює безпеку
Якщо для кінцевого користувача головний біль — це нескінченні consent screens, то для IT-відділу ситуація значно серйозніша. Поточна модель MCP створює зони, де корпоративна безпека втрачає контроль.
По-перше, IT-адміністратори часто не бачать повної картини того, які саме MCP-сервери використовують співробітники. Підключення до них відбувається не через централізований IDP, а безпосередньо з клієнта, який може бути будь-яким AI-агентом — від офіційно дозволеного Cursor до менш бажаних інструментів, які компанія не хотіла б допускати до чутливих даних.
Це означає, що:
- співробітник може взяти довільний MCP-клієнт і видати йому доступ до Figma, Notion чи інших систем, де зберігаються корпоративні дані;
- IT не має простого способу обмежити, які саме агенти можуть отримувати доступ до цих ресурсів;
- контроль доступу, який так ретельно налаштовується на рівні SSO, фактично обходиться на рівні MCP-підключень.
По-друге, виникає проблема «висячих» токенів. Навіть якщо IT-служба оперативно реагує на інциденти — виявляє скомпрометовані машини, відключає їх від мережі, анулює сесії в Okta чи іншому IDP — це не гарантує, що всі канали доступу перекриті.
У локальному середовищі розробника можуть залишатися:
- збережені OAuth access tokens;
- refresh tokens, які дозволяють отримувати нові access tokens;
- API-ключі та інші облікові дані, не пов’язані безпосередньо з IDP.
У контексті MCP це означає, що навіть після звичайного offboarding’у співробітника або після інциденту безпеки:
- SSO-доступ до основних додатків може бути відкликаний;
- але MCP-клієнти все ще мають дійсні або оновлювані токени до окремих сервісів;
- доступ може зберігатися днями, тижнями, а іноді й місяцями, якщо компанія не використовує додаткові механізми на кшталт SCIM для повного відкликання.
Це створює класичну проблему «lasting access»: IT вважає, що користувач уже не має доступу, але насправді в нього залишаються робочі канали через локально збережені токени MCP-підключень. І що більше таких підключень, то важче їх виявити й відкликати.
Нарешті, навіть у «мирний час», без інцидентів, поточна модель ускладнює онбординг. Компанія може автоматично налаштувати, які MCP-сервери мають бути доступні в Cursor чи Claude для нових членів команди, але кожному з них усе одно доводиться вручну проходити всі OAuth-флоу, натискати «Allow» і розбиратися з помилками, якщо щось пішло не так.
Досвід WorkOS: коли автентифікація стає інфраструктурною проблемою AI
Те, що сьогодні виглядає як «дрібна незручність» для розробника, насправді є типовою інфраструктурною проблемою, з якою enterprise-світ стикається вже багато років. І саме тут досвід WorkOS виявляється показовим.
Компанія позиціонує себе як шар автентифікації, який робить додатки та AI-агентів готовими до вимог підприємств. Вона вже забезпечує auth для таких гравців, як Anthropic, Cursor та OpenAI. Тобто всі ті інструменти, які сьогодні активно інтегрують MCP і будують навколо нього агентні сценарії, фактично працюють поверх WorkOS або подібних рішень.
Ґаррет Ґалоу до WorkOS багато років займався саме enterprise-платформами для розробників у Microsoft Azure та Cloudflare. Це означає, що:
- він добре бачить, як виглядає автентифікація не на рівні одного додатка, а на рівні екосистеми;
- знайомий із тим, як корпоративні клієнти мислять про ризики, контроль доступу та відповідність політикам;
- розуміє, що для AI-агентів автентифікація — це не просто «увійти в систему», а питання того, як агент представляє особу користувача в десятках інших сервісів.
Саме тому MCP та агенти стають для WorkOS природним полем діяльності: тут стикаються одразу три світи — AI, розробники та корпоративна безпека. І поточна модель OAuth у MCP виявляється недостатньою для того, щоб ці світи працювали разом без постійних тертя.
Чому поточна модель MCP неминуче ламається в крос-додаткових сценаріях
Якщо подивитися на MCP не як на окрему технологію, а як на інфраструктуру для крос-додаткових AI-воркфлоу, стає зрозуміло, чому сьогоднішня OAuth-модель не масштабується.
По-перше, кількість зв’язків зростає квадратично. Один агент може підключатися до десятка MCP-серверів, а в організації може бути кілька різних агентів. Кожна пара «клієнт ↔ сервер» — це окремий OAuth-грант, окремі токени, окремі consent screens і окремі точки відмови. Навіть якщо кожен із цих флоу формально «правильний», у сукупності вони створюють крихку систему, де щось постійно ламається.
По-друге, модель довіри не відповідає реальності. У класичному OAuth припускається, що додатки не знають одне про одного, а користувач є єдиним джерелом істини, який вирішує, кому що дозволити. У корпоративному середовищі все навпаки: саме організація визначає, які додатки можуть працювати разом, а користувач має отримати безшовний досвід у межах цих політик.
По-третє, SSO залишається «островом», не інтегрованим у MCP-флоу. Хоча і MCP-клієнти, і MCP-сервери вже довіряють одному й тому ж IDP, ця довіра не використовується для встановлення зв’язку між ними. Замість цього кожна пара змушена розігрувати власну міні-історію з OAuth, ніби жодної спільної точки довіри не існує.
По-четверте, життєвий цикл токенів розходиться з життєвим циклом доступу. SSO-сесія може бути відкликана, але refresh tokens у локальних інструментах продовжують жити. IT-адміністратори втрачають можливість гарантувати, що «відкликання доступу в IDP означає повну втрату доступу до всіх пов’язаних сервісів».
Усе це разом робить поточну модель MCP непридатною для того, щоб AI-агенти стали повноцінними учасниками корпоративних воркфлоу. Вона працює для ентузіастів, які готові терпіти незручності заради нових можливостей, але не для організацій, де безпека, контроль і передбачуваність є обов’язковими.
Куди рухається екосистема: MCP, агенти й enterprise-готовність
Той факт, що WorkOS уже сьогодні забезпечує автентифікацію для Anthropic, Cursor і OpenAI, показує, що питання enterprise-готовності агентів перестало бути теоретичним. Це не «майбутнє, яке колись настане», а реальність, у якій великі компанії вже тестують і впроваджують AI-агентів у свої процеси.
У цій реальності MCP має відповідати кільком вимогам одночасно:
- бути достатньо гнучким, щоб агенти могли підключатися до різних сервісів;
- бути достатньо прозорим для IT, щоб вони бачили, які саме агенти до чого мають доступ;
- бути достатньо керованим, щоб відкликання доступу в одному місці дійсно означало його втрату всюди;
- бути достатньо зручним для користувачів, щоб вони не витрачали час на повторювані й незрозумілі флоу.
Поточна модель, заснована на ізольованих OAuth-грантах між кожною парою клієнт–сервер, очевидно, не задовольняє ці вимоги. Вона створює надмірну кількість точок взаємодії, не використовує вже наявну довіру до IDP і залишає IT без повного контролю над тим, як агенти взаємодіють із корпоративними даними.
Саме тому в екосистемі MCP з’являються нові підходи, які намагаються переосмислити, як має виглядати автентифікація в світі крос-додаткових AI-воркфлоу. Одним із таких підходів є Cross-App Access (XAA), який використовує Identity Provider як посередника довіри між MCP-клієнтом і MCP-сервером та будується на специфікації Identity JWT Authorization Grant (ID-JAG).
Деталі архітектури XAA, поведінку токенів, політики безпеки та підтримку з боку вендорів розглядають окремо, але вже зараз зрозуміло головне: без переосмислення моделі автентифікації MCP не зможе стати надійною основою для масштабних агентних сценаріїв у підприємствах.
Висновок: MCP потребує нового шару довіри, а не ще одного екрану згоди
Сьогоднішня MCP-реальність — це десятки OAuth-екранів, десятки життєвих циклів токенів і десятки шансів, що щось піде не так. Навіть за наявності SSO користувачі змушені знову й знову «входити» у ті самі системи, а IT-відділи отримують фрагментовану картину доступів, де частина каналів контролюється через IDP, а частина живе власним життям у вигляді локальних токенів.
Досвід WorkOS, Anthropic, Cursor та OpenAI показує, що автентифікація для AI-агентів перестала бути другорядною технічною деталлю. Це фундаментальний елемент інфраструктури, від якого залежить, чи зможуть агенти безпечно й передбачувано працювати з десятками корпоративних сервісів одночасно.
Поки MCP покладається на традиційний OAuth без урахування вже наявної довіри до корпоративних Identity Provider’ів, він неминуче ламатиметься в крос-додаткових сценаріях. Наступний етап еволюції — це моделі, де один логін у SSO дійсно означає контрольований, керований і безшовний доступ агентів до всіх потрібних додатків, без нескінченного повторення одних і тих самих флоу.
Джерело
One Login to Rule Them All: Cross-App Access for MCP — Garrett Galow, WorkOS