Плагины Claude подключаются сами при входе, пока в бете

Anthropic 3 ноября открыла в бете на тарифах Team и Enterprise автоподключение плагинов: пользователь входит в Claude, и коннектор уже работает, если его MCP-сервер признаёт доверенным эмитентом сам Claude. Коннектор подключается так только при одном условии: его сервер авторизации принимает JWT bearer grant по RFC 7523 и меняет подписанное Claude подтверждение личности на токен доступа. В организациях, где вход в Claude идёт через Okta, вариант с Claude в роли эмитента недоступен.

Схема описана в документации Anthropic по Enterprise Managed Auth. Claude подписывает JWT для конкретного пользователя под адресом эмитента вида https://identity.anthropic.com/issuers/<issuer-id>, который принадлежит организации клиента. Сервер авторизации проверяет его и одним серверным запросом, без участия браузера, возвращает токен. Редиректа и отдельной страницы согласия для каждого коннектора нет: коннектор доступен, как только его включил администратор, а MCP-сервер получает такой же bearer-токен, как после обычного OAuth. Поддержку уже добавили Amplitude, Apollo.io, Atlassian, Datadog, Dropbox, Figma, Granola, HubSpot, Linear, Mixpanel, Notion, PagerDuty, Semrush и Supabase.

Вариант, где подтверждение подписывает провайдер идентификации самой компании, уже открыт всем на Team и Enterprise. Новый режим нужен клиентам без своего провайдера: организации для него не требуются ни SSO, ни подтверждённый домен. В админке Claude оба варианта видны в поле Identity source как IdP-managed и Claude-issued, формат токена и обмен на стороне сервера у них одинаковы. Но каждое рабочее пространство в продукте разработчика доверяет ровно одному эмитенту.

Что проверять в каждом запросе

Если сервер авторизации построен на готовой платформе идентификации, писать код, возможно, не придётся. Anthropic просит убедиться в трёх вещах: платформа поддерживает JWT bearer grant, выполняет все проверки подтверждения и умеет зарегистрировать доверенным эмитентом адрес, который не принадлежит провайдеру идентификации клиента. Поддержка зависит от продукта, и часть коммерческих серверов авторизации этот grant пока не умеет.

Проверки идут в заданном порядке на каждый запрос токена, любая неудача заканчивается ответом invalid_grant. Сначала сервер находит рабочее пространство, для которого выписано подтверждение. Если администратор клиента указал в настройках Claude ваш tenant ID, он придёт в claim aud_tenant, причём сам Claude это значение не проверяет. Atlassian, например, требует ввести туда свой cloudId, без него интеграция не работает, говорится в инструкции Atlassian. Иначе пространство определяется по зарегистрированному iss, и если таких пространств ноль или больше одного, запрос отклоняется.

Самое чувствительное место - сравнение эмитента. Все эмитенты Claude подписывают одними и теми же ключами, поэтому валидная подпись ничего не говорит о том, из какой организации пришёл пользователь, это определяет только iss. Сравнивать его нужно как точную строку и до загрузки ключей: совпадение по префиксу или хосту, по словам Anthropic, пускает пользователей других клиентов.

• Ключи берутся из jwks_uri документа <iss>/.well-known/openid-configuration, ключи из заголовка самого JWT игнорируются, закреплять один ключ нельзя. У эмитента Claude в этом документе только issuer и jwks_uri, без token_endpoint, так что валидатор, который ждёт полную конфигурацию OpenID Connect, его не примет: эти два поля читают сами.
• Допустимы ES256 и RS256, Claude подписывает ES256; none и HMAC вроде HS256 отклоняются. Заголовок typ должен быть oauth-id-jag+jwt.
• aud совпадает с issuer вашего сервера авторизации и может прийти строкой или массивом из одного элемента; client_id совпадает с клиентом запроса.
• Расхождение часов допускается не больше 60 секунд, а само подтверждение от Claude живёт меньше минуты.
• Каждый jti, уникальный номер подтверждения, принимается один раз. Если сервер не может проверить, был ли он уже использован, запрос отклоняется.

Токен выдаётся только для найденного пространства, даже если тот же человек состоит и в других.

Пользователь по почте

Подтверждение от Claude утверждает одно: пользователь сейчас состоит в организации клиента в Claude, а email - адрес его аккаунта в нижнем регистре. Входил ли он через SSO и проходил ли многофакторную проверку, из подтверждения не узнать, групп и sub_id в нём тоже нет. В режиме через провайдера идентификации, как описывает Atlassian, доступом управляют политики провайдера: назначения приложений, группы, условный доступ. Групповых данных из Claude-issued подтверждения сервер не получит.

Искать пользователя нужно по почте среди участников найденного пространства: адрес целиком, без учёта регистра, точки и плюс-теги не трогать. Claim sub у каждого эмитента свой, поэтому для поиска он не годится. Если такого адреса в пространстве нет, запрос отклоняют либо создают пользователя, но только когда домен почты подтверждён этим пространством в вашем сервисе.

Срок токена и удалённые сотрудники

Срок жизни токена доступа выбирает сам разработчик. Короткий, например час, не заставляет людей входить заново: Claude без участия пользователя получает новое подтверждение и меняет его на новый токен. В режиме через провайдера для этого служит долгоживущий refresh-токен, который Claude получает при входе через SSO, в режиме Claude-issued Claude подписывает подтверждения сам, пока человек состоит в организации.

Когда сотрудника удаляют из организации в Claude, новые подтверждения для него перестают подписываться. Уже выданные токены при этом действуют, так что срок токена и задаёт, сколько удалённый человек сохраняет доступ.

Схема работает и с ленивой аутентификацией, когда сервер требует вход только на защищённом вызове инструмента. На ответ 401 с заголовком WWW-Authenticate Claude обычно показывает карточку Connect и запускает OAuth, а при настроенном Enterprise Managed Auth молча делает обмен и повторяет вызов. К серверам без авторизации всё это неприменимо: они никогда не возвращают 401.

Как проверить до релиза

Пока сервер в разработке, его можно гонять в cross-app access playground от Okta без организации Claude. Сквозной тест идёт из организации на Team или Enterprise под ролью Owner или Primary Owner. Для Claude-issued подходит любая такая организация, где вход не через Okta, в том числе свежесозданная тестовая Team-организация без SSO, домена и провайдера идентификации. В ней можно сразу добавить коннектор и запустить проверку подключения.