У корпоративному світі AI‑агентів та інструментів на базі Model Context Protocol (MCP) розрив між зручністю для розробників і вимогами безпеки стає дедалі помітнішим. Кожне підключення нового MCP‑сервера означає ще один OAuth‑флоу, ще один екран згоди, ще один набір токенів, які потрібно обслуговувати. Попри наявність Single Sign‑On (SSO), користувачі знову й знову проходять авторизацію в одних і тих самих системах.
Гаррет Галоу, керівник продукту в WorkOS, який раніше будував enterprise‑платформи для розробників у Microsoft Azure та Cloudflare, пропонує іншу модель. WorkOS забезпечує автентифікацію для того, щоб застосунки та AI‑агенти були «enterprise‑ready», і вже сьогодні стоїть за логіном у таких продуктах, як Anthropic, Cursor та OpenAI. У своїй доповіді він описує Cross‑App Access (XAA) та специфікацію Identity JWT Authorization Grant (ID‑JAG) — механізм, що перетворює один SSO‑вхід у множину короткоживучих токенів доступу до різних MCP‑серверів.
Коли SSO не рятує: як MCP множить OAuth‑флоу
MCP сьогодні покладається на OAuth як базовий шар автентифікації. Для кожного MCP‑сервера — Figma, Notion чи будь‑якого іншого — MCP‑клієнт на кшталт Cursor або Claude ініціює окремий OAuth‑флоу з власним екраном згоди. Користувачеві доводиться підтверджувати: так, Cursor може отримати доступ до мого Figma‑акаунта; так, Claude може працювати з моїми документами в іншому сервісі.
У невеликій команді це виглядає як просто дратівна рутина. У великій організації, де розробники підключають півдесятка чи десяток MCP‑серверів, а таких розробників — десятки, це перетворюється на масове «клікання по згодах», яке ніхто не читає й не контролює. Ба більше, іноді ці флоу повторюються без очевидної причини: токени забуваються, сесії втрачаються, користувачі знову бачать ті самі вікна.
Теоретично SSO мав би розв’язати цю проблему. Працівник компанії входить через Okta чи Microsoft Entra, отримує єдину сесію і далі безшовно працює з усіма корпоративними застосунками. Але MCP руйнує цю модель: протокол виходить з того, що застосунки не знають одне про одного, не мають спільного уявлення про користувача і не можуть покладатися на вже встановлену довіру. У результаті SSO існує, але не використовується як єдине джерело істини для AI‑агентів, які ходять у різні сервіси.
Це створює не лише незручність, а й прогалини для IT‑відділів. Вони не бачать, до яких саме MCP‑серверів підключаються агенти, не завжди можуть контролювати, які саме AI‑клієнти отримують доступ до чутливих даних у Figma чи Notion, і не мають централізованого важеля, щоб оперативно перекрити цей доступ.
Тристороння довіра: як XAA використовує Identity Provider як посередника
Cross‑App Access (XAA) пропонує змінити точку опори. Замість того, щоб кожен MCP‑клієнт напряму будував довіру з кожним MCP‑сервером через окремі OAuth‑флоу, XAA використовує вже наявну довіру до корпоративного Identity Provider (IDP) — Okta, Entra чи іншого.
У типовій архітектурі, яку демонструє Галоу, є три ключові учасники. MCP‑клієнт — наприклад, Cursor або Claude. MCP‑сервер — Figma, що надає API й MCP‑ендпоінт. І IDP — Okta, через яку співробітники компанії вже входять у всі свої застосунки.
І Cursor, і Figma вже довіряють Okta: обидва інтегровані з нею для SSO, обидва знають про домен компанії, обидва розуміють, хто такий конкретний користувач і чи має він право користуватися цими застосунками. XAA використовує цю спільну довіру, щоб побудувати місток між клієнтом і сервером.
Суть у тому, що Identity Provider стає посередником довіри між MCP‑клієнтом і MCP‑сервером. Клієнт не просить Figma про доступ напряму, а звертається до Okta з проханням видати спеціальний токен, який Figma визнає як достатній доказ того, що:
користувач автентифікований через SSO;
користувач є членом і клієнтського застосунку (Cursor/Claude), і серверного (Figma);
IT‑адміністратор дозволив саме цьому клієнту запитувати доступ до саме цього сервера.
Таким чином формується тристороння модель довіри: MCP‑клієнт довіряє IDP, MCP‑сервер довіряє IDP, а IDP виступає арбітром, який вирішує, чи можна одному застосунку діяти від імені користувача в іншому.
ID‑JAG: специфікація, що перетворює SSO‑сесію на крос‑аплікейшн токен
Технічно XAA реалізується через специфікацію Identity JWT Authorization Grant (ID‑JAG). Попри громіздку назву, її роль відносно проста: визначити, як і в якому форматі ідентифікаційні твердження (assertions) від IDP можуть бути обміняні на токен, придатний для доступу до іншого застосунку.
У демонстраційній схемі з Claude, Figma й Okta ланцюжок виглядає так.
Спочатку користувач один раз входить у Claude через SSO в Okta. Це стандартний OIDC‑флоу: після успішної автентифікації Claude отримує від Okta ID‑токен і refresh‑токен. Ці токени засвідчують особу користувача і дають змогу оновлювати сесію без повторного логіну.
Далі, коли Claude хоче підключитися до Figma як до MCP‑сервера, він не показує користувачеві новий екран згоди. Натомість клієнт звертається назад до Okta і, посилаючись на вже отримані ID‑токен або refresh‑токен, просить видати ID‑JAG‑токен, який буде дійсним саме для Figma.
Специфікація ID‑JAG дозволяє клієнту пред’явити різні типи первинних тверджень: це може бути refresh‑токен, ID‑токен або навіть SAML‑асерція, залежно від того, як налаштований IDP. У відповідь IDP, якщо все гаразд, видає ID‑JAG‑токен — спеціальний JWT, призначений саме для крос‑аплікейшн‑доступу.
Ключовий момент у тому, що перед видачею такого токена IDP виконує перевірку членства. Okta має інформацію про те, до яких застосунків підключений користувач, і про те, які крос‑аплікейшн‑зв’язки дозволені IT‑адміністратором. Тому, перш ніж видати ID‑JAG‑токен, вона перевіряє, чи є користувач членом як MCP‑клієнта (Claude), так і MCP‑сервера (Figma), і чи дозволено Claude запитувати доступ до Figma.
Якщо відповідь позитивна, IDP видає ID‑JAG‑токен, який Claude може пред’явити Figma як доказ того, що:
користувач автентифікований;
користувач має доступ до обох застосунків;
цей запит узгоджений із політиками організації.
Як XAA вбудовується в існуючий OAuth‑ландшафт MCP‑серверів
З боку MCP‑сервера XAA не вимагає радикальної перебудови. У прикладі з Figma архітектура розділена на два компоненти: ресурсний сервер (власне Figma API та MCP‑сервер) і сервер авторизації, який видає OAuth‑токени.
Коли Claude отримує ID‑JAG‑токен від Okta, він надсилає його не безпосередньо в API Figma, а в компонент авторизації Figma. Повідомлення по суті звучить так: «Ось ID‑JAG‑токен для цього користувача від нашого спільного IDP. Перевірте його і, якщо все гаразд, видайте мені звичайний OAuth‑access‑токен».
Сервер авторизації Figma, маючи власну інтеграцію з Okta, верифікує ID‑JAG‑токен у IDP. Якщо токен дійсний, не прострочений і відповідає дозволеній конфігурації крос‑доступу, Figma видає Claude стандартний OAuth‑access‑токен.
На цьому етапі XAA‑специфіка закінчується, а далі починається звичайний MCP‑флоу. Claude використовує отриманий OAuth‑токен, щоб звертатися до MCP‑сервера Figma, а той — до свого API. Для MCP‑сервера це виглядає як звичайний клієнт із коректним OAuth‑токеном; не потрібно підтримувати новий тип облікових даних або змінювати семантику доступу.
Важливо, що XAA на цьому етапі зосереджується саме на автентифікації та встановленні довіри між застосунками. Він не змінює моделі авторизації всередині Figma чи інших MCP‑серверів: які саме дії може виконувати агент, як налаштовані ролі й дозволи — усе це залишається в межах існуючих механізмів самого сервісу. Специфікація ID‑JAG наразі не визначає «урізані» або спеціально скоуплені гранти для крос‑аплікейшн‑доступу; вона лише описує, як безпечно перенести ідентичність користувача з одного застосунку в інший через IDP.
Один логін — багато підключень: як виглядає XAA з точки зору користувача
У демонстрації з Claude‑клієнтом, Figma‑сервером і Okta як IDP користувацький досвід радикально відрізняється від класичного MCP‑сценарію.
Спочатку користувач відкриває Claude і проходить SSO‑логін через Okta. Це може бути перший вхід за день або за тиждень — залежно від політик організації. Після успішної автентифікації Claude отримує ID‑токен і refresh‑токен і зберігає їх локально.
Далі, коли користувач відкриває список MCP‑серверів у Claude, Figma вже відображається як підключена. Немає додаткового вікна браузера, немає окремого екрану згоди, немає ручного підтвердження доступу. Підключення відбулося «автоматично», але не за рахунок прихованих API‑ключів чи небезпечних практик, а завдяки тому, що за лаштунками відпрацював XAA‑флоу з ID‑JAG‑токеном.
Для користувача це виглядає як справжній «one login to rule them all»: один вхід через корпоративний IDP відкриває шлях до всіх дозволених MCP‑серверів, без повторних авторизацій і без плутанини з тим, чому той чи інший інструмент раптом «забув» попередню згоду.
Для IT‑відділу це означає, що всі ці підключення відбуваються в рамках контрольованої моделі. Адміністратори в IDP явно визначають, який застосунок може запитувати доступ до якого іншого. У налаштуваннях Okta вони конфігурують Cross‑App Access, встановлюючи, наприклад, що Claude має право отримувати ID‑JAG‑токени для Figma, але не для якогось іншого, небажаного сервісу. Якщо політика змінюється, адміністратор оновлює її в одному місці — в IDP.
Короткоживучі токени й залежність від SSO‑сесії
Ще одна важлива характеристика XAA‑патерну — те, як він працює з часом життя токенів. У класичному OAuth‑сценарії MCP‑клієнт часто отримує довгоживучі access‑токени або refresh‑токени, які можуть залишатися дійсними днями чи тижнями. Якщо користувач звільняється або його обліковий запис компрометовано, ці токени можуть продовжувати давати доступ до сервісів, навіть коли SSO‑доступ уже відкликано.
У моделі XAA access‑токени, які MCP‑сервер видає клієнту після валідації ID‑JAG‑токена, можуть бути дуже короткоживучими — на рівні кількох хвилин, орієнтовно близько п’яти. Це зменшує вікно, протягом якого скомпрометований токен може бути використаний.
При цьому MCP‑клієнт не змушений турбувати користувача кожні п’ять хвилин. Поки SSO‑сесія в IDP активна, Claude або Cursor можуть повторювано отримувати нові ID‑JAG‑токени, пред’являючи refresh‑токен або інше первинне твердження, і обмінювати їх на свіжі access‑токени для MCP‑серверів — усе це без додаткової взаємодії з користувачем.
Якщо ж SSO‑сесію в IDP відкликано, користувач втратив доступ до застосунку або його обліковий запис деактивовано, ланцюжок обривається. MCP‑клієнт більше не може отримати нові ID‑JAG‑токени, а отже, після закінчення строку дії поточного короткоживучого access‑токена доступ до MCP‑серверів автоматично припиняється. Це повертає контроль у руки IT‑відділу: достатньо відкликати сесію або доступ у IDP, щоб через кілька хвилин AI‑агенти втратили можливість звертатися до корпоративних сервісів.
Підтримка з боку IDP та роль адміністраторів
Щоб XAA працював, потрібна підтримка з боку Identity Provider. У випадку Okta така підтримка вже є для OIDC‑підключень, а в планах — розширення на SAML‑базовані інтеграції. Це означає, що застосунки, які вже використовують Okta як IDP через OpenID Connect, можуть поступово додавати підтримку ID‑JAG і Cross‑App Access без повної перебудови своїх auth‑флоу.
Натомість Microsoft Entra на момент виступу ще не підтримує XAA або ID‑JAG. Це обмежує можливості організацій, які повністю покладаються на Entra як на єдиний IDP, але водночас задає вектор розвитку: якщо патерн XAA приживеться, іншим постачальникам ідентичності доведеться наздоганяти.
IT‑адміністратори відіграють центральну роль у цій моделі. Саме вони в IDP визначають, який застосунок може запитувати доступ до якого іншого. У термінах Okta це означає конфігурацію Cross‑App Access: наприклад, дозволити Claude запитувати ID‑JAG‑токени для Figma, але заборонити будь‑яким іншим AI‑клієнтам робити те саме. Таким чином, навіть якщо користувач спробує підключити «лівий» MCP‑клієнт до корпоративного Figma, без відповідної XAA‑конфігурації в IDP це буде неможливо.
Ця централізація не лише спрощує керування доступом, а й робить його прозорішим. Замість того, щоб відстежувати десятки окремих OAuth‑інтеграцій між різними клієнтами й серверами, IT‑відділ працює з єдиною матрицею дозволених крос‑аплікейшн‑зв’язків у IDP.
Висновок: XAA як міст між зручністю AI‑агентів і вимогами enterprise
Model Context Protocol відкриває шлях до потужних крос‑аплікейшн‑AI‑воркфлоу, але традиційна модель OAuth у цьому контексті виявляється незручною і для користувачів, і для адміністраторів. Cross‑App Access і специфікація ID‑JAG пропонують спосіб використати вже існуючу довіру до корпоративного Identity Provider, щоб перетворити один SSO‑логін на множину контрольованих, короткоживучих токенів доступу до MCP‑серверів.
У прикладі з Claude, Figma та Okta видно, як це працює на практиці: користувач входить один раз, а далі MCP‑клієнт непомітно для нього обмінює SSO‑сесію на ID‑JAG‑токени й стандартні OAuth‑access‑токени для різних сервісів. При цьому зберігається сумісність з існуючими OAuth‑механізмами, а контроль над тим, хто до чого має доступ, концентрується в IDP.
XAA не змінює моделі авторизації всередині окремих застосунків і не вводить нові типи прав доступу. Його сила в іншому: у можливості зробити AI‑агентів «першокласними громадянами» корпоративної екосистеми, які поважають SSO, політики безпеки й рішення IT‑відділу, не змушуючи при цьому користувачів нескінченно клікати по екранах згоди.
Джерело
One Login to Rule Them All: Cross-App Access for MCP — Garrett Galow, WorkOS