У світі агентів на кшталт Claude чи Cursor під капотом усе частіше працює протокол MCP (Model Context Protocol), який з’єднує AI‑клієнтів із десятками корпоративних сервісів — від Figma до Notion. Але разом із цим приходять нескінченні OAuth‑консенти, довгоживучі токени й «сліпі зони» для IT‑відділів.
Про те, як це змінює новий підхід Cross-App Access (XAA) на базі специфікації Identity JWT Authorization Grant (ID‑JAG), розповідає Ґаррет Ґалоу, керівник продукту в WorkOS. Він понад десять років будував enterprise‑платформи для розробників у Microsoft Azure та Cloudflare, а нині WorkOS забезпечує автентифікацію для Anthropic, Cursor, OpenAI та інших, роблячи додатки й AI‑агентів «enterprise‑ready».
Ця стаття зосереджена на безпеці, адмініструванні та підтримці екосистемою Cross-App Access: як працюють короткоживучі токени, як централізовано відкликати доступ, що можуть налаштувати IT‑адміни в IdP, які вендори вже підтримують XAA і що потрібно MCP‑клієнтам та серверам, аби вписатися в цю модель.
Короткоживучі токени як базовий запобіжник
Класичний OAuth у зв’язці з MCP створює знайому картину: користувачі постійно проходять через consent‑екрани, а в результаті на локальних машинах накопичуються довгоживучі access і refresh токени до чутливих сервісів. Якщо обліковий запис або пристрій скомпрометовано, такі токени можуть залишатися дійсними днями чи навіть тижнями, а IT‑відділ часто не має прямого способу побачити й відкликати їх усі.
Cross-App Access пропонує іншу модель життєвого циклу токенів. У ній MCP‑сервер (наприклад, Figma) видає access‑токени, які навмисно робляться дуже короткоживучими — орієнтовно близько п’яти хвилин. Це не випадковий параметр, а свідоме обмеження «blast radius» у разі компрометації.
Якщо зловмисник отримає такий токен, часовий горизонт його корисності мінімальний. Навіть без додаткових дій з боку адміністратора, через кілька хвилин цей токен просто перестане працювати. На відміну від традиційних сценаріїв із refresh‑токенами, які можуть «жити» місяцями, тут кожен access‑токен — це тимчасовий пропуск, який швидко втрачає силу.
Важливий нюанс: для самого користувача це не означає, що йому доведеться логінитися кожні п’ять хвилин. Короткий строк життя стосується лише токенів доступу до конкретних MCP‑серверів. Під капотом XAA використовує активну SSO‑сесію в Identity Provider (IdP), щоб без участі користувача постійно оновлювати ці короткі токени.
Як одна SSO‑сесія живить безліч MCP‑токенів
У моделі Cross-App Access організаційний Identity Provider — наприклад, Okta — стає посередником довіри між MCP‑клієнтом (Claude, Cursor) і MCP‑сервером (Figma). Обидва додатки вже довіряють IdP для SSO, і XAA використовує цю довіру, щоб автоматично видавати токени доступу без додаткових consent‑екранів.
Після того як користувач один раз проходить SSO‑логін у IdP, MCP‑клієнт отримує від IdP ID‑токен і refresh‑токен. Далі вступає в гру специфікація Identity JWT Authorization Grant (ID‑JAG). Вона дозволяє клієнту звернутися до IdP з цими обліковими даними й отримати спеціальний ID‑JAG‑токен, який можна обміняти на access‑токен у MCP‑сервері.
Ключовий момент: поки SSO‑сесія в IdP активна, MCP‑клієнт може повторювати цей цикл скільки завгодно разів — отримувати нові ID‑JAG‑токени й обмінювати їх на свіжі короткоживучі access‑токени до різних MCP‑серверів. І все це без будь-якої додаткової взаємодії з користувачем.
З точки зору UX це виглядає як «магія»: користувач один раз увійшов через Okta, а Figma‑сервер у Claude чи Cursor уже «сам по собі» підключений, без жодного нового вікна з дозволами. З точки зору безпеки це означає, що:
- довготривалою сутністю стає лише SSO‑сесія в IdP, яка вже контролюється корпоративною політикою;
- усі доступи до MCP‑серверів похідні від цієї сесії й реалізуються через короткі токени, що постійно оновлюються.
Така архітектура переносить центр ваги з локально збережених OAuth‑токенів на керовану IdP‑сесію, яку IT‑відділ може контролювати й відкликати.
Централізоване відкликання доступу: коли IdP стає єдиною точкою правди
Справжня цінність XAA для корпоративних команд безпеки проявляється не лише в коротких токенах, а в тому, що відміна доступу знову концентрується в одному місці — в Identity Provider.
У традиційній MCP‑моделі на базі OAuth, навіть якщо IT‑відділ виявив компрометацію пристрою чи облікового запису й розлогінив користувача з Okta або Microsoft Entra, на локальній машині могли залишатися дійсні access і refresh‑токени до Figma, Notion та інших сервісів. Вони не були безпосередньо прив’язані до поточного стану SSO‑сесії, і IdP не мав повного огляду, де й які токени ще живуть.
У Cross-App Access усе інакше. Сценарій виглядає так:
поки SSO‑сесія в IdP активна, MCP‑клієнт може продовжувати отримувати ID‑JAG‑токени й обмінювати їх на короткі access‑токени до MCP‑серверів. Це забезпечує безперервну роботу агентів без повторних логінів.
якщо ж IdP‑сесію відкликано — наприклад, користувач звільнився, пристрій скомпрометовано або IT‑відділ примусово завершив усі сесії — MCP‑клієнт більше не може отримувати нові ID‑JAG‑токени.
після того як поточний короткоживучий access‑токен (ті самі приблизно п’ять хвилин) спливає, клієнт втрачає можливість звертатися до MCP‑сервера. Жодних довгоживучих «залишкових» прав не лишається.
Таким чином, IdP стає єдиною точкою правди щодо того, чи має агент право діяти від імені користувача. Якщо доступ у IdP втрачено, доступ до всіх пов’язаних MCP‑серверів автоматично «висихає» після закінчення короткого строку дії останнього токена.
Для IT‑команд це означає:
- немає потреби вручну шукати й відкликати розрізнені токени в кожному окремому сервісі;
- ризик «забути» про якийсь локальний credential суттєво знижується;
- політики безпеки (наприклад, обов’язковий re‑auth раз на день чи тиждень) реалізуються на рівні IdP й автоматично поширюються на всі MCP‑інтеграції.
Автентифікація, а не авторизація: чого XAA поки що не робить
Попри те що Cross-App Access суттєво змінює спосіб, у який MCP‑клієнти отримують доступ до серверів, важливо розуміти обмеження поточної реалізації. XAA, як вона описана зараз, фокусується на автентифікації, а не на зміні моделі авторизації в самих додатках на кшталт Figma.
Коли Figma виступає MCP‑сервером і приймає ID‑JAG‑токен, вона, по суті, підтверджує: «Це той самий користувач, якого я знаю з Okta, і він має доступ до мого застосунку». Після цього Figma видає звичайний OAuth‑access‑токен, і далі діють ті самі права, які користувач має у Figma як додатку.
XAA не вводить нових, більш дрібних scope‑ів чи окремих «агентських» ролей. Поточна специфікація ID‑JAG не визначає scoped або reduced‑permission grants для cross‑app доступу. Це означає, що відносини доступу залишаються на рівні «повний доступ додатку від імені користувача», а не «обмежений набір дій, дозволених лише агенту».
Практичний наслідок:
- якщо користувач у Figma має право читати й редагувати певні файли, агент, який діє через XAA, матиме ті самі можливості;
- XAA не дозволяє, наприклад, видати Claude лише «read‑only» доступ до Figma, якщо сама Figma не підтримує таку модель ролей на своєму боці.
Інакше кажучи, Cross-App Access сьогодні вирішує проблему «хто ти і чи маєш ти право зайти», але не додає нових механізмів «що саме тобі дозволено робити всередині додатку». Для більш тонкого контролю прав усе ще потрібні зміни в самих MCP‑серверах і, потенційно, подальша еволюція ID‑JAG.
ID‑JAG як універсальний міст між OIDC і SAML
Ще один важливий аспект Cross-App Access — сумісність із різними типами корпоративних SSO‑налаштувань. У реальному світі організації використовують як OIDC, так і SAML‑провайдерів, і XAA має працювати поверх обох моделей.
Специфікація ID‑JAG тут відіграє ключову роль. Вона дозволяє клієнту подати до IdP один із кількох типів облікових даних, щоб отримати ID‑JAG‑токен:
- refresh‑токен;
- ID‑токен;
- SAML‑assertion.
Це означає, що незалежно від того, чи організація використовує OIDC‑підключення, чи SAML‑федерацію, той самий базовий XAA‑флоу може працювати поверх наявної інфраструктури. Для MCP‑клієнта важливо лише, щоб його SSO‑з’єднання було XAA‑сумісним і могло запитувати та обробляти ID‑JAG‑токени.
На практиці це знімає з розробників агентів необхідність підтримувати окремі, несумісні механізми для різних IdP. ID‑JAG виступає уніфікованим шаром, який абстрагує різницю між OIDC і SAML, але при цьому зберігає можливість використовувати обидва типи підключень.
Як IT‑адміни керують XAA: політики в IdP
Cross-App Access не лише змінює технічний флоу токенів, а й переносить важливу частину контролю в руки IT‑адміністраторів, які керують IdP. Саме вони визначають, які додатки можуть запитувати доступ одне до одного.
У випадку з Okta це виглядає як політика, яка явно описує, що, наприклад, Cursor має право запитувати доступ до Figma. Адміністратор конфігурує в IdP зв’язок між двома застосунками:
- «додаток‑клієнт» (MCP‑клієнт, такий як Cursor або Claude);
- «додаток‑ресурс» (MCP‑сервер, наприклад Figma).
Коли MCP‑клієнт звертається до IdP по ID‑JAG‑токен, IdP перевіряє не лише особу користувача, а й те, чи дозволена така cross‑app взаємодія політиками. Okta може перевірити, що користувач є членом обох застосунків і що політика дозволяє видачу токенів для цієї пари «клієнт–ресурс».
Це дає IT‑відділам кілька важливих важелів:
- вони можуть дозволяти або блокувати конкретні зв’язки між агентами й сервісами;
- можуть бути впевнені, що навіть якщо користувач спробує підключити «небажаний» агент до чутливого сервісу, IdP просто не видасть ID‑JAG‑токен;
- мають централізований огляд того, які додатки в принципі можуть взаємодіяти через XAA.
На відміну від поточної MCP‑реальності, де користувач може локально додати будь-який MCP‑сервер або клієнт, минаючи IdP, XAA повертає контроль у корпоративний perimeter: без відповідної політики в IdP cross‑app доступ просто не відбудеться.
Підтримка вендорів: Okta попереду, Entra — в очікуванні
Успіх будь-якої нової моделі автентифікації залежить від того, наскільки швидко її підхоплюють ключові гравці ринку Identity. На момент виступу Ґаррета Ґалоу картина виглядає так.
Okta вже підтримує Cross-App Access для OIDC‑підключень. Це означає, що організації, які використовують Okta як IdP і мають OIDC‑інтеграції з додатками на кшталт Cursor, Claude або Figma, можуть почати впроваджувати XAA без фундаментальної перебудови SSO‑інфраструктури. Okta також планує додати підтримку XAA для SAML‑підключень, що розширить охоплення на ті організації, де історично домінує саме SAML.
Microsoft Entra (колишній Azure AD) на цей момент Cross-App Access ще не підтримує. Для величезної кількості підприємств, які покладаються на Entra як основний IdP, це означає, що XAA поки що залишається перспективною, але недоступною опцією. Поки Entra не реалізує підтримку ID‑JAG або аналогічного флоу, агенти в таких середовищах будуть змушені працювати через традиційні OAuth‑моделі з усіма їхніми обмеженнями.
Ця асиметрія створює цікавий ландшафт: компанії на Okta можуть експериментувати з новою моделлю доступу для MCP‑агентів уже зараз, тоді як екосистема навколо Entra, ймовірно, чекатиме офіційної підтримки з боку Microsoft.
Що потрібно MCP‑клієнтам і серверам, щоб увійти в XAA‑екосистему
Cross-App Access — це не лише про IdP. Щоб модель запрацювала, і MCP‑клієнти, і MCP‑сервери мають навчитися працювати з ID‑JAG‑токенами й новим флоу.
Для MCP‑клієнтів ключові вимоги такі. По-перше, їхні SSO‑підключення мають бути XAA‑сумісними, тобто вміти запитувати ID‑JAG‑токени в IdP, використовуючи refresh‑токени, ID‑токени або SAML‑assertions. По-друге, клієнти повинні реалізувати логіку обміну ID‑JAG‑токена на короткоживучий access‑токен у MCP‑сервері й оновлювати його по мірі спливу строку дії.
WorkOS уже реалізував підтримку отримання ID‑JAG‑токенів і виконання цього обміну від імені MCP‑клієнтів, які використовують WorkOS для SSO. Це означає, що розробники агентів, інтегрованих із WorkOS, можуть делегувати складну частину XAA‑флоу інфраструктурному провайдеру, а не будувати її самостійно.
Cursor і Anthropic (Claude) якраз належать до таких клієнтів: вони використовують WorkOS для своїх SSO‑з’єднань і покладаються на WorkOS для XAA‑пов’язаних потоків. Для кінцевого користувача це проявляється у вигляді «одного логіну» через корпоративний IdP і автоматично підключених MCP‑серверів без додаткових consent‑екранів.
На боці MCP‑серверів вимоги інші. Вони мають навчитися приймати новий тип JWT‑bearer‑токена, який представляє ID‑JAG‑токен. Авторизаційний компонент сервера повинен уміти:
- перевірити цей ID‑JAG‑токен у IdP;
- переконатися, що токен дійсний і відповідає очікуваному клієнту й користувачу;
- після валідації видати стандартний OAuth‑access‑токен для подальшого спілкування MCP‑клієнта з API.
Важливо, що з точки зору самого MCP‑протоколу на останньому етапі нічого не змінюється: клієнт і сервер продовжують працювати зі звичайним OAuth‑access‑токеном. Уся «магія» XAA відбувається до того, як цей токен з’являється, у взаємодії між клієнтом, IdP і авторизаційним сервером MCP‑додатку.
Висновок: безпека й контроль без втрати зручності
Cross-App Access на базі ID‑JAG пропонує відповідь на одразу кілька болючих питань, які виникли, коли MCP‑агенти почали масово підключатися до корпоративних сервісів. Короткоживучі access‑токени обмежують наслідки потенційної компрометації. Активна SSO‑сесія в IdP стає єдиним довготривалим «якорем» доступу, який IT‑відділ може централізовано відкликати.
Адміністратори отримують можливість явно визначати, які додатки можуть запитувати доступ одне до одного, а ID‑JAG забезпечує єдиний флоу поверх як OIDC, так і SAML. Водночас важливо усвідомлювати межі поточної моделі: XAA сьогодні вирішує задачу автентифікації й делегування довіри між додатками, але не вводить нових, більш дрібних рівнів авторизації всередині самих сервісів.
Підтримка з боку Okta й реалізація XAA‑флоу у WorkOS означають, що для частини ринку ця модель вже не теоретична, а практична. Для решти, зокрема екосистеми Microsoft Entra, це поки що вектор розвитку. Але загальний напрямок очевидний: у світі, де AI‑агенти стають повноцінними учасниками корпоративної інфраструктури, контроль доступу має повертатися до Identity Provider, а не розпорошуватися по десятках локальних токенів.
Джерело
One Login to Rule Them All: Cross-App Access for MCP — Garrett Galow, WorkOS